14

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.

10

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.

  • 2
    Do you have citations for this? Most people say that you shouldn't reestimate. I linked to two such references in my answer. Can you link to a third party that backs up your claim that you should reestimate? – Thomas Owens Aug 18 '15 at 12:37
  • @ThomasOwens See the Sprint Planning section of the Scrum guide; a forecast and implementation plan for the current increment is the proper output of the ceremony. This process happens each Sprint, not a la King Arthur (e.g. encompassing "once and future Sprints"). Many Scrum practices such as velocity tracking, user stories, and estimation techniques are not prescribed by the framework; you can implement any practices you like consistent with incremental planning. Legacy estimates are orthogonal to incremental planning. – Todd A. Jacobs Aug 18 '15 at 14:52
  • 1
    I agree with the statement that you plan the increment (the sprint). So far, though, I can't seem to find anything that says you reestimate a story. So if you have a 10 point story that was "unfinished", you move it back to the product backlog. When it comes up again in increment planning, I can't find anything that says you reestimate. You treat that as a new 10 point story and can add (velocity - 10) more points to your sprint. That seems to be what I've found to be consistent with most things I've read. Can you point to anyone else who says that you should reestimate the story every sprint? – Thomas Owens Aug 18 '15 at 14:57
  • 2
    I guess what I'm saying is that I'd like to see this answer backed up with at least one external reference that describes how people reestimate instead of using the value as-is with respect to increment/sprint planning. I've always read and was taught that once a story has been estimated, that's the estimate. If you don't meet that estimate, you address why in a retrospective. – Thomas Owens Aug 18 '15 at 14:58
  • 1
    @ThomasOwens You could make hay over the fact that the framework currently explains this under Cancelling a Sprint rather than in some other section, but the intent and reasoning seem pretty clear. The Scrum Guide definitively states: "All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated." – Todd A. Jacobs Jun 7 '18 at 22:21
8

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. If no other story has a higher priority, then, yes, they are moved into the next sprint. If other stories have a higher priority, then they might be moved back into the product backlog if there is not enough room in the sprint to accomodate them. This all happens in the sprint planning, based on the priorities assigned to each story by your Product Owner. 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, you estimate a story when you accept it, begin work, and don't have a concept of partially complete. A story is either 100% complete, tested, and accepted (done) or it's not done. If there's no concept of partially complete, there's no way for you to determine how much work is remaining on the story. It appears that I'm not alone in this thought, either. 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 postmortem and try to avoid making that mistake for future sprints.

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.

  • It's a good point about 'credit' for work done. That's a big change for lots of people (extra context: the team in this case is offshore, which complicates things a little in this regard). I don't agree that the planning element of estimation should be considered an afterthought though. Yes, owning and understanding commitment is crucial but the purpose of that commitment is partly to know how much value is added over time and the reason you need to know that is so you can plan around it as a business. – Willl Aug 6 '15 at 8:42
  • 1
    Story points and velocity will not tell you how much value is added over time. The product owner's estimation of story priority or rank is a closer proxy to customer value. A team with increasing velocity or a team with a higher velocity than a different team does not indicate that the team is delivering more value. Scrum teams commit to delivering stories and indirectly commit to delivering value. It's more the customer or PO that is responsible for ensuring the commitment contains the right stories that optimize value delivery. – WBW Aug 6 '15 at 17:06
2

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.

0

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.

  • Good point about standalone velocity being pretty meaningless. – Willl Aug 4 '15 at 19:46
0

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.