17

Do you just move the story to a new iteration, or delay the next iteration?

It gets a bit tricky when you use something like Jira when you have to copy or move around stories between iterations as it effects calculations of velocity/points etc.

Is there a best-practice?

Improve this question
2
  • 3
    "tricky ... as it effects calculations of velocity/points etc" How is that "tricky"? Please explain what you think makes this "tricky". If you have too many stories, you have a velocity problem to begin with, since you mis-estimated. What's "tricky" about that?
    – S.Lott
    Sep 12, 2011 at 21:17
  • It really depends on whether you want to prescribe to "Scrum Proper" or if your team is just "agile" in some way, shape, or form......
    – Agile Scout
    Sep 12, 2011 at 23:19

12 Answers 12

Reset to default
23

In my experiences, stories are either done or not done. There is no concept of an unfinished story. At the end of a sprint, you either completed the design, implementation, testing, integration, and system testing for a story and presented it to the customer for sign-off, at which point it was moved out of the backlog or it remained in the backlog for the next sprint. There was no concept of re-estimation or partially completed stories.

At the beginning of the next iteration, a N point story that was started in the previous iteration and left unfinished was still considered to be a N point story. Our velocity for the previous sprint was used to pull down an appropriate number of story points for the next sprint, starting with the N unfinished points and the top stories until the number of story points in the iteration was the velocity of the previous points.

However, that was just our practice. The key is to be consistent. Whatever you choose, do that at every iteration and don't change - that will affect how you compute velocity and estimate work for future sprints.

Improve this answer
1
  • 2
    I down-voted because I disagreed with the approach since arithmetically it doesn't make sense that those points go nowhere. Then after reading this article I changed my mind since points do not follow the usual rules of arithmetic but they are only a tool to represent business value delivered and of course half-done features deliver the same value as non-existent ones. Unfortunately my down-vote is locked.
    – pgpb.padilla
    Oct 12, 2014 at 18:43
8

Move the story to the next iteration. Possibly update it's size, if a fair amount of work has been done on it.

Improve this answer
1
  • 1
    The crucial problem is determining how you update size. It's not easy (in fact, nearly impossible, given the ninety-ninety rule), to quantify how many hours (or how many points) are left to develop a software component. The only thing you know is that your estimate was wrong, and when you finish, how much you were off by.
    – Thomas Owens ♦
    Sep 14, 2011 at 17:56
8

The iteration size is supposedly fixed. The best approach (according to me :) ) is to split. Typically when tasks are not completed within the iteration they are assigned to, I suggest splitting the user stories and move the incomplete tasks to the next iteration. The estimate of the new user story is calculated from the remaining units necessary to complete the original user story. This way you can keep the estimates and also maintain historical references.

Improve this answer
3
  • Like @hvgotcodes has mentioned, the idea of agile is continuous improvement. So as long as we keep records of stories we split and understand the problems with those user stories, we will have less and less instances of split stories.
    – doc_180
    Sep 12, 2011 at 19:03
  • 2
    Good point; however, IMHO splitting is only appropriate if the split stories still have business value on their own. Just splitting into "done" and "not done" is not helpful.
    – sleske
    Feb 2, 2015 at 12:31
  • @sleske I agree, I will edit my answer.
    – billygoat
    Feb 10, 2015 at 18:25
7

A. Put the story into the project backlog. If it's still the most important thing, it will be scheduled for the next sprint. If not, the product owner will schedule something more valuable.

B. You get no points for that story for this sprint. When you schedule the next sprint, Only count points for stories completed this sprint. (Yeah, you'll pull in a bonus story at the end of the next sprint. Great. But it's better to get a bonus story than to presume you'll get it done, then you'll have another unfinished story to account for.)

Improve this answer
3

You can move the story to the next iteration and estimate again. You can always discuss with product owner / team and scrum master what to do.

Improve this answer
3

The dilemma: Where do story points for unfinished stories go? The sprint where they are finished? Partial credit in each sprint for the portion finished in each sprint? Here is how I answered the dilemma in a blog post:

Those points go nowhere. No credit. But the team DOES have to complete the work.

Full blog on this topic here: http://agileangle.blogspot.com/2011/07/story-points-who-gets-credit.html

Improve this answer
2

In addition to other answers, you could

1) create a story to represent the completed work, and a new one for the remaining work, adjusting estimates.

2) analyze why there was a mis-estimate. Stories typically represent commitments, and if a commitment wasn't met, it's kind of bad. Was there not enough analysis up front (i.e. devs didn't know how much work it would actually be), did people get sick, did other bugs prevent the work from being done, etc?

Improve this answer
2

If the story is not complete (as per in your definition of done), you should not receive any points from it.

In the the next sprint, create a new story based on what is left from the unfinished one, add it to the sprint backlog and estimate it. Possible merge it with another story if it is too small.

If your tool cannot handle this, you should probably look for something which can. I prefer low-tech tools myself.

Improve this answer
0

We tend to try to brake up stories so that it can easily fit into a sprint, and that it can easily be removed. It takes a certain mindset to brake up the story into deliverable pieces during the sprint planning meeting.

The thing I also found is that if the stories brake up into deliverable pieces (which can be visible or not, or even switched off for a couple of sprints), my team can do all the work on the trunk, and not hassle with doing work on a branch, and then rebase/merge the work later which is always a pain, so that's a bonus.

Improve this answer
0

We do a variation on some of the answers given.

You estimate a sprint at a given amount of points, let's say 34. If after we reach the designated end point for the sprint and we have not finished, we go into a remedial sprint.

What this means is:

  1. We get credit for the 34 points.
  2. We have to finish the story that we were working on. It was the highest priority on the backlog at the time of assignment, so it maintains that priority.
  3. We task and work on the given story until we meet our definition of done. This amount of time is assigned 0 story points. This serves to adjust our velocity.
Improve this answer
0
  1. At the sprint review, the Product Owner, in consultation with the sprint team and stakeholders makes the decision on done-ness. In this case, the PO declares that the story will not meet the customer's needs as intended.
  2. The PO may elect to create a new story and place it into the Product backlog. The new story, like any story is based on the information that the PO has about the current state of the product and the current needs of the customer. This obviously includes the discussion that took place about the undone story above.
  3. At the next planning meeting, the new story is assessed like any other. The PO prioritizes and the team estimates effort.

Notes:

  1. The degree of done-ness is a factor in the decision process. For example, if the team agrees that they are "one hour" from completion, the PO may agree to delay the done decision. But the team still needs to demonstrate that the story is done!
  2. On my team, a story is never moved out of the sprint after that sprints review (it's closed as-is). We use the "done-done" rate to use as a talking point during the retrospective. If we moved the story, then it would appear as if our done-done rate was 100% every sprint.
Improve this answer
-2

So there are two ways you do it

FIRST - Split the stories and assign and divide points to old and new split story - this means estimate the remaining work on the story

For example - An 8 pointer story was 'unfinished' with only 3 point of work completed and team estimates that 5 points is needed for the pending/remaining work - Then update the 'unfinished' story to 3 points and the new split story to 5 points.... makes sense?

SECOND - Split the story and zero out the points from the old story and update the new split sory with the full points of the old story - this is the best practice scrum teams follow. The credit is given only when the full story is completed and velocity also can be captured properly by averaging out once some iterations are done.

Second option is what we follow

Improve this answer

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