Mike's points are dead on. You estimated to help make decisions on what NOT to do.If a feature is broken down to12 stories estimated at 150 points and the team's velocity is 75, then the product owner knows that it will cost her at least two sprints for the feature. Why "at least"? Because the feature's full sizing can only be determined once the requirements are fully documented in the stories and in my experience, the full sizing only goes up once these details are flushed out. But the point is, if the product owner finds the estimate too expensive, she can either lower its priority (e.g., don't do it) or simplify the requirements (which should lower the estimate).
The Estimating Process
Here is the process I advocate:
- Teams, departments, or organizations should define metrics and a process to derive or demonstrate business value. The product owner is expected to prioritize the high level feature backlog based on the business value.
- On seeing a new feature prioritized, the leader(s) from the technical team should break prioritized feature on the feature backlog into Story Stubs - story names, without details. For "simple" features, this usually isn't a difficult task for experienced teams but for more complicated ones -
- It may require sessions with the Product Owner to get some more details
- It may require breaking down the feature into smaller ones, some that might be easier to break down and be more important.
- It may require some R&D (spikes) to help flush out an approach.
- It may fall out of scope for what the team (or teams) can perform - either by size, skill, or complexity.
- Assuming the feature now has story stubs, the leaders of the technical team should now be able to assign estimates to the Story Stubs.
- Mature technical teams will often review story stub estimates. Is the feature fully broken down? Are there architecture considerations? Should technical debt be addressed with the feature?
- The Product Owner should then review, and has several options:
- Accept the estimate and move the stories to the story backlog. (Note: on the story backlog, a separate process should be used to document the stories with acceptance criteria and to size the story.)
- Lower the priority of the Feature or remove it from the backlog.
- Discuss the estimate to see if assumptions were wrong, or if the feature's definition can be simplified and yield a lower estimate. If this path is taken, the newly refined feature should be prioritized again on the feature backlog for a second estimate.
Why Estimation works?
- It's only done after the Product Owner has prioritized features by business value. So the most important features are estimated.
- Good estimates require some thinking. Breaking the feature to stories and accounting for some of the complexity is one way to insure that estimates are grounded in some reality. Contrast this with an estimate at a feature level - "that looks like three sprints" - that provides no details or assumptions.
- Stubbing and estimating are low cost activities - often involving only the technical lead for the team. The activity can be time boxed. If the feature is expensive, it can be reevaluated or killed without too much investment.
- Going back to the first point, the process forces prioritization - first to get the feature estimated (don't try to estimate everything because estimates require some thinking!) and then to review/prioritize before adding the stories to the story backlog.
- It also forces good behavior - if the product owner asks for too much and the estimate is high, the process to simplify the feature definition and estimate again will delay development of the feature. Hopefully, this encourages the product owner to request minimal feature sets.
- Stories that make it to the story backlog go through a more expensive process - writing, reviewing, and sizing the story. Again, this process insures that only the most important features, now with accepted estimates, are sent to the story backlog.
- The features, broken down with stubs and estimates provide an architecture team visibility into future needs. It gives them room to consider future architecture needs and process to insure architecture requirements or technical debt are factored into estimates.
- Ultimately, to the extent that "estimates" are not as accurate as "sizes" (again, sizing in this process is done on the fully written story, by the development team, and for stories on the story backlog) - the product owner has a second chance to review and prioritize based on this added information.
So if you're only sizing fully written stories, consider implementing an estimating process to make teams smarter and more efficient.