An estimate is a prediction of what will be delivered, how much it will cost, and when it will be delivered.
Estimating supports decision-making throughout the life of a project, for instance:
- To evaluate the business case.
- To plan the constituents of the next release.
- to decide what can be worked on in the next timebox.
The iterative and incremental approach of Agile means that estimates made early in the project will be base on limited knowledge – with this being enhanced throughout the lifecycle as understanding grows of the work that's required.
The Four Estimating Principles
1. Know the purpose
You must understand why you are estimating and only estimate when necessary, for instance to make a decision or change direc.
The purpose of the estimate should drive the level of detail, the time to be spent on it, and the techniques used. The key here is to do just enough to satisfy the need so that a decision can be taken.
2. Challenge and validate the estimate
Estimates should be created collaboratively and validated by the use of more than one technique.
And they should also be checked regularly throughout the project, based on experience and feedback.
3. Expect change & uncertainty
Projects have to deal with uncertainty and unknowns, and estimates must acknowledge that by being upfront about any risks and assumptions that have been made.
4. Take ownership
The project team should create the estimates as they have the knowledge and will be responsible for delivering the work.
That said, those responsible for steering and leadership must decide how much estimate risk they are willing to accept.
1. By Analogy
A project is estimated by reference to its relative size, compared with similar work that has been delivered by the team and the organisation.
Any equivalence regarding the following factors should be considered when deciding which project to benchmark against:
- The number, size and nature of the business requirements.
- The possible solutions and its architecture.
- Its use of tools and technologies.
Estimating by Analogy is a good approach to use when the speed of producing an estimate is more important than its precision, e.g. to decide whether an idea is worth taking forward in the pre-project stage.2. Top-down
This approach focuses on assessing a product or service based on its external features — with just enough understanding to estimate size without needing to analyse every detail.
The main elements of a product or service are identified here, such as the key delivery components and the high-level requirements. These are then sized using techniques such as Story Points or T-Shirt Sizing (see the next section), and measures of effort or speed of delivery are applied to give an overall estimate.
Given the inherent uncertainty of using this style in early phases, the estimate is often provided as a range, e.g 125-175 days, or $100,000-$150,000.
The benefits of this approach are its speed and focus on the full scope of the estimate, rather than the detail.3. Bottom Up
This approach involves breaking down the product or service into the detailed work steps needed to deliver it – with the level of decomposition being adjusted according to the precision that’s required.
Each step is then sized (for instance in person-days) and subsequently aggregated to give an overall estimate.
This approach is best used when detailed information is available, and the estimating and planning horizon is short, for example when estimating for a two-week timebox.
The benefits of this approach are that it provides a good understanding of the product or service and the work that’s required, and that it may offer a more accurate basis for planning.
The following techniques can be used to support these approaches
1. Story Points
This technique may be used for top-down estimating.
A Story Point is an abstract number that's assigned to reflect the perceived effort to complete a User Story, based on its complexity, risk, and the likely effort required.
Planning poker is a popular, consensus-oriented way of calculating Story Points, using relative estimates to size User Stories against each other.
Here members of the delivery team are each given a deck of cards with values representing Story Point numbers in a Fibonacci-like sequence, e.g. 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, and Infinity.
Once a User Story has been discussed, each person chooses a card from their deck showing the number that matches their Story Point estimate for the work that's required.
When everyone's ready, all the participant's cards are revealed simultaneously, and any significant differences (typically the highest and lowest estimates) are discussed.
The process is repeated until consensus is achieved around one or two points on the scale (in which case the higher number should be used). If that isn't possible, then the User Story should be put aside, pending further information
This activity continues until every User Story has been estimated — following which these steps are carried out:
|1||Compute the total number of Story Points, e.g. 100.|
|2||A facilitator seeks agreement about the number of Story Points that the team can deliver in a fixed-length timebox, e.g. 20 Points in a two-week timebox. This is called “the velocity”.|
|3||Divide the Story Point total by the velocity to determine how many timeboxes are required, i.e. five timeboxes, run over a 10-week period.|
|4||Calculate the total effort and cost of developing and delivering the solution based on the size of the team.|
The benefits of this technique are that it:
- Creates a forum for discussing and understanding the requirements.
- Allows the team to participate in the estimation exercise, and in a way that's independent of their individual capabilities. Doing so tends to improve the accuracy of estimates, especially as they're the people they'll be doing the work.
- Provides a sound basis for measuring progress once the project is under way.
2. T-Shirt Sizing
This technique may be used for top-down estimating.
A facilitator works with the delivery team to allocate every User Story to a size in a range of:
|2||Discuss and agree on a “table of effort” that shows how many person-days are required for each of the T-shirt sizes.|
|3||Multiply the numbers from Steps 1 and 2 for each T-shirt size.|
|4||Aggregate the numbers from Step 3 to get the overall delivery estimate.|
The benefits of T-shirt Sizing lie in its simplicity and because the estimates can be revalidated and adjusted throughout the delivery lifecycle.
A drawback is that it can't easily be used in velocity calculations to demonstrate progress and a projection of future delivery.
3. Days effort
This technique can be used for bottom-up estimating.
It's particularly useful where the estimating horizon is short, the scope of the work is well-understood, and the estimators are the people that are responsible for delivery — for instance, at the start of a four-week timebox.
|1||Break down the work of the timebox into the tasks that are required to deliver it.|
|2||Decide how many person-days are needed for each task.|
|3||Calculate the total number of person-days.|
|4||Compare the total of this effort with the team's availability in the timebox to assess whether it’s achievable – adjusting the scope of the timebox if necessary.|
The benefits of this technique are that it provides additional insight to the work that's required and can be used to measure progress once the timebox is underway.
Agile Business Consortium
- [email protected]
- +44 01233611162