This is an old revision of the document!
What is the Basis of Our Estimating Process?
The basis of this discussion is “Team based relative size estimates” or Story Point estimation and this list assumes that as a basis. This page is all about estimating User Stories (the requirement), not tasks associated with User Stories although a lot of the ideas could easily be carried onto the task estimation in hours. From there the assumptions are:
- We do relative size estimates (how big something is in relation to something else) estimates, not duration (how long something takes).
- We use a team based approach to estimation such as planning poker or affinity (triangulation based) estimation
- We have the people doing the work doing the estimates
- We use the modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) for estimating
- All data we collect can and should be used to understand what and how we are doing so that we can get better.
It is worth delving into the notion of a relative size estimate for a moment. Most traditional estimates are based on duration, and that leads to a whole bunch of problems (see What is the Purpose of Estimation? for more information). But it is worse than that. If you have two pieces of work to day, both of which you think will take about 20 hours to do, but the first piece of work is straight forward, while the second is in an area where there is a traditionally a lot of problems, should these items have the same estimate? No, you'll probably want to put some level of buffer in place to offer a more realistic estimate in the the case of the second piece of work. This is another reason to move away from pure time based estimates.
As Daryl Kulak says:
If a development team is equating some number of hours to a storypoint, it is missing the point (pun intended). Saying, “Thirty hours equals one point” is ridiculous. If you’re doing that, just use hours for goodness sake. You haven’t gained anything from storypoints except to be able to claim to be doing “agile.”
While the approach of using team based relative sized points is counter-intuitive at first, over time teams start to build up a a table of sizes in their heads:
As a starting point a team might say “lets say a day of work is a point”. But what this really means is that particular item is also low in risk, and low in complexity.
For more information on the basis of the process see Planning Poker for Estimates from Mike Cohn. And if you want to understand the scientific basis of this approach see Why Do We Use a Story Point and Relative Sizing to Estimate.