Updating estimates during a Sprint
Page 14 of the Scrum Guide says:
"The Development Team modifies Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint"..."As new work is required, the Development Team adds it to the Sprint Backlog. As work is
performed or completed, the estimated remaining work is updated."
Perhaps there are at least two ways to interpret this:
1) the estimates (e.g. story points) for all remaining work should be updated during the Sprint, even for those stories that have already been estimated.
2) only the new work being brought in is estimated. The estimates for the work already planned in will not be changed. The calculation of remaining work will be based on these figures.
The advantage of (1) is that the estimated points reflect the truth as it is currently understood. Therefore if they are written on the story cards on a Scrum board, the information radiator will be telling the truth. By the end of the Sprint they will be very close to the actuals. The disadvantage is that better estimation (and therefore analysis) during planning is potentially discouraged, since the team know they can always change the estimates as they go along.
The advantage of (2) is that there is a clear inspect/adapt opportunity at the end of the Sprint to improve estimation (and analysis) during planning for the next Sprint. The disadvantage is that the board is less honest, because it will be showing story point estimates that do not best reflect the truth as it is currently understood.
Many teams adopt a compromise approach whereby tasks are broken out for each user story, and only the estimates (often in hours) are updated. By the end of the Sprint the task estimates will effectively be actuals. However the story points themselves will not be amended.
What are your opinions on the best way to update estimates during a Sprint?
This is how I've interpreted the following part:
The Development Team modifies Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint"..."As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated.
- As new work is required = extra tasks for a specific User Story that is needed to complete the User Story.
- As work is performed or completed, the estimated remaining work is updated = when tasks are performed or completed, modify it to which you think it is correct.
Usually in my teams we attend to guestimate User Story relative from each other by using the Fibonacci numbers and subtasks by hours or sometimes nothing.
I’m my opinion it doesn’t really matter whether you use time, complexity, t-shirt sizing or even nothing, in the end it’s all about completing the stories that the team had forecasted. I’ve seen teams without any indication doing extremely well and teams using time, complexity etc. fail miserably.
Wearing my Coach's hat I need to answer your questions by asking more questions (don't you just hate that?):
1. What will the team gain by updating story points in the middle of a sprint?
User Stories are measured in relatively abstract terms: points, t-shirt sizes, ideal team days, etc. Any "truth" in the measure is a reflection of the team's long-term performance (velocity) not day-to-day progress. In my experience, revising user story estimates after the sprint adds no value to the process and can introduce confusion when planning the next sprint. I'll agree with Chee-Hong that "as new work is required" refers to the tasks needed to realize User Stories. These tasks are measured in hours (a measure of "work"). The work estimates (hours remaining) are updated daily for/during the daily stand-up, so when new work (a new task) is added it is estimated. This is not a compromise: it's Scrum.
2. Do I understand correctly that the "new work" you are adding to a sprint reflects new user stories?
If that's the case I have only one comment: User Stories are measured in more abstract terms: points, t-shirt sizes, ideal team days, etc. Any "truth" in the measure is a reflection of the team's long-term performance (velocity) not day-to-day progress. In my experience, revising user story estimates after the sprint adds no value to the process and can introduce confusion when planning the next sprint. We don't add stories to a sprint in progress.
The cool thing about relative estimation is that it will autocorrect itself when you apply it within an iterative process.
A couple months ago I did I small research on relative estimations and it’s quite interesting to see what happens with initial estimations and how that affects the planning.
After my research I go into the Sprint Planning Meetings with a whole other intention :D
But who is responsible for updating the estimates during a sprint?
Ian, responding to your original question. Btw, thank you for all of your contributions to the forums -- I find your posts to be very informed and informative too.
Scrum and the Scrum Guide does not really speak directly "on point" on this subject, so you know what that means... ;-)
Frankly, I think sticking to reality is the best approach. Estimates are estimates and no one precisely knows how much effort does the actual implementations of most of stories need. So at the end of the day the team or individuals who underestimated a tricky story and have not delivered it ontime might be challenged by stackholders. So it makes perfect sense to be honest and say if something has been wrongly estimated even if whole the team disagree with you. The thing that does not add value is dishonesty, and/or being in bounds of what you guys have wrongly estimated and insisting on that wrong thing. I personally think the people who are working on some stories surely are the best people who know how many points it really is and the rest of people who disagree with them can give it a try and do those stories themselves if they think doing those stories is eady.
To grumble a bit I would say some people are just sitting beside the ring and saying "do this, do that". In reality these sort of people are nothing but noise.
Stick to reality guys.