We previously looked at how to perform agile estimation, we also dipped into the cone of uncertaintyand explained how it is used in the development lifecycle (and the weather in our intro to agile estimation).
To quickly recap, the cone of uncertainty tells us that over time our estimates become better and more accurate (but never perfect!). Estimates at the start of a project can be off by a factor of 4, an original project duration of 1 year could in reality be anywhere from 3 months to 4 years. Understandably this is a pretty difficult idea to work with when communicating with your business, as other departments will have work to do around this estimation (think training events, PR, advertising).
The cone of uncertainty tells us that our estimates will get better over time, as a result of a number of factors:
- More information becomes available
- The product begins to take shape, we get a better perspective on functionality
- The team has had time to gel and work together
Start Measuring
As we have already discovered, our estimations are never perfect even towards the end of a project, they just get better over time as more information becomes available. However we can introduce more accuracy into the cone of uncertainty by adding some reality to your estimation.
You should already be re-estimating at the end of each sprint, and as we work through our sprints our estimations are becoming more accurate as more information comes to light. As mentioned before we are also getting a better idea of the teams productivity as they work together over longer periods of time.
During this process there are some important metrics that can be collected to facilitate more accurate agile estimation. (The metrics are the data points to collect during each iteration of our project)
Product backlog size
The size of the backlog at the start of the iteration. This reflects all items that are left to complete the project. This will fluctuate throughout the life cycle of the project, as the development team will complete work, things may be added or removed.
Committed backlog items
At the start of each sprint the development team will select items from the backlog to complete during the sprint (sometimes based on priority, sometimes led by product managers).
Backlog items completed
The number of items from the backlog that have been completed during the last sprint. This gives us an idea of how the development progressed.
Team velocity
The fluctuations in the team velocity as the project progresses.
Items added to backlog
How many new items have been added to the backlog. This is not the number of items added to an ongoing iteration (you shouldn’t be doing that) rather the items added to the product backlog during the iteration or at the point where the iteration was completed.
Items removed from the backlog
Typically removed because the product owners of developers decide they are no longer required.
Number of bugs added
The number of bugs added to the backlog during each iteration.
Lets apply some values to the above data points to start to get an idea of what this will look like:
Lets assume we have just started a new project and we have just finished our 1st sprint. Our backlog had 100 pointsworth of work at the start. The team committed to completing 10 items during this 1st sprint but only completed 7. As this is the first sprint, the team velocity will be the same as the items completed number (7).
We also added the number of additional items that were added during sprint 1, and the number of bugs introduced to the backlog by the developers. As this is the 1st sprint, our number of items removed from the backlog is likely to be 0, at least until further sprints when the project begins to mature.
TheSprint estimate to completionvalue tells us how many sprints we need to complete in order to finish the current backlog. We get this value by dividing the size of the product backlog by the team velocity.
We started our 1st sprint with 100 items in the backlog, the team completed 7, bringing the backlog size down to 93, but in the process 5 items were added and we introduced 1 bug (Total backlog size 99). Now we can divide this number by the velocity99/7=14.1429.