An estimate is a qualified guess to help people make a decision about doing work. In the Agile world, one approach to estimation has become prevalent: the combination of Planning Poker and Story Points.
Story Points are past time, according to Ron Jeffries and Chet Hendrickson, the people who created them. Hendrickson has said, “As one of the folks that sort of started all of this, let’s say that it was the best we could think of in 1996, by 2001 we had discovered better ideas, and by now it should have been kicked to the curb long ago.”
The benefit of Story Points was the speed at which the numbers could be generated, but among their many faults was that they fail to make clear the uncertainty, they’re often used as a commitment and, worse, for comparison of teams.
Commonly used estimation techniques:
- Story Points and Planning Poker
- Bucketing, which is where a team sort a large number of Product Backlog Items into clusters using numbers that look like story points – Good for sorting through a large list of items.
- T-Shirt Sizing, where the story point numbers are replaced by Small, Medium and Large. Anything classified as Medium or larger needs to be split before being worked on in a Sprint.
- Simply count the number of product backlog items. If the Product Backlog contains a number of large items, notice on average how many small items they decompose to. Use that as a rough multiplier to go from large to small.
- Abandon estimation and focus on Forecasting instead.
Blind Estimation for Planning Poker
Scrum By Example: Learning How to Estimate
Resource Links:
- Agile Alliance Report – Estimates are Terrible
- Additional Benefits of Estimation
- Bucketing stories for quick estimation
- Estimates vs Actuals
- Estimating Complexity
- Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty [PDF warning!]
- Slides on Estimation from Mike Cohn
- Story Points Revisited – Ron Jeffries
- What Are Story Points?
- When I’ve Skipped Estimates
- Wideband Delphi
- You Don’t Need Story Points
CHALLENGES
- An Hour Next Year Is Shorter than an Hour Tomorrow
- How to Misuse Velocity
- Is Velocity Killing Agile?
- Your Optimistic Bias Won’t Allow Your Estimate to Improve
- Why is Estimating so Hard?
- Why You Should Not Estimate in Hours or Days
Books
- Software Estimation without Guessing – George Dinwiddie
See Also:
*Thank you for visiting the World's Largest Opinionated Agile Reference Library. This content is created and the links are curated through the lens of Agile Pain Relief Consulting's view of what is effective in the practice of Scrum and Agile. We don't accept submissions and emails to that effect are marked as spam. Book listings may use affiliate links that could result in a small commission received by us if you purchase, but they do not affect the price at all. From experience, this won't amount to anything more than a cup of coffee in a year.
