Scrum re-estimation of stories

Question

Every day, after the stand-up, my team and I update our estimates for each story. I have a feeling that there is something wrong with the way we do it, so I need your help.

This is how we do:

Story A estimate: 24 hours (8 hours per day - we use "ideal days" as the measure)

• Day N: developer starts working on Story A in the morning (8 hours of work completed by the end of the day)
• Day N+1: Story A re-estimation = 16 hours (one workday taken out of Story A, from day N)
• Day N+2: Story A re-estimation = 8 hours (one workday taken out of Story A, from day N+1)
• Day N+3: Story A should be done by now. But it's not. The developer reckons it will take another 3 hours to finish. We update the story on the whiteboard and burndown accordingly.
• Day N+4: Story A took the whole day to be finished instead of only 3 hours! Now it's done. The difference, 5 hours, is completely unaccounted for in our planning.

How should we be daily re-estimating our stories?

Answer 1

The difference, 5h, is completely unaccounted for in our planning.

Yes, it is accounted for implicitely because the following tasks are delayed. If there was a burndown chart just for that developer, you'd notice that the curve has remained "flat" for one day while it would have gone down if the developer had finished it early enough to take on another task.

There's nothing wrong with the way you're re-estimating during daily meeting, re-estimation is more about figuring out if we can make it for the end of the sprint than it is about tracking the exact lateness of each task. All you need in Scrum to be able to adjust your plan on a daily basis is something that indicates Sprint progress and how far you are from meeting the Sprint goal (typically, a burndown chart).

Answer 2

The question you should be asking is: Should we be reestimating our stories?

I would argue that you should allow the Agile "magic" to balance your under- and over-estimations over an iteration when calculating your velocity for the next (which is the only reason to correct a value). See Mike Cohn's Agile Estimating and Planning for more info.

However, there is a case where you should reestimate: where something you've learned about a category of work adjusts all estimates going forward.

eg. If adding a column to a database is estimated to take an ideal hour, but it turns out to take 3 hours because of some factor that no one considered and it looks like that factor will apply every time you're adding a field to the database then all estimates for work of that nature should be adjusted, including the one you are working on.

Answer 3

What I've found to be most effective is:

• Size stories by points (or T-shirt sizes.)
• Re-estimate any story in the product backlog at any time (but especially right before sprint planning.)
• Do not re-estimate stories that are scheduled for this sprint -- feel free to bring up concerns at standup, but do not change the estimates.
• Use yesterday's weather to schedule sprints

If stories are entering the sprint with bogus estimates, pre-sprint planning re-estimates will let you fix them before they become an issue. If stories are taking longer than expected because the team is too optimistic, yesterday's weather will keep you on track.

Daily re-estimates of what's remaining tend to be totally bogus, as you described in your question. Work completed/remaining is a bogus number designed to make it look like you're working "hard enough". Far better is to ask, "When do you think you'll be done," and make clear that if there's an issue with a story, that the team will step up to help.

Answer 4

I think this is not a problem. Rather, it may be lack of experience. The more you follow scrum, the more developers get used to provide preciser estimates. This is our experience of implementing scrum after 5 months.

In planning poker sessions, our developers were suggesting very diverse estimations for each PBI and each task in first sprint. However, now, we're almost equal on the time and estimation. How long have you been using scrum? If not that much, give it some time. But if it's a long time, then as @pdr suggested, consider adding extra margin for tasks with higher risks. For example, each time our team wants to make a piece of UI cross-browser, we pass our estimation. Thus, we always multiply cross-browser tasks' estimation by a factor to get sure we can cover it.

Answer 5

Re-estimating committed user stories during sprint doesn't make sense. It only waste your time. You already did commitment and it doesn't matter if you do re-estimation or not.

The different situation is with user stories which are not committed to current sprint. From time to time it is good to make re-estimation (no more than once per sprint before the planning). Situations why it can be reasonable to re-estimate can be:

• Product owner changed any user story
• Product owner split or merge any user story
• Product owner added user story
• You have some additional knowledge which was not available during last user story
• You found that some user stories are related and you already did part of another one not committed yet
• etc.

You don't need necessarily re-estimate every user story but you can. For complete re-estimation you usually need some fast method. Planning poker can be damnly slow, inefficient, boring and sometimes also inaccurate if you take more then 10-20 stories to estimation. Alternative can be Magic estimation.