Estimation is inaccurate by nature. Traditionally, hours and days have been used to provide an estimate. The problem encountered with using hours and days to provide an estimate is that they are absolute, even when given relatively, which inherently imply commitment. In an agile environment, we use a Story Point to provide an estimate. Story Points are relative and unit-less. For this reason, relative estimation doesn’t change over time and remains relative.
Story Points typically follow the Fibonacci sequence (1, 2, 3, 5, 8, 13…) this limits the number of estimation choices encouraging a team to collaborate to come to an agreed upon estimate. Limited estimation choices speed estimations, promote consistency and become more accurate when triangulating against known user stories for comparison. During collaboration, the sprint team can clarify unknowns that may be well understood by other sprint team members, thus bringing the sprint team to a level playing field. Relative estimation is achieved through triangulation, and based off knowns, unknowns, complexity, overall effort and risk.
Story Points remain accurate over time despite changes to the sprint team.
For example: A junior sprint team estimates their backlog of user stories in Story Points and ideal hours\days as such:
|User Story||AgileStory Points||TraditionalIdeal Hours\Days|
|Story A||13||2 months|
|Story B||5||2.5 days|
|Story C||8||2 weeks|
|Story D||3||16 hours|
|Total||29 Story Points||10 weeks, 4.5 days|
The sprint team today can complete 10 points a sprint, so we can plan that 29 points will take the sprint team approximately 3 iteration cycles to complete all the work.
Let’s consider this scenario:
The sprint team is known to produce 10 Story Points per 2 week iteration cycle. Over time, this sprint team becomes more experienced, they gained 1 new developer and they can now produce 14 story points per iteration.
Based on the two sets of estimates above, can we plan the remaining stories?
With Story Points, we know that there are 29 points remaining to be completed, and the sprint team on average can complete 14 points per iteration. We can plan for the team to complete the remaining work in approximately 2 iterations. 14 points iteration cycle 1, 14 points iteration cycle 2. 1 point remains. The estimates stayed accurate despite the team changes and the growth of the team’s expertise over time.
It is very difficult to plan the remaining 10 weeks, 4.5 days due to the team’s changes in resources and gained experience. The ideal estimates are stale and inaccurate. Unless we re-estimate the remaining work continuously, they are no longer valid to plan with.
No matter which method you choose to use to estimate work, estimates are meant to be a rough guess. Estimates are inaccurate by nature, unit-less estimates like Story Points are no more or less accurate at the moment in time of estimation, but they sustain their accuracy over time which in turn, absolute ideal estimates like hours\days\weeks diminish over time.
Iterations and releases can be planned and adjusted as teams increase and decrease their abilities to complete work within their planned iterations. This allows us to re-plan with confidence continuously throughout a release cycle allowing for continuous improvement and keeping us as accurate as possible when planning with estimates.
Agile embraces constant change, inspect and adapt – Story Points allow us to remain agile.
To view more information on applying agile techniques by Kristen Varona, visit my slides at SCRUM Estimation .