It’s OK to change a story point estimate but I caution to be very careful in doing so. If you change an estimate after sprint planning you will then calculate velocity using at least one user story whose story point estimate came after a great deal of thought. THis will tend to overstate or understate velocity relative to the product backlog items, which are each estimated without that level of thought.

Thanks for your great knowledge sharing. I tend to only have one sticking point in my mind when it comes to going from story points on the backlog to task hours in a sprint and would love to know what should be done.

It basically stems from the conclusion that people tend to either be chronic under-estimators or over-estimators – hence the use of story points and actual velocity in the first place to give a real estimate on completion date based on empirical data.

The confusion I have then is when a team commits to what it can achieve in the sprint by breaking stories into tasks and hours. This is then limited by available hours for the sprint (i.e hours of actual work each day * number of days in the sprint * number of people – holidays etc).

Now, what happens if the team tend to overestimate/underestimate, the velocity based on history says that they should be able to complete X stories, but after they break it down they say they will only be able to handle Y. Y may consistently be above or below X.

What should be done in this case? Do you resign to always pulling extra items off the backlog in the sprint once they finish early (in the overestimation case), or alternatively find that the burn down is never completely burnt in the sprint (in the underestimation case)?

Also, is it perfectly acceptable to change the story points associated to a story once further in depth analysis has been carried out in sprint planning or should these remain unchanged?

Thanks
Hamish

Excellent post. Our team (who you trained before I joined it) has also been doing what Chris mentions. As PO I would own the backlog and the stories in it. Devs would estimate the stories in points. Based on team velocity (story points per 2 week sprint) the team would commit to the top ‘n’ stories by priority.

The dev pair working on each story would then break it down into tasks (with hour estimates). Once number of hours remaining for all tasks associated with a story got to 0, we moved the entire story to “Ready for Demo” status. The Demo was basically an evaluation of our user acceptance criteria for the story and we could it “DONE” if the evaluation passed.

All in all, this process worked pretty well without us having to estimate at the hour level. Also we had very clearly defined boundaries, PO owned the stories and devs owned the tasks it comprised off. But as Chris said, all these devs were well seasoned, both as technologists and as SCRUM practitioners

In the meantime, I’ll add writing something about sprint planning as design session to my list of topics to write about.

I see too many teams breezing through planning and losing the opportunity to really make sense of the work they’ll be doing and coming away with a real solid understanding of their “commitment” (in quotes because I think this commly results in something less than true commitment).

Do you accept requests? I’d like to see a blog focused on sprint planning as a design session.

Thank you for the great post. A team that I was part of in the past actually did complete Sprint [iteration] Planning without breaking down into tasks. It was interesting how we could come up with a few pieces of relevant information on each user story and a couple doodles then decide that was enough as a team. I must say this was a team of people who had been doing Scrum for over 4 years along with XP practices longer than that and were well seasoned technologists too. I have not been part of a team that has done this since.

That can be the case for some projects. Fortunately, though, when it is the case, that part of the sprint planning meeting usually takes only a few minutes.