- Published on
If Stories Get Bigger During Sprint Planning, Try a Checklist
- Authors
- Name
- Dipal Bhavsar
- @dipal_bhavsar
In my experience, work often expands when looked at in detail. At a high level, we estimate something may take five hours (or days or story points). But then when we begin the work, we realize there is more to it than we thought.
Last series Story Point Estimates Are Best Thought of As Ranges, we discussed about story point estimates best thought of as ranges. For example, if estimating with the Fibonacci sequence, an eight represents anything above five and up to eight.
But what should you do if you are already estimating that way and thinking of estimate values as implicit ranges?
One helpful technique is to start assembling a checklist of things to consider on each estimate. Every time you split a story into tasks and the work then seems significantly more than initially thought, ask why.
Turn the answers into a checklist. Sometimes the answer is that the team just messed up one estimate. Often, though, you’ll find common patterns to what the team failed to consider in creating their estimate on the product backlog item. On one recent team, the team was failing to consider the effect of changes on reports.
Your team’s definition of done can be a great starting point on this checklist. For example, if your product is to be localized into three languages, put an item on your checklist saying:
- Have we considered the impact of localization?
Other examples could be:
- Have we considered documentation?
- Have we considered getting this deployed, not just coded and tested?
- and so on.
Just before a team is ready to assign a specific estimate to a product backlog item, go over the items on the list. After a while, you can stop explicitly reviewing the checklist for each item. Instead, just hang a large sheet of paper containing the checklist in the space where the team estimates.
By turning the items your team frequently overlooks into a checklist, you can help the team create better estimates right from the start. And that will help you succeed with agile.