In scrum should incomplete stories be re-estimated or does the original estimate get burned down when it's finally completed?

Question

If I have a story that's been estimated at 10 story points and we don't manage to complete it in a sprint how do you handle estimates for the sprint in which it's next included (assuming it gets selected for development)? Assuming 80% of development was completed on the story should it be re-estimated at (for argument's sake) 2 story points? Or should the original estimate remain and all 10 story points be burned down when it's finally completed? The former approach seems wrong because a 'big' task now looks like it's small. The latter seems wrong because it surely mis-represents actual velocity in a sprint.

If I write a new story for the remaining work then that also seems like a mis-representation because the original 80% of the work is unaccounted for unless I re-estimate it at 0 points and include it along with the new story for the remaining work and resolve it at the same time as the new 2 story point story is completed.

Footnote

For those who are interested in the background to this question it's born out of JIRA's default agile board behaviour, which is to return incomplete stories to the top of the backlog. In general we've been re-writing them and/or splitting them into new stories before putting a new estimate against them but I was never sure if this was really the "correct" way of doing it.

Answer 1

TL;DR

Velocity is simply a proxy for measuring team capacity over time, and shouldn't be used for historical time accounting. Always estimate based on the current level-of-effort and complexity, and this will naturally result in incomplete stories being reflected in velocity as drags on capacity.

Stories Shouldn't Carry History

Don't treat stories as historical artifacts. Incomplete user stories from past iterations should not carry history. Instead, they should be decomposed, edited, and refined as if they were new work, and this new work estimated without regard to historical estimates or past progress.

There are many reasons for doing this. One of the main reasons is to ensure that you are tracking team capacity to complete new objectives, not volume of work previously done, through your velocity metrics. Velocity is simply not the right tool for historical time-accounting.

Discard Historical Data in Estimates

Each Sprint is an ephemeral time-box. When you plan a Sprint, historical progress is irrelevant. What you are really attempting to answer with your estimate is:

Based on what we know and where we are today, how much effort is required to deliver this feature now?

Changes to level-of-effort or complexity happen a lot in Scrum as the cone of uncertainty narrows or as new efficiencies are discovered. In addition, the iterative nature of agile development means the context of a user story can change over time.

For example, you might have had a story about delivering a GUI widget that was estimated at 8 points several sprints ago. However, when the story is re-estimated, it turns out that the team now knows about a third-party plugin that can simply be dropped into the code to provide the feature.

The effort to merge this plugin into your current code base is estimated at 2 points. That is the level of effort required to implement the feature today; the fact that the team is throwing away 16,000 lines of code (whether that code is good, bad, or ugly) from six months ago is irrelevant to measuring the story's ability to fit into the current time-box.

Answer 2

Below is my answer to the question What to do with estimation of incomplete story? on Software Engineering Stack Exchange. Although the question is worded slightly differently, it is asking essentially the same things.

---

Firstly, what happens with those user stories? Do you just carry them over into the next sprint?

It depends.

The Scrum Guide states that, at the end of a Sprint, unfinished Product Backlog Items are moved back into the Product Backlog and the Product Owner ensures the correct ordering of the work. However, practically speaking, if the work remains ordered high in the Product Backlog and the work is also consistent with the Product and Sprint Goals, it would be highly likely to be selected for the next Sprint at Sprint Planning.

Since one of the purposes of agile methods like Scrum is to maximize the delivered value while reducing the time, it all comes down to how much value is added by finishing those stories.

Regardless of what happens, you still need to strive for a potentially shippable product at the end of the sprint. This might mean rolling back to ensure that the end-of-sprint product passes all tests and the completed features are fully usable by the user without any significant problems.

If so, should they be re-estimated? In my view the work remaining on these user stories can be minimal or a lot? If not, why not?

I would not reestimate because, in Scrum, a Product Backlog Item is either done (designed, developed, tested, and acceptable) or it's not done. If there's no concept of partially complete, there's no way to determine how much work is remaining on the story. You estimated the work that you thought you can do, so leave this data point in and make it a point to discuss why the estimate was off in your Sprint Retrospective and try to avoid making that mistake for future sprints.

Answer 3

What you really want to get at is why it wasn't done and why the team committed to doing something that they couldn't deliver (especially if you frequently have this problem). Estimation is a tool to empower a team to own and understand their commitments, using it for planning purposes is an afterthought.

Velocity is an average amount of work that can be completed in an iteration, so whether you split a 10 into an 8 and a 2, or carry the whole thing over, the long term average velocity of the team doesn't change.

Now some team members feel punished if they don't get some "credit" for the work they did. Story points do not equal credit or productivity to a team member or any external stakeholder. If there are external or internal misconceptions about what story points or velocity represent or are used for that is a separate problem to address.

So to answer your question of whether to split, carryover, or re-estimate...Go for the practice that makes your team feel empowered to fix the real underlying problem of why the story wasn't done.

Answer 4

Velocity measures the team's ability to get work 'done' in a sprint. It doesn't measure the team's ability to get work in progress.

My preferred approach would be to re-estimate the story, taking in to account the work that had been completed so far. I would treat this as a new story that should be prioritised alongside all the other items in the product backlog. In your example the 10 point story would become a 2 point story.

At first this may appear to mis-represent the true velocity. But I believe it is an effective measurement of the team's ability to get work 'done'.

Remember that the most important reason for measuring velocity is to allow the team to target a realistic amount of work in future sprints. It is not and has never been about measuring the performance of the team.

Answer 5

The scrum guide is silent on this, which leaves people to draw their own interpretations and use different approaches.

We move the complete story to the backlog and then to the next sprint (invariably, since the feature priorities don't change that frequently). Yes, it projects a wrong velocity for that sprint but then Velocity is supposed to be used for the rate of delivery in a release. It doesn't mean much when you see it standalone.

Answer 6

As long as you aim to predict the future you should re-estimate spillovers before the next Sprint or before purring them back in the Backlog. The reason for that is very clear - it is describing what is really left to do. You are not getting paid for story points you delivered.