Work out sprint capacity when carrying over story points in scrum

Question

Let’s say story A is worth 10 story points. Development starts in sprint 100, but is not completed by they end of the sprint. I am then assuming that you do not claim any points. A story is done or not done. And tets say your average velocity is 25pts and your team stays the same for the next iteration. So when working out your capacity for the next sprint What do you with the story points when carrying them over. Do you:

A) Carry over the 10pts to the next sprint taking off 10pts off the next sprints capacity. So take away 10pts from your 25pts capactity which leaves you with 15pts for new stories.

B) Work out how many points are left in the story and only take them off the capacity but claim 10pts on completion. So say there are 3pts left. Take them from your 25pts capactity which leave you 22pts of capacity for new stories.

C). Something else?

Thanks in advance!

Answer 1

First off beak your tasks down so that they fit into one sprint.

If there is a task that didn't get completed write down what you did complete, count those points for the sprint that they were work on and then make a new ticket for the remainder in the next sprint.

This is just an indication that your estimates are not good, it may be a one off or maby you need to work on that.

To clarify, you need to break the ticket up into two but don't change its size. The missed estimate should be recorded. So if you had it sized as 10 pts and you completed 70% of it move 3 pts to the next sprint as say finish feature X.

Answer 2

We generally assume that any story that was not finished is basically "unstarted", which is an option A of sorts. This has turned out to be just as good as any other assumption you can make. Conceptually we just push it back onto the backlog, since we may choose to postpone it further (if someone else has to fix something then you might as well leave it for a sprint or five)

The argument for considering unstarted are along these lines; You thought you could finish it in the sprint. You didn't. And in most cases this is for a reason. And since you'll be working on it for another sprint, chances are your requirements are going to be changing or there's other trouble. So we basically consider the effort lost, or perhaps wisdom gained is less pessimistic ;)

Answer 3

I'd say B (although you shouldn't spend much effort trying to estimate how many points out of 10 are left...) or C.

In my experience, it's rare that you get exactly the amount of items done that was estimated. Far more often either some items do not get done, or everything gets done before the sprint ends (and new items are added during the sprint). In both of these cases it's common that an item is unfinished when the sprint ends.

So, when deciding how much you'll take to the next sprint, in my team we've come to think that while it's useful to look at your (long-term) velocity, you shouldn't think about the numbers too much. Instead, just add items to the new sprint until the team has a consensus that no more items fit. This can be a pragmatic alternative, especially if you haven't really yet established what your velocity level is, or, like in your case, some of the items are already "almost finished" - the team can quite easily accommodate for that fact.

Answer 4

In our company, we do (B).

For planning purposes, the team re-evaluates the complexity of what’s left and those story points are used.

However for calculating velocity, the original story points are allocated to the sprint that it is finished in. This can lead to a see-sawing effect, but this will average itself out in the end. If lots of stories are spilling over to other sprints, then your stories are probably too large for your sprint length. Consider breaking the stories down into smaller ones.

Hope that helps!

Answer 5

I would do (C) in my team: - cary that unfinished story over and start planning the sprint as usual - stay a bit more on the aggressive side (above average velocity) when soing the first pass in the planning meeting - after the first part of the planning meeting is over, estimate the available time, and compare it with the total remaining time in all tasks - if the variance is more than 20%, adjust the stories if needed, usually it means add/remove one small story - it works well for my team

Answer 6

c) Neither. Don't count any of the undone story's points towards the last sprint. Then you put the story back into the backlog for prioritization by the PO (he may kill it off). When you go to tackle it again, you will re-estimate it. When this happens you may get a larger or smaller number than you did the first time. It may be smaller because you learned a lot about the story during the first failed attempt and thus you are more confident this time around. Or it may be larger because last time you made some assumptions that led you to underestimate it and this time you know it is bigger than you thought before.

Your team velocity will drop because you didn't finish the story. But that is Ok because you were overcommiting anyways. So at your next sprint planning meeting you might be able to take on 24 points instead of the 25 you tried before.

I generally find that the reason stories don't get completed on time is that we make bad assumptions about simplicity (just a bad faucet). Then when we get into the story during the sprint we find a lot of complexity (re-plumb the whole house). Thus, most stories remain equal or higher estimated than before. If it was just a matter of a few linear more hours, then I would have to wonder why the team just didn't man-up and get the thing done per their commitment.

Answer 7

Scrum sez that no partial credits are given for incomplete sprint backlog items, whether you are 1% complete or 99% complete. The item goes back onto the product backlog (at the top), and the product owner gets to make the call as to when it's worked on. If the item is nearly done it almost always ends up in the next sprint.

So you signed up for 30 points and only got 25 points done, plus another 5-point item was 99% complete. Since you know there's not much work left, you could take on 35 points in the next sprint... 30 points of new work plus the 5-point nearly complete item. If you get everything done, then you get 35 points, otherwise you repeat the process for unfinished items. Note that continually not finishing committed items is a Scrum smell and should be discussed and diagnosed in the sprint retrospective so you can fix the underlying problem (are you overcommitting? were your estimates bad? is your team not putting out? is your velocity not increasing as the project progresses?).

When you look at average velocity, these dips and rises average out.