Who needs this?

This article intends to shed some light on the overall benefit of developing software in an agile and statistically based way.

This article is useful for you if:

• You are a product owner or a stakeholder that does not see enough progress from a development team
• You are part of an Agile process which involves more precise estimation
• You are part of a team that is having some trouble with calibrating estimations
• You want to know more about software estimation in general

Existent development methodologies

The most important software development methodologies that are part todays world are the Waterfall methodology and the Agile methodology. They both have their strengths and weaknesses so it would make a lot more sense to cherry-pick the good parts out of the methodologies, then to pit them against each-other.

Waterfall

The Waterfall model is a multiphase software development framework which originated from the manufacturing industry. It allows for the building of software components according to a sequence of predefined operations.

The waterfall interaction is usually characterised by (high level):

• A full list of requirements exists upfront, as before the start of the project, a list of requirements has been computed in order to assess feasibility.
• Design phase is done at the beginning of the project, and based on the design phase, the rest of the project is estimated.
• The project deadline and costs are estimated at the beginning of the project based on the provided list of software feature requirements
• The development company will commit to the estimated duration and cost of the project, as the budget allocated for the project would be strict.
• Each time a requirement is changed, it will have to pass through the sequential pipeline of Analysis –> Design –> Construction –> Testing –> Deployment.
• In modern waterfall, re-estimation of required budgets are performed from time to time, in order to re-ensure the project’s feasibility.

Agile

Initially, the Agile methodology was consisted of a very small set of guidelines which aimed at pointing out that software development should be flexible in nature and that both stakeholders and development companies should calibrate processes of mutual benefit in order to build software solutions. Along the way, the agile methodology itself reached a level of standardisation which goes against what it had originally intended but which had proven effective for numerous large tier enterprises.

The agile interaction is usually characterised by (high-level):

• Just enough requirements exists in order to start the project. The rest of the requirements are computed along the way.
• As development is performed in iterations, analysis, design, implementation, testing and deployment are performed in iterations.
• The project deadline and costs are estimated throughout the lifetime of the project, after valuable business metrics are computed.
• The development company does not have to commit to a budget, as payment is commonly executed at the end of each iteration if the stakeholders accept the way that the features have been developed.
• Each time a requirements is changed, it will be pushed to the backlog and picked up in future iterations.
• Re-estimation is practically done periodically by the fact that velocity is constantly computed.

The problems of the industry

Throughout our interaction with stakeholders in various projects that we’ve delivered, questions such as  “When will your team be done with this project?” or “When will that feature be ready?” have popped up more times that we can count. It took us a while to actually understand why all stakeholders seem to be in such a hurry, and why it is crucial for them to have the ability to compute forecasts.

Cost and timing

Developing software is a rather costful operation where accurate estimation seem to be critical in allowing the business stakeholders to plan for strategies that would allow for their newly developed product to penetrate the discovered market. Many markets have just a window of opportunity, so accurate forecasting and fixed budget allocations are things to dream for in all kinds of enterprises.

Estimation fallacy

In areas such as manufacturing, business intelligence allows stakeholders to predict the time it takes to create and deliver a functional part down to the millisecond, thus being able to accurately forecast financial gains made off of the commercialising of the mentioned parts.

The ability to perform precise estimations was only obtained by the manufacturing industry by the reiteration and restandardization of manufacturing processes which were tailored over a period of time.

You would expect the same type of precision to exist when manufacturing software, because it’s rather similar to manufacturing goods in the sense that it has a defined “assembly process” in which a “raw materials” (the requirements) are passed along multiple “manufacturing lines” (software development teams) which produce  “functional parts” (software components) that end up being assembled into a finite product. And there you go, the product manufacturing is estimated down to the millisecond!

The dystopian reality is that, since during the process of software development we’re not interacting with machines, and since developing software relies more than ofter on intellectual and creative effort that implies tackling new problems with new solution, we cannot estimate with machine like precision the actions of “non machine agents” (developers).

Hard to predict or scale

Up until recent years, estimation in software development was performed using “ideal man hours” which implied that developers estimated their work effort in working hours, based on their working shift. Developers thus had to guess exactly how many hours were necessary in order to implement a feature based on the provided requirements, without having nothing to correlate against, except their experience. If a developer had experience on his side, then the chance that a 5 hour estimate would be implemented in 5 hours would be greater.

Having estimations done this way does not account for situations where developers are overconfident or over-pessimistic in their estimations. Nor can the stakeholders compute the impact of adding new developers to the team in a reliable manner.

But then how can the stakeholders estimate the time it takes to build the actual product or software feature in a way that will allow them to perform forecasts?

Business agility

Iterative development

As opposed to fixed deadline estimations that attempt to estimate and plan when a project will end from the start, Agile development is performed in iterations of development called “Sprints” which take up between 2 and 4 weeks. This offers flexibility with regards to the changing and collecting of requirements, as it allows teams to continue developing on chunks of the product in an iterative fashion without being impeded by the lack of upfront and complete requirements.

Also, by developing software this way, the stakeholders can have more insight into what and how is developed, as a common practice in the Agile realm is to have a Demo meeting at the end of each iteration, in which the development team shows the stakeholders what was implemented and how.

The story point

Because the concept of a user story had existed long before Agile development was born, there was a need to somehow replace inaccurate hourly estimations in such a manner as to allow for more fine grained estimations which business stakeholders can use in order to predict delivery deadlines. Thus the story point came to life, as a metric of complexity plus effort.

A story point is practically an integer used to denote the overall complexity and effort needed for any developer in a team to implement a user story according to the team’s defined definition of done.

