Should we re-estime (reduce) story points of a task that we started but didn't finish last sprint? [duplicate]

Question

I need an advice and it's about the best option to choose in an agile project, here is the situation :

• A sprint backlog contains between 15 and 20 user stories
• A the last day of the sprint, we understand that we will not finish 1 story, we did some code on it, and we will need to continue in the next sprint
• This US was estimated initially at 13 points, and the developer says that he did 50% of the US

What to do, should we create a new ticket in the next sprint, exactelly the same US, re-estimate it to maybe 5 points because we did some job on it ? and closing the one we started after re-estimating it to 8 points ?

Or to keep same 13 points in the next sprint to this same task ?

Answer 1

Ultimately it's up to the team but I expect it depends on exactly how you use points. A rule that I like to use when a story is not 100% done is to count it as zero points towards the current sprint's velocity. If that's what you do then I would suggest leaving the points unchanged when you add the story into next sprint. The effect of that will be to show a drop in velocity in the current sprint but a corresponding increase in the next sprint, which seems to make sense.

Answer 2

While I understand the argument for pragmatism or letting the team decide, I would absolutely advise that you carry over the same 13-point story to the next sprint. Scrum is meant to be about delivering increments of product, not doing work. That may seem like a silly statement because you certainly have to do the work to deliver the increment, but it's about where you put the focus.

So, let's look at the question in that lens. If we split the story, it is about showing that work was done. But it hides the fact that no increment of the product was delivered. On the other hand, carrying over the story only checks the done box once the increment is delivered, regardless of where the work went. So, which one is actually delivering on the intent of Scrum?

Now, there is a nuanced third answer to this. Let's say we've got 2 days left in the sprint and it's clear this one backlog item won't be completed. So, at that moment, we agree with the PO that we could deliver part of the feature in a potentially-releasable state (QA, deployable, etc) if we don't work at all on another part and everyone agrees this makes business sense. Now, we have actually delivered part of that 13-point story and it makes sense to call it done and move the rest of it out to the next sprint. You could, then, re-estimate both stories if that gave you some value in the team.

Answer 3

There isn't any best option; you can do it either way. The best option here is to decide this together with your team instead of having one voice say "we will do it this way".

Here is how I look at this, others may use different approaches depending on how they use velocity.

Velocity is something that should show progress per sprint, not work per sprint. If you split the story points you are measuring work not progress. The user story being "Done" means progress, half done is not really progress because in Agile progress is measured in working software not in percentage of work complete.

So if you split the story points, your current sprint will show more progress than actually accomplished. For future forecasts this might give a more optimistic view on what you can do. It seems you did more, but in fact something spilled into the next sprint. A smaller velocity will account for the fact that this can occur again in the future so it makes the velocity measure more in tune with reality (at least that's how I look at it).

In your next sprint you reestimate the story for what still remains to be done and finishing this work will reflect in the velocity of this next sprint as being "Done".

Overall you do more or less the same work, but velocity will reflect the "hiccup" in this sprint.