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.

We're using Scrum and occasionally find that we can't quite finish a User Story in the sprint in which it was planned. In true Scrum style, we ship the software anyway and consider including the User Story in the next sprint during the next Sprint Planning session. Given that the User Story we are carrying over is partially complete, how do we estimate for it correctly in the next Sprint Planning session? We have considered:

a) Adjusting the number of Story Points down to reflect just the work which remains to complete the User Story. Unfortunately this will mess up reporting the Product Backlog.

b) Close the partially-completed User Story and raise a new one to implement the remainder of that feature, which will have fewer Story Points. This will affect our ability to retrospectively see what we didn't complete in that sprint and seems a bit time consuming.

c) Not bother with either a or b and continue to guess during Sprint Planning saying things like "Well that User Story may be X story points, but I know it's 95% finished so I'm sure we can fit it in."

share|improve this question
add comment

5 Answers 5

In my current team we do c).

The velocity should account for things the team really finished in the sprint. Something that was not delivered has no value for the customer, so we don't count any points for it, it's all or nothing.

So we shift the whole unfinished story on to the next sprint and all its story points will be added to the next sprint's velocity. Velocities even out over time and we take an average of the few previous sprints as a reference to determine estimate future velocities.

share|improve this answer
    
If your team and situation is static enough I can see this option making sense. I have personally had issues with this because sometimes I need to compare sprint to sprint metrics to make a point that a process or environment change is adversely affecting throughput. Does that come up for you? –  Bill Jun 27 '12 at 13:26
    
The need for side by side comparison of 2 sprints does come up occasionally. However, there's a very large number of factors that can affect productivity (wrong estimates, external disturbances...) We found out that just removing one of these factors from the equation by accounting for unfinished user stories doesn't make the real causes appear magically. The productivity drop caused by unfinished stories is generally marginal in such cases and doesn't blur the metrics that much. –  guillaume31 Jun 27 '12 at 15:04
    
"doesn't make the real causes appear magically" => nor make obvious causes disappear magically, I should add. –  guillaume31 Jun 27 '12 at 15:13
add comment

Option A is a commonly recommended course of action. You do not award points for the completion of the story for the previous sprint and to move the story back into the product backlog, where it is reprioritized. You compute your velocity (and other metrics) based on the completed user stories and value-added. When you begin planning for the next sprint, you take the highest priority stories based on their value (which might or might not include the unfinished story, if business priorities have changed). When you estimate the story, include the work that has already been done when factoring in the new amount of points for the story.

Of course, an alternative option (and my preference) would be to use the original estimated number of story points, which is something that I've done in the past. This makes the assumption that your estimate was good and well-founded, but you pulled down too much work for the sprint (eg - the story was actually worth 3 points, but the problem lies in the fact that you pulled down 15 story points when you should have only pulled down 13). It's a potentially dangerous assumption if you aren't confident in your ability to perform the estimates, but it might work based on your team and process.

However, you mention that this will "mess up the reporting of the Product Backlog". The Product Backlog should be dynamic anyway, with the ordering and estimations of each story changing as more is understood about the technology, the system, the requirements, and the customer. Typically, what gets reported out of the Product Backlog is the number of user stories and the total number of story points. These should be expected to change as priorities change, new requirements are added, invalid requirements are removed, and more information is learned.

share|improve this answer
    
I agree with all of this except the "new amount of points for the story" part. Unless the scope of the story has changed, the original points assigned to the story should not change. As I see it, without that part, what you wrote is exactly option C. –  Eric King Jun 27 '12 at 15:29
    
@EricKing What I present in the first paragraph is Option A, along with accounting for changes in business priorities that might cause the story to be descoped for a sprint or two. I do not advocate Option C because you should not "guess" based on finished work, but go through your team's estimation procedure. –  Thomas Owens Jun 27 '12 at 15:32
    
I suppose I took "guess" and "estimate" to be approximately equal, since an estimate is, essentially, an educated guess. Like I said, though, I agree with everything in your first paragraph except the last bit. And I agree with all of the rest of your answer. But the essence of option A is adjusting the story points, which I feel should not be done just because some work has been completed on the story. Remove that, and you're left with option C. –  Eric King Jun 27 '12 at 16:02
add comment

If your reporting tool cannot handle option A accurately then I would go with option B unless you have no hope of ever using your metrics.

In some cases you can do option B AND not skew what closed means by narrowing the scope of the old task you are about to close and only creating a new task for the scope that remains. This makes the history make more sense semantically and usually indicates places where you should have considered breaking the task down further. Sometimes this is not possible or logical and you simply have a task that is that large or runs into that level of issues.

edit: This assumes (as I believe the OP was assuming) that nearly complete work has not been knocked down in priority and that getting to the payoff on the previous effort keeps it high enough in the list to continue working. I know some shops do not do this, but most places I have worked consider finishing a near-complete leftover task to be valuable enough to simple continue unless something has changed dramatically. The penalty of changing context is often not worth changing the order.

share|improve this answer
add comment

Thinking too much about this makes it seem more complicated than it is... It's actually pretty simple:

Option C

Incomplete stories go back into the product backlog, without the points being changed. When planning the next sprint and what can get done, the discussion should include the fact that much of the work is already accomplished. If the team decides they can fit it into the sprint, then it goes in, with its original number of points. If not, it stays in the backlog. Done. The points get awarded to the sprint in which the story was completed.

If it helps, you could track a separate "work remaining" metric per user story, so that if, by the end of the sprint, the story isn't complete, the estimated work remaining can be noted on the story and factored in when planning its inclusion in a subsequent sprint. But even then, don't alter the original story's point value.

share|improve this answer
add comment
up vote 1 down vote accepted

I'm surprised there doesn't seem to be a straight answer to this. I was expecting a chorus of "option D, dummy"!

As we haven't seemed to be missing anything obvious, we figured this is one of those decisions each team needs to make for themselves based on how they want to work and what metrics are most important to them.

We decided that keeping accurate records of the user stories we have implemented is essential, as these form the basis for our testing, support documentation and release notes - that rules out option B.

Next we figured that being able to perform sprint planning accurately was essential - that rules out option C.

We have therefore concluded that option A is right for us. We're going to re-estimate the story points for any stories we partially complete in a sprint in order that we can plan for them properly in subsequent sprints. Over time the product backlog will slightly under report the amount of story points we have implemented, but this is going to be less of a problem than any of the other options and could possibly be resolved by changing our record keeping and reporting.

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