The most common integer values attributed to story points are the ones that can be found in the Fibonacci sequence, mainly 1,2,3,5,8,15,21 and so on. The values are attributed this way in order to generate a sense of magnitude for the development team, as each number in the fibonacci sequence is the result of the sum of the previous two numbers.

Story point estimation is used to replace hourly estimations in organisations that have a fixed length working schedule. An example would be the 8 hour man day.

Team estimation

As said before, estimating tasks in ideal work hours does not work well, as hours estimated by one developer cannot and will not be a standard for the entire team. Here is where the power of the story point kicks in.

In Agile development, estimations are performed as a team effort as part of special sessions such as Backlog Grooming or Sprint Planning (since it’s Agile, estimations can be performed in either session) that take place during each sprint in order to construct an estimated backlog of user stories that are estimated in advance.

When a new team starts implementing a project, they must first participate in a story point calibration meeting so that everyone in the team has roughly the same conceptual idea of the complexity and effort that is implied by each story point value.

During the sprint meetings the team then assign story point values to stories in order to indicate the complexity of the story and the effort required to implement it. This allows for the correlation of stories based on their perceived story point estimation.

Imagine having an old scale in order to assess the weight of several household items such as a cup of coffee, a pen and a smartphone. By using the scale you can’t get exact numbers with regards to the actual weight of the object, but you can observe that a pen is lighter than a smartphone, and that a cup is more similar in weight with a smartphone that with a pen.

Applying this way of thinking allows development teams to assign “weight” to user stories. As these sprint meeting progress, the estimations will become better and better as developers will have a metric to correlate agains. If a creating a registration form component was worth 5 points in the previous sprint, a login form should have pretty much the same level of complexity and thus should be worth the same number of points.

Velocity

In the Planning meeting, the team usually decides what will be implemented over the course of the next iteration, and so the team “commits” to a number of story points that they think they can deliver as a functional team. These story points are known as the team’s velocity.

The concept of velocity shows how many story points can a team deliver over an iteration and it’s the most reliable way (at the moment of writing) for estimating projects.

As in maths everything regresses to the mean, so too will the team’s velocity given a large enough sample rate, which means that in time, the average team velocity will become constant.

Scaling teams

One of the most important advantages of story point estimations over individual hourly estimation is the ability to scale. As we are talking about an industry in which development teams are composed out of individuals having different working habits and different efficiencies, our goal is to find out how adding or removing a member from a team would impact the overall project. This is a crucial aspect to take into consideration when planning project deadlines as during the lifecycle of the project situations in which developers are either added or removed from the project are quite common.

In the previous example, we found out that a team of 4 developers averaging a velocity of 80 story points / sprint would finish up a 1000 story point backlog in 12.5 two week iterations. Based on this example, and ideal case would be that each team member averages around 20 story points per iteration.

Adding a new member to the team will allow you to see exactly how it impacts the teams performance. The ideal case for adding another member to the team would be to push the team’s velocity to 100 story points. This means that the project will be done in 10 two week iterations.

The ideal case for removing a developer from the team would be to drop the team’s velocity to 60 story points, which would mean that the project would take 16.6 two week iterations.

Estimating costs

Calculating estimative development costs can be done by first dividing the total number of story points estimated to the velocity of a team in order to find out the number of iterations needed, and then multiplying the number of iterations with the total number of development hours that will be billed by the software development company.

Let’s take an example

Let's say that the stakeholders alongside the development team have estimated the backlog in advance to an amounted 1000 story points.

The mature development team is composed of 4 developers and has an average velocity of 80 story points per two week sprint. Each member of the team works according to an 8 hour schedule.


The most common billing strategy that software development companies use is the billing based on day worked by developer. Let's say that the development company charges 400 euro per developer per day (meaning 50 euro / hour).

Ex.

This means that the project will take up 1000 / 80 = 12.5 two week iterations which means around 6 months and one week total time or 125 working man-days.

The total cost of development is thus calculated: 125 working days * 4 developers * 400 euro per day = 200.000 euros

Analyze in retrospect

One of the most important practices that is part of agile methodology is the fact that teams participate in retrospective meetings. These meetings aims to analyse situations that have been part of the previous sprint which could have been avoided or done better by the team members or by the active customer representatives that are involved with the project.

First of all, retro meetings are a great place to clear tensions that exists at team level, by allowing team members to express their negative feelings (as we are emotional agents by design, this happens a lot).

Secondly, retro meetings evaluate overall sprint level impediments and analyse reasons why velocity can be impacted. This is done in order to raise awareness and to improve overall estimations. By having team members aware of multiple fail points and issues, their estimation would gradually become better and better.

Furthermore, retro meetings straighten the bonds between team members and stakeholder representatives and gets everyone on the same page. Usually in large organisations a phenomenon that happens is that a lot of members partake in power struggles and conflicts which cause them to lose focus over what’s being delivered.

Retro meetings thus ensure that everyone has their eyes on the ball

Conclussions

Recent years have brought up ways of developing software that a dacade ago would have been deemed utterly impossible. There are large companies that really on an adapted versions of the ROWE (Results Only Work Environment) model in order to develop software solutions. Surprisingly companies such as Best buy who came up with this model have renounced it for the lack of productivity while companies such as Atlassian or Google are prospering by using it. It’s more a matter of using what works for the specific scenario.

The main key to success in developing impactful software solutions is the calibration of a business to business workflow that leads to mutual benefit and quality on both ends of the partnership.

This is what we understand by business agility and that is why here at abac, just as software architecture suggests relying on abstractions as opposed to concrete implementations, so too is our focus contoured around the creeds that govern agility more than the textbook implementations resulting from various companies having different business strategies.

We think that an appropriate mantra for being truly agile in business would be :

“Whatever floats the boat (product)”