Estimation in Agile Projects

Definition of Project Success

Scott W. Amber published a survey in 2007 on project success in Dr. Dobb’s. You can actually download the raw data and other analysis from Scott’s website as well.

As analyzed by him the following numbers talk a lot about what people think about the success of a project.

In his survey he found that:

• 87.3 percent said that meeting the actual needs of stakeholders is more important than building the system to specification.
• 87.3 percent said that delivering high quality is more important than delivering on time and on budget.

Clearly the majority of the people thought meeting the estimated date, cost and effort is not the top-most criteria for the success of a project. Rather, delivering high quality software that meets the needs of the stakeholders and users is the top most priority.

Fallacy of Estimation

Often we are asked to estimate the size or effort for delivering a project. In the Agile world the requirements are expected to evolve over a period of time so the work to be estimated is often a moving target and changes over time. The “Cone of Uncertainty” and related statistical data shows that the estimation at the beginning, during the project inception can go wrong as much as 4 times than the actuals and becomes better over a period of time as we move along the development lifecycle. While estimation is a necessary evil in most of the software development projects, it makes a lot of sense not to get hung up on spending too much time and effort in trying to be more and more accurate as it can always go wrong because of several unknown unknowns. Even if the scope can be nailed down completely, nobody falls sick from the team during the entire project timeline, the technology choice is as robust as it was assumed and everybody kept their commitments as per the assumptions during the estimation, the estimation can still go wrong.

Consider the following picture. If we need to estimate the length of the line ABC with respect to the base AC and if we know ABC is an equilateral triangle, we can very easily say that it will be double the length of AC.

AB + BC = 2* AC

Take the mid points of each side and join them. Again the side AD + DF + FE + EC is twice as long as the side AC.

You can go ahead and continue this process for ‘n’ number of times. More number of times you divide the equilateral triangles as indicated, you get closer and closer to the base line AC and slowly the line above becomes impossible to be differentiated from the line AC. BUT even if you continue this process for a million times, the length of the line above will still remain to be twice as long as the base AC.

If you are estimating the length of the line above after doing this operation a million times, whereas the actual line is the base AC, you will always perform 100% under estimation assuming both the lines are of same length. You can’t figure out by any scale that the above line is double the length of the base line AC.

Estimation is required for planning and tracking but too much time and effort spent on it as well as too many dependencies on the estimated values are wasteful and may turn out to be very risky. The best approach for project execution will be to define a small piece of the work, estimate, design, code, and test the piece of work and get feedback from the client. And then pick up of the next small piece of work. That way the inherent risk of estimation error, complexity and unknown unknowns’ impact can be reduced considerably.

Alliance Agile Framework enables the work to be divided in a series of user stories which are then prioritized along with the customer for bringing in early and faster business value. Our approach focuses more on “Being Agile” instead of “Doing Agile”. The focus we have in our Agile Development Framework is on delivering business value instead of following prescriptive Agile processes where the team starts being Agile rather than doing Agile. While estimation is a part of the process, it just provides high level indicators for planning and tracking.

As the team gains more knowledge about the system and various contextual aspects the plan is reviewed along with the estimation for reduction in the variance of the delivery plan and the actuals. In an Agile project, estimation & planning is considered to be a just-in-time process instead of a big upfront waste of time and effort at the beginning of the project.