How does capacity planning (and velocity) work when an issue is split between sprints?

[Rob Horan]

Assume I have a 10 hour or 10 point issue.  Unit agnostic.

I do 5 units of work in sprint A ran out of time, and did the remaining 5 in B.

How do I allocate 5 units to each sprint?

[Nic Brough -Adaptavist-]

You do not.

In a Scrum methodology, you are supposed to complete a story in a single sprint.  If you can't for some reason, then the issue rolls over into the next one (or goes back into the backlog), but you should never be planning for that to happen, it represents a failure to achieve what you said you would do.

If you have a story that can't be done in a single sprint, then you should split it up into two or more stories that can be achieved within a sprint.

[Rob Horan]

@Nic Brough -Adaptavist-  - I appreciate your reply from a theoretical perspective. Still, I'm trying to find an answer to give someone else, and giving them a scolding isn't going to work. 

What does rolling into the next sprint mean? How is the time spent in both sprints tracked in the issue and visualized? How does this affect capacity in roadmaps?  

Nobody wants to fail at what they set out to do. You're assuming that everyone knows what can and can't be done in a single sprint, but that's not always the case. Everyone wants to meet their deadlines, but the reality is it doesn't always happen. Sometimes - for whatever reason - finishing on time isn't possible. Maybe a resource got sick and was out for a few days. Maybe an emergency issue took precedence. Does that mean all of the work put into Sprint A was for nothing?

[Nic Brough -Adaptavist-]

It's not a scolding, it's more a case of explaining that they're using a scrum tool for their non-scrum processes, so there's going to be issues.  In this case, they're not doing the estimation in the way Scrum expects.  So:

>What does rolling into the next sprint mean?

It means the entire story is placed in the next sprint as well as the currently closing one, along with its estimate.  As an example, imagine you have an issue with an estimate of 10, and your team's velocity at the moment suggests they should take 80 units into a sprint.  You put that issue into sprint 45 (along with issues adding up another 70 units), work on it, but fail to complete it.  When sprint 45 ends, the issue goes into sprint 46 automatically.  Assuming the velocity is still 80, then the team now has capacity to take in another 70 units.

The point here is that the work done on the issue in sprint 45 is irrelevant, the issue is still estimated at 10 units.

The scolding bit there is just that you're supposed to be avoiding pulling too much into the sprint.  Either the team is taking too much into a sprint, or the estimates on the story are wrong, or the story needs to be split up into fragments that can be completed in a sprint. 

There are always going to be times when something breaks and causes a story to roll over into the next sprints, that's one of the points of the Scrum process.  But you should not be planning for unknowns - you should be planning to take achievable work into a sprint, not planning for roll-overs.  If you're planning for roll-overs, you're not doing Scrum.

[Curt Holley]

What @Nic Brough -Adaptavist- said. ✔