tags:

views:

796

answers:

4

Let’s say product X is worth 10 story points. Development starts in sprint Y, but is not completed in time. What do you with the story points when calculating sprint Y’s velocity?

Would you:

a. Allocate 0 story points for sprint Y and 10 points for the sprint it is eventually completed in;

b. Determine the story points for the remaining work (let’s say 3) and allocate the difference to sprint Y (7 in our example); or

c. Something else?

Thanks in advance!

+4  A: 

Depends on whether you care about your "instantaneous" or "average" velocity. Personally, I wouldn't make it more complicated than necessary and just add it into the sprint where it was completed. Calculate your average velocity by looking at the average number of points completed per sprint over the last 3, 6, and 12 months. Hopefully, these will eventually converge and you'll have a good idea of how much you can get done in one sprint.

tvanfosson
Thanks for that. We found that the velocity from sprint-to-sprint would see-saw, as sprint x would have a low velocity due to incomplete items and sprint x+1 would have an artificially high velocity due to the items that rolled over. A rolling average over several sprints smoothed that out.
Fuzzy Purple Monkey
+3  A: 

Allocate 0 points for sprint Y and 10 points when the story is eventually completed. Either the story is done or it is not done. There is no middle ground. You want to avoid the 50% done or your teams may implement many stories half way and none completely.

It is perfectly okay not to finish a story during a sprint and completing it in the next sprint. But, you should not present this story to the product owner during the sprint review.

If you have enough stories for a given sprint, it won't matter if the story is completed this sprint or the next. Things will average.

It is also important to explain to the team and to the stakeholders that the velocity helps estimate when the release will take place and is not a measure of the team performance.

The team should be judged on the final result they produce, not when those results are produced.

Combined with a well prioritized backlog, you will create good quality software that means your customers needs.

David Segonds
+2  A: 

That's one of the ideas of the sprint, the "completeness" is binary, either done or not, over time the team(s) will have better estimation and this question will loose relevance

webclimber
A: 

BUT...

The next question is how do you caculate your commitment for sprint after Y. If your past weather shows you have a an average velocity of 20pts. If you carry the story over then you carry over 10pts. However if you think there is only 3pts left of the story: Do you

A) Take on another 17pt to fill your estimated capacity of 20pts B) Only take on 10pt more as the story carried over was originally estimated at 10pts

We got into a mess trying to do A. What do other people think ?

[Update]

I posted a question about this:

Work out sprint capacity when carrying over story points in scrum

Peter Delahunty