This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Ask
Ideal days
Ideal days are the most common way to estimate in traditional project management. When estimating in ideal days, the assumption is “This is how long it would take if I had nothing else to work on.”
Ideal days are usually used in conjunction with some sort of “efficiency coefficient” whereby someone takes the ideal days and multiplies them by the number of actual ideal days you can get in a week. For example, in 5 business days I get 3 ideal days of work done, so the coefficient is 3/5. Therefore, if I estimate this work in ideal days and call it a 3, it will take me a week.
Story Points/Tshirt sizes
Story points are a way to decouple the estimation of size and effort from the duration of time. Instead of trying to estimate how long something will take, you estimate how big it is and let your velocity data tell you how long it will take.
If you don’t have velocity data, take your best guess in terms of how much work a team can do in a sprint, then measure the actual when you have actual data.
I like story points as a sizing practice because once the teams get their minds around decoupling time and effort, it makes it easy to estimate large amounts of work quickly.
Threshold-based sizing
Another form of sizing I like to use is “Threshold-based sizing.” This is where we set a threshold (say 3 days) and when we estimate, we are only interested in getting stories under the threshold. This eliminates distractions around precision (2.3 days vs 2.8 days) and moves the stories toward a standard size.
For stories that are above the threshold, we split them, or decrease the scope, or cut functionality until they are below the threshold.
My preference is to use a combination of tshirt sizes and threshold estimation
At the release level, I like to use chunky tshirt sizes: XL, XXL, XXXL
At the sprint level, I like to see smaller, more granular tshirt sizes: S, M, L
When we go into sprint planning, I take the stories slated for that sprint and apply the threshold method, as a double check. When applying the threshold, I use the rule of 1, 2, 3:
- 1 user story should take
- 2 people no more than
- 3 days
Maybe its a developer and a tester, maybe its a front end developer and a back end developer, or maybe its 2 full stack developers. The composition of the 2 people working on the deliverable doesn’t really matter to me. What matters to me is that we are spreading knowledge around the team so we don’t end up in a situation where “Only on person knows about this..”
What are some other ways of estimation you have seen?
