When do we estimate in Scrum?
Hi guys,
I got a simple question: when do we (as a dev team) estimate in Scrum?
When I first learned the Scrum basics, back in 2014, I remember that it was said that the dev team was supposed to estimate during the Sprint Planning using technics like the Planning Poker or extreme Quotation.
But I am puzzled reading the Scrum Guide because it seems that estimation is recommended to be done during the Backlog Refinement activity.
Is that correct and if so what is the main reason why?
Thank you,
J.
If work is not estimated, can it be considered “ready” for Sprint Planning?
Stories can be estimated during backlog refinement on the information available at that time, however development team can re-visit the estimation (if any new information is available) during sprint planning
Oh OK thank you that was my question: can we build upon some kind of "continuous planning" or "rolling wave planning" with regular estimation activities instead of relying on an "event based approach".
So that means estimation can be done any time before or even during the sprint planning, as long as it allows the team to commit on a forecast for the upcoming sprint.
To my understanding, this also implies that we should start the sprint with just enough information about the sprint backlog to really start to work on the sprint goal. Is that correct, or should we identify the complete Sprint Backlog during the Sprint Planning (in theory)?
In my experience, emergent conception offers better flexibility and adaptation. What do you think?
J.
As @Ian said, how do you know if something is ready to pull in to a Sprint if you still haven't agreed on some level that it is understood. In my opinion, estimation is the final act of a team agreeing on what they feel the story means and the relative estimate size of the agreed upon interpretation to other stories they have in the Product Backlog. Where is the best place for that activity? Refinement. That is the entire purpose of Refinement. But if at Sprint Planning, there has been additional information uncovered, I will encourage the team to rethink their estimate. That is the empirical transparency, inspect, adapt loop in practice.
However, after the team starts working on a story, no more do you revise estimates. At that point changing the estimate is waste. However, I do revisit estimation with my teams based on past experience. "You have chosen to estimate this new story as an 8. In the last sprint you had a story estimated as an 8 and all of you said it was underestimated. So in relation to that under estimated story, do you still feel that the new one is an 8?". Learn from the experience but don't feel like it has to be perfect. A team will very seldom know everything about a story before they start.
I find it is beneficial at times to take team size estimates and compare them to similarly-estimated past items.
"You have all estimated this as 5 story points. This is a 5 story point item from 3 sprints ago. Do any of you feel that this new item is larger or smaller than the 5 point item you completed a while ago?"
To refer back to the thread topic, I believe it is critical for estimation to occur prior to Sprint Planning. How else can we support the PO determining what the Development Team might be capable of completing in the upcoming sprint?
Agreed with all above.
One worthy note: the development team is free to pull into sprints (whether right at the start or later) any unestimated item they believe they can complete (surely, upon discussion/negotiation with the PO), especially when there's no impact on the sprint goal.