Re-estimate story points or not?

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.

- 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.

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. 

@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' ? 

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?

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.

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

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

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. 

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.

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.

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?

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.

No.. We should not re-estimate Story points. Story points are not for Effort that your team has completed per sprint. Story points, these story points or estimation shows the business value to stakeholders to take decisions. How much business values would deliver in which month and all other marketing strategies and other plans falls in place.

Also, If you re-size the Story points then Committed remains the same and completed will show less story points. Ex: Sprint 1 has 50 Story points (Committed) and when you re-size these 50 Story points in Sprint 2 to 30 SP then completed would be 30 SP. 

There are many good insights in this thread around story point re-estimation for unfinished items in a sprint.   I have even held both opinions (re-estimate, don't re-estimate) at one time in my career.



The reasons why I prefer re-estimation now are twofold:

1. Story points are intended for planning purposes, and should not be used in evaluating performance or getting 'credit' for incomplete work
   
    
2. Items that are not re-estimated are less transparent than ones that are (i.e. - this item is a 5-pointer, but really there's maybe 1 point remaining to finish it).   Transparency is one of the 3 pillars of Empiricism, which Scrum is based on

I'm going to join @Timothy Baffa.  This thread is 2 years old and I have learned a lot since my initial statements.  I still don't find much use of Story Points beyond guessing effort of a story vs other stories that need to be worked on. I do not believe that repointing is useful unless it is a significant amount.  If the team decides to pull it into the next Sprint, they should be able to create their Sprint Backlog with that story in it as well as adding others.  If the work is going to be put into the Product Backlog for consideration at a later date, even then repointing is problematic because new information may be obtained before the story is pulled into a Sprint. Of late, I have suggested removing any points, reworking the story definition to match the work that remains to provide value and putting it through refinement activities just like all other stories in the Product Backlog.

What matters in the end is the delivery of value to the stakeholders not the number of "points" completed.  If you didn't finish a story during a Sprint, you did not deliver the value. I don't feel like this ia a mistake or failure unless you do not learn from what happened.  If you discuss the story and fully understand why it wasn't possible to finish it during a Sprint timebox, then you are successful.  Because the chances of running into the exact same situation is very unlikely.  But the reasons could be encountered in different ways on other work. 

Very useful opinions. Currently I am facing the same dilemma. I tend to be supporting the re-estimating practice and I agree with Timothy's reasons. Usually we re-estimate the tasks In Progress before closing the active sprint. This way the complete part of the work is reflected in the burndown chart. However this complete part is not reflected in the velocity chart and is sort of lost. How to deal with this problem and how to get accurate velocity numbers when re-estimating stories?  

Example - 1 sprint, 2 stories, 10SP each, one is completed, one is re-estimated to 5SP and we close the sprint. The burndown chart goes from 20 to 5 which is correct and the actual team velocity is 15SP, but the velocity chart shows only the 10 completed SP. 

 

If a story spills to next sprint, there is no need for re-estimation for the story. However this case is a good retrospective candidate to discuss and team can eventually come up with solution / improvements/ workways to reduce these kind of situations in future sprints.

If there is a delay - there must be a reason for delay.

Retrospective is the best place to identify that reason, discuss about possible solution, finalize one/more ways to reduce this situation in future.

For example -

A better estimate at the first place is needed during sprint planning.

A technical hindrance

A missing functional case - added last minute

Lack of technical expertise.

These are few from many possible scenarios for delay.

We can strive to be more self organizing and more efficient each day with each sprint cadance. Thats being Agile.

Hello All,

This is what I encourage teams to do:

Done? -- Add SPs to velocity calculations

Not Done? -- Do not add SPs to velocity calculations

And, if the story goes into the next sprint, the SPs remain the same but the team take into account the work already done when they consider their capacity for the sprint.

I just concluded one Sprint where the Team was not able to finish one of the Stories which was worth 5 points. We just put it back in the Product Backlog after re-estimating it to 3 points based on the tasks done and knowledge gained in the last Sprint.

If you don't re-estimate your story points, the metrics your team uses to chart progress will be thrown off.

For example, say all members of the team poorly estimated their work, and everyone got half done. The charts would show zero points for the sprint. The next Sprint, assuming everything was completed, would show twice as many.

That's not helpful. Perhaps it will all average out over time. But perhaps it wont?

Sometimes we must search for a pragmatic solution to problems.

No Points for Scrum

Scrum doesn't have 'points.'

We're not really supposed to talk about points in Scrum.

But, Scrum does say Product Backlog items can be 'decomposed?'

"For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers." -The Scrum Guide

Perhaps the incomplete work was a result of a poorly decomposed Product Backlog item?

Maybe work to see how the story may have been better decomposed. See if any work completed meets the definition of done for a more decomposed item, and put that work in the done column. That would allow points to be accrued?

I'm not in love with that solution. I don't like going back in time to re-evaluate what's done. But it's a thought.

If it's a regular occurrence, it's probably an indication there's some coaching needed. Definitely something to discuss at the Sprint Retrospective.

Mike Cohn does have a very good and detailed insight on this topic, but it is not the article mentioned earlier. It is here: https://www.mountaingoatsoftware.com/blog/should-you-re-estimate-unfinished-stories