An Effective Agile Approach for Project Estimation
Sep 18, 2015 by Vyacheslav Moskalenko
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
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?
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:
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.
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.