Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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 '11 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 '11 at 23:19
    
Panic.......... –  jiggy Sep 14 '11 at 17:59
add comment

migrated from stackoverflow.com Sep 12 '11 at 21:58

This question came from our site for professional and enthusiast programmers.

11 Answers

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

share|improve this answer
add comment
  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.
share|improve this answer
add comment

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.
share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 '11 at 19:03
add comment

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?

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
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 '11 at 17:56
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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