Re-estimate story points or not?

Last post 06:55 pm October 29, 2019
by John Varela II
12 replies
Author
Messages
06:53 am March 4, 2019

Hi everyone, 

I have the following case: 

- story was estimated for 8 story points
- didn't deliver the story within the sprint, but 85-90% is done

- story was moved to next sprint

- should we re-estimate the story? (let's say we re-estimated to 3)

- in the sprint review if the story is done than we delivered 3 story point for the complex 8 story points story (initially it was 8 st) 

so didn't we loose those 5 story points? 

05:32 pm March 4, 2019

Margarit,

To begin, you should refrain from determining any level of % complete in Agile/Scrum.   It is either "Done", or it is "Not Done".   Those are the only two states you (and your team/department/organization) should be concerned with.

The following is from the Scrum Guide.   Although it is found in the Canceling a sprint section, it also applies to your situation:

All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. 

There is a critical factor that you must keep in mind regarding story points.   They are for planning purposes only, to be used as needed to help both the PO and the Development Team determine how much work to forecast for completion in future sprints.   Once a sprint begins, story points are meaningless.   Ignore them completely.   Only refer to them again when the sprint has ended, and you need to add up the # of story points that are done, in order to feed another sprint into your team's velocity calculation.

There are many organizations though that attempt to use story points and velocity as a performance metric on the team.   This is completely wrong, since story points are valid only for planning purposes, and only germane to the team providing them.   

I have been asked in the past to increase the velocity of teams I've served.   My response has been to confirm that what they are asking for is for my teams to double their story point estimates.   Of course, that isn't what they are asking for, but it is important to push back as much as possible on the misuse of such metrics.

Hope this helps.

 

 

06:45 pm March 4, 2019

- should we re-estimate the story? (let's say we re-estimated to 3)

A backlog should always show the amount of work which is currently thought to remain.

- in the sprint review if the story is done than we delivered 3 story point for the complex 8 story points story (initially it was 8 st) 

In Scrum, valuable and “Done” increments ought to be delivered. The only purpose of estimation is to help a team get its arms around how much work it can take on.

Why do you think that you have “delivered” story points? Who has use for them? 

so didn't we loose those 5 story points? 

There ought to be a concomitant reduction in the size of the Product Backlog, since less work will remain. That’s how any work performed so far will be accounted for.

I’d suggest that there is no value in story points to either deliver or to lose.

09:57 pm March 4, 2019

As usual I have a different perspective.  On your 8 point story where you got part of the work done, why would the estimate change for that story?  Your team originally estimated based on delivering the entire story.  Just because you have finished part of the work, why does that change the estimate to finish the entire thing?  Why not carry the story over to your next sprint and finish it in it's entirety?  As @Timothy points out, points are for planning purposes only and should not be used to "judge" the team.  They planned a sprint based on what they knew at the time. I would bet that they found out things they didn't know that lead to their not finishing the story. If you absolutely have an aversion to moving things into another sprint, I suggest updating the original ticket to reflect what you actually accomplished and marking it done then create a new ticket for the remaining work that can be estimated again. 

so didn't we loose those 5 story points? 

How do you lose points when points are just an educated guess of some measure that your development has agreed to use?  There is no real value to the points other than giving the Devs a way to evaluate one story against others. 

10:17 pm March 4, 2019

@Timothy - Thanks for the above response.

There is a critical factor that you must keep in mind regarding story points.   They are for planning purposes only, to be used as needed to help both the PO and the Development Team determine how much work to forecast for completion in future sprints.   Once a sprint begins, story points are meaningless.   Ignore them completely.   Only refer to them again when the sprint has ended, and you need to add up the # of story points that are done, in order to feed another sprint into your team's velocity calculation.

I agree with you , but how do you forecast the SPs for the next Sprint ? Like in the above example 8 story points were 'not done' but some % of the work is already completed on this PBI. So we move it to the PB and re-estimate for the 'undone work' . Now during planning should we keep in mind that 8 points were 'not done' in previous sprint & avoid overestimating or should we take in account only the work 'not done' ? 

 

 

 

05:44 pm March 5, 2019

Now during planning should we keep in mind that 8 points were 'not done' in previous sprint & avoid overestimating or should we take in account only the work 'not done' ? 

My advice is to take into account only the work not done.   Forget that it was originally an 8-point item.   By focusing on the remaining work, you provide transparency into the item and the estimate.   Keeping the estimate unchanged (as @Daniel suggested) lowers transparency, and requires extra effort from the team and others when evaluating work for the next sprint (i.e. - this item is 8 points, but it really isn't an 8-pointer...).

What is critical in all of this though, is to have a conversation in your Retrospective around why the 8-point item was not completely delivered.   

  • Did the team encounter unexpected challenges?   
  • Did they underestimate?   
  • Was it too large (poor flow, work product accumulated and moved through workflow stages in a large batch)?   
  • Would they have benefited from splitting the item into smaller items (improve flow)?  
  • What is within the team's ability to mitigate or prevent a similar non-delivery situation?   What can they try and improve on going forward?

 

06:42 pm March 5, 2019

I will say that I agree with @Timothy from the perspective of using Story Points as some indicator of what is done during Sprints.  He is spot on with how it has worked for me in the past.  It is just not the way I prefer to do it. As I've said on many story point/velocity threads, I tend to view them as an estimation tool and prefer to marry them with some Kanban-ish measures like Cycle Time, Cumulative Flow, etc.  I do see value in Story Points, I just view them in other ways. So take my opinions as an opposing view and let it help you in making the right decision for your team. 

I will say that the Scrum Guide says nothing about how to measure productivity and leaves that up to individual organizations to decide. Good luck with working it out.  This is one of the hardest things I deal with when starting up with new teams.

09:07 pm March 5, 2019

Mike Cohn had a good blog post recently on this very topic:

https://www.mountaingoatsoftware.com/blog/why-agile-teams-put-so-much-e…

 

10:58 am March 6, 2019

While both opinions (Timothy's and Daniel's) provide enough arguments, my view is that Timothy's is the preferred one (and I've been practising it with my teams). The reasons I'm leaning towards it are multiple, but they all navigate around the principles set forth above by Ian.

When looking at the backlog, anyone (especially the PO and stakeholders) should have the most relevant information, based on transparency, empiricism and common sense. At the end of the day, it's human nature to know where you are, at any point in time, which is precisely why, for example, you always want to know (have an estimate) how much time / distance / effort remains of a certain initiative. 

Say you ask someone to build a two-car garage for you. They say (estimate) it's going to take 10 days. On the tenth day, it's clear to you (and everyone else) the garage isn't ready (most likely, due to the builder calling out sick on several consecutive days). Are you then, on the tenth day, eager to find out how much work's left (re-estimation) or are you willing to accept that, while the work isn't complete, no re-estimation is needed, and the garage requires 10 more days (no re-estimation).

 

As mentioned above, one of the hardest things for many teams (both starters & mature) and also organizations (especially managment) is to learn those numbers (estimation in story points) don't mean much, and value comes from other streams, and NOT from the numbers itselves. 

Also, Ian correctly pointed out the value "lost" in a sprint (via sprint backlog) is actually gained for the product (via product backlog). To be more precise, if the whole backlog is now, say 150 story points worth of work, with a forecast to be completed in 5 sprints (roughly 30 points a sprint), when you re-estimate the stories not done, the whole backlog's going to be decreased.

 

Backlog: 150 points

Sprint N start: 30 points pulled in

Sprint N end: 22 points burned down, a story worth 8 points isn't done > re-estimated at 3 (but 5 points aren't really lost)

 

Backlog post sprint N: 150 - 22 - 5 = 123 points

 

So, Margarit, the essence here (as pointed out by all contributors) is: value comes from the work itself, not from the numbers associated to it (user stories). Your team (PO, SM, DT) should focus on creating as much value as possible by reaching your sprint goals and creating done (and potentially releasable) increments. 

06:29 am October 28, 2019

If a story was NOT completed in sprint 1 (lets say 8 story points), and needs to be moved to subsequent sprint, we will then have to do the following:

1. When inside Sprint1, validate whether you can estimate the amount of work done and whether the work done can be shipped or not. If you can estimate the work done and it can be shipped, then break the stories into two (or whatever it can be broken into) stories. The first story will include all activities that were completed and hence the story can be marked as "Done" and will carry a revised estimate as per activity completed. The second story will be carrying activities which are to be done and so will be moved to the backlog. You will then estimate the second story (when needed) and take it in subsequent sprint.

2. If the amount of work done inside Sprint1 cannot be estimated or cannot be shipped, then move the story to backlog. Dont change the estimation as you still don't have any idea on how long you need to finish the story. You will then take this story as part of the subsequent sprint (based on priority). 

Why you shouldn't change the estimate when it comes to choice 2: For the current sprint lets say you committed 50 story points. Once the current story (8 SP) is NOT done and whatever % completed is not shippable, you will move the story outside the current sprint which leaves 42 story points for your velocity calculation from current sprint. Considering the fact that you didn't change the estimate for the story, you will be able to complete this story (8 SP) in subsequent sprint in a much shorter duration than originally planned. So in essence, when you take this new sprint output, you might have delivered (lets say for example) 54 Story points instead of the assumed 50 SP; That value when used for your velocity calculation (which is average of all story points output so far) you might land up in more like 48 Story Points as an example and so serves right for your velocity calculations as well.

04:55 pm October 28, 2019

Anand, this thread is full of competing opinions.   Bottom line is that you should collaborate with your team to determine what works best for them.

I assume that your post is something that works for your Scrum team, which is fine (although I do disagree with it, for reasons already stated).   What should be made clear is that you are suggesting a way to manage this situation, and not proposing a definitive way for everyone.

01:04 pm October 29, 2019

I agree with @Timothy that every one has their suggestions/opinions on how to handle this and what works for them but there is no definite rule for this.

But also what @Anand mentioned caught my attention and i somewhat agree to it. If an undone story cannot be split into done (by satisfying the DOD) and undone then its better to have same original points for it. If some % work is done and some % not , at end what matters is its still undone and cannot be delivered. Although work might become clear after spending some efforts on it and might be delivered quickly but still it has to be 100% completed to know the actual size of it. Also this can serve as a topic for Retrospective to inspect such stories which are not done. And of course velocity chart might swing down and up but like others mentioned what matters is how you perceive this data. For me its absolutely fine. 

@Timothy - Thanks , I like this blog  https://www.mountaingoatsoftware.com/blog/why-agile-teams-put-so-much-emphasis-on-being-done-each-iteration?

 

06:55 pm October 29, 2019

Just to toss in my two cents. I don't prefer splitting stories just to capture the work that was completed. However I do encourage splitting them during Sprint Planning if no work has started yet.

The purpose of a story is to identify what work is needed and how to determine when it's done. If it's not Done, then it's not Done and that's ok. The value of the story should remain intact and if the team has learned they are writing vague stories, then they should improve on that. 

The estimate is for the benefit of the team, to identify capacity appropriately. Velocity will help you obtain this by being the barometer of Done. By learning from story writing behaviors, it's possible to get better at identifying risks of unknowns/assumptions. It is better to keep the story as-is and re-point it to reflect what's left to do for transparency. We estimate a story based on amount of known effort and that effort should not be larger than the Sprint. 

If the team has incentives or is motivated by completed points, perhaps try to redirect it to delivering fully completed work and improving wherever needed.