An Effective Agile Approach for Project Estimation

1. Home
2. Blog
3. An Effective Agile Approach for Project Estimation

 

Does the customer want to get project estimates quickly and with minimal investment in writing detailed requirements? We ask for rough estimates almost everywhere – when we order custom furniture, when we plan an apartment renovation, when we repair a car, when we ask for the approximate time of delivery, approximate costs of a complex service and so on. In the customer role, we usually request a rough estimate when we are in contact with a company representative. For many of us the question “How much will it cost?” may be the first one. I often choose to order in a company that is able to provide a quick estimate. The reliability of rough estimates can differ and depend on many factors, which in a complex situation most likely won’t behave as you predict.

Rich experience and a high level of expertise can increase the reliability of rough estimates. But if the producer doesn't have profound expertise he may wrongly think that comprehensive requirements would improve the reliability of his estimates. But don’t very detailed specifications improve your ability to provide a more accurate estimate? Even if it does, you shouldn’t worry, as most likely your understanding of the requirements is going to be changed. Let’s observe some practical examples and see some recommendations about how to make rough estimates in IT software development more reliable.

Recommended Estimation Framework

• Break down the entire project into smaller but usable features.
• Confirm a shared definition of “Done” with your customer. Usually it includes all the development activities to be completed in order to bring the feature into a releasable and usable state, i.e. potentially shippable.
• Estimate all the features using a relative story point technique and make a guess on the quantity of the story points per one Sprint, considering the definition of “Done”. It shouldn’t take more than 2-3 days to get into the project context. Having a first impression of requirements means you are able to guess the rough estimates for the entire product.
• Select one or two small features and bring them to a releasable state as soon as possible.
• Re-calculate the cost per story point (quantity of the story points by the given time) and refine time to complete the project.
• Set up an iterative-incremental process (aka Scrum) and regularly update the cost per story point.
• Regularly update your customer with fair and realistic estimates.

Even though the process may appear quite simple, however you will likely face common challenges to this effective estimation method.

Fixed Price and Fixed Scope Contracts

You would probably remark that this method can work perfectly for T&M contracts. But many customers may still prefer fixed-bid contracts. They know just a little about Agile and “relative story points” and such terminology can be inappropriate. The good news is that in most cases the customer doesn’t really care what methodology will be used to deliver the expected results. Therefore, let’s refine step #3.

Estimate all the features using a relative story point technique and make a guess on the quantity of the story points per one Sprint, considering the definition of “Done”.

We need to convert relative story points into absolute numbers, such as man-days. This requires some calculation. For instance, the initial guess is that the team of five will accomplish 20SP in the next two weeks. Thus, the cost of 1 SP = 5 men * 10 days / 20 SP = 2.5 man-days. If we have in the backlog 200 SP this can be treated as 500 estimated man-days. This would give you a high-level number that you can use to calculate project price.

Mistakes in the Initial Estimates

Mistakes in the initial project estimate are inevitable. Our customers don’t tolerate mistakes and insist that we stick with the initial contract terms. They still want to meet deadlines. Agile encourages the development team to respect customer deadlines as well. What are our options?

• Suggest adding into the contract the Product Owner role on the customer side. The Product Owner should be responsible for managing priorities. Remind your customer that initial requirements will probably change with time and by the given deadline the Product Owner would help the development team deliver the most valuable requirements to ensure the best possible ROI.
• As you will regularly deliver software in the releasable state, it will give you an opportunity to inspect the progress and request budget\scope\time adaptations. Be honest with your customer in terms of mistakes in estimates, as honesty is the foundation of a good reputation.
• The authors of DSDM methodology invented the MoSCoW prioritization (Must, Should, Could, Would). The idea of the technique is to make sure that in fixed scope\fixed time contracts there are not less than 30% of requirements in the “could/would” category. It will simplify the re-negotiation process in the case of mistakes in estimates.
• Prepare a release roadmap as an alternative to the project plan. A release roadmap will indicate which requirements will be in a releasable state during the project timeline. Use it as a main reporting tool. It will show what the initial plan was and how it is evolving over time. I’ve seen only positive results when a development organization is completely transparent to its customers.

How to Decompose Specification

Decomposition is a key to good estimates. Vertically sliced requirements with well articulated business value would help the development team to produce not only “releasable” increment, but also “usable”. A key benefit of the frequent delivery of usable increments is that the customer can evaluate your results in the middle of the project and provide valuable feedback. It also helps you build trust with your customers. Remember what the Agile Manifesto says – “Customer collaboration over contract negotiation”. The best way to engage your customer in collaborative work is to demonstrate him something that is working. There is a chance that your customer will close his eyes to contract issues or be more flexible in renegotiations if he sees positive outcomes at a regular pace. There are good frameworks available for slicing requirements:

• INVEST criteria
• Patterns for Splitting User Stories

Too Few Details in the Requirements

When we don’t have more detailed requirements in our backlog, it may stop the estimation process until we get them. A better approach is when the development team can agree on assumptions for each item in the Product Backlog and estimate based on those assumptions. Then you could send your customers high-level estimates with a list of those assumptions. Tell your customer that the estimate will probably change, as initial assumptions tend to do.

Team Speed is Decreasing

If you want reliable estimates it should include not only to development activities, but also all kinds of testing, automation, integration, documentation and other activities which would guaranty sustainable development. High-quality engineering standards should be included in any type of contract as a part of the non-functional requirements. Consequently this shared agreement will become a definition of “Done” for the development teams. It should plan into the Sprint as many work units as it able in order to meet the definition of “Done” at the end of the Sprint. After all, the increment should be not only “releasable” or “usable” but also a “high-quality” – which means free from technical debt and defects. Such practices as code reviews, unit testing, continuous integration, deployment automation, and functional testing automation usually guarantee built-in quality. Remaining estimates will be always more or less valid if the development team adheres to high quality standards.

Methodology challenges

Improper methodology can ruin all good efforts. I would recommend deploying Scrum Framework, as it has all the internal mechanics to support an empirical estimation approach. Scrum brings to the table all needed transparency. The best thing about Scrum is that it’s quite easy to find support from within the Scrum community – there are many other teams that have already tried it and can share its best practices as well as its common challenges.