- Published on
When Is the Worst Time to Estimate Story Points?
- Authors
- Name
- Dipal Bhavsar
- @dipal_bhavsar
This week, I’d like to encourage you to correct a common mistake I see teams make. If you’re making this one mistake, you are probably
- Making it difficult for your product owner to prioritize
- Spending too long estimating product backlog items, even with a technique like Planning Poker What one, easily fixed mistake could be causing both of those problems?
Estimating your product backlog items during sprint planning meetings. Let me explain why doing this is so bad.
First, when a team estimates product backlog items (typically by playing Planning Poker) during sprint planning, the product owner does not have time to adjust priorities based on the new estimates.
Product owners should select the work to do next based on something like a simple return on investment calculation. Product owners should compare how badly they want an item with how much it will cost (in effort, as estimated with story points). Something highly desirable that is estimated to be 40 points may be prioritized below something moderately desirable that only costs 2 points.
Without knowing an estimate, product owners cannot make these decisions. And getting the information during sprint planning is too late for a product owner to make anything but a snap judgment about the work of the coming sprint.
Further, when teams estimate product backlog items during sprint planning, my experience is that team members spend way too long doing it.
This happens because the team is mentally prepared for the deeper discussions that characterize sprint planning and task decomposition. And so they start having those discussions while estimating story points. And this means they spend more time estimating product backlog items than if they’d done that outside of sprint planning.
So, if estimating the story points (or any unit) for product backlog items should not be done during sprint planning, when should teams do it?
Hit reply and let me know your thoughts. I’ll share mine with you next week.
Until then, I hope you and your team are succeeding with agile,