Skip to main content

Readjusting the story point value of a user story after it has been completed

Last post 02:48 pm June 21, 2013 by Millard Ellingsworth
4 replies
03:05 pm June 11, 2013

Hi,

I am trying to get a good grasp on the velocity of my team and I was wondering something. Sometimes, my team works on user stories that turn out to be much bigger or much smaller than they thought. We use Fibonacci to measure stories (1, 2, 3, 5, 8, 13...) and sometimes a 2 turns out to be a 5, or a 3 turns out to be a 1 for various reasons that are then discussed in our sprint retrospective.

Is it a good practice to readjust the story point value of such a story after it has been completed? It would then make the velocity that I calculate more accurate.

Any thoughts?

Nick


03:47 pm June 11, 2013

I would recommend you read Agile Estimating and Planning.

There are times when re-estimating or adjusting estimates works and times when it has negative impacts (mathematically).

http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415



05:15 pm June 11, 2013

Hi Nick

As Ryan indicates, it does rather depend upon what you are trying to achieve. My advice is that the matter isn't quite as important as you might think. Scrum is concerned about the delivery of value, not the delivery of story points or any other measure. There is no prescription that stories, or story points, be used at all. Scrum just says that backlog items have to be sized.

I look at it this way. Transparency is important, which implies that a Scrum board should always tell the truth as it is understood at the time. This can be interpreted at least two ways:

1) Update a Scrum board to reflect the latest and best understanding of what the size is. Result: the sizes will end up reflecting the actuals very closely.
2) Don't update the Scrum board. If the sizes are estimates that were made for planning purposes, and they are subsequently changed, then the board will no longer tell the truth about how they were estimated at the time. Result: the sizes remain a truthful reflection of initial estimates.

So in very simple terms, it depends upon what you value most in your metrics. Estimates or actuals? There's no right or wrong answer.

As a very general recommendation, I'd suggest leaving the story points as they were originally estimated. If you are identifying tasks for each story, it's the sizes of the tasks that can and should be updated during the Sprint.


11:59 am June 12, 2013

Hi,

thanks for the responses guys.

I will check out that book and I will not readjust my story values. Since I see the point value as a planning tool, I will leave them as they were during the planning and use the updated task hours to measure the actual work it took to deliver stories.

Nick


02:48 pm June 21, 2013

Mike Cohn covered this topic in a blog post: http://www.mountaingoatsoftware.com/blog/to-re-estimate-or-not-that-is-…

While I second the idea of reading his book, his blog and freely downloadable presentations are also an excellent resource.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.