Stories rolling over into next sprint

A few ideas:

• Is your team using a Sprint Goal?  If not why not?
• Is there a Definition of Done to help understand effort?
• Is this topic being discussed in the Sprint Retrospective?
• If a good number of stories roll over to the next Sprint, why not focus on completing those before anything else? Stop starting and start finishing.
• How might limiting work in progress help?

What do you mean by the team not having "cracked" their velocity? Once you complete one Sprint, how many stories or points did you finish? Don't give any partial credit. Then, in your next Sprint, bring in only that amount of work. If the unfinished work is still at the top of the Product Backlog, then you may not start anything else until that is done. But once you start getting work to Done, the jam of unfinished work should start to clear.

Also, be sure to consider capacity. If you have people working less, potentially taking on unplanned urgent work, or even doing something like cross-training, you'll need to reduce the work you bring in to free up space for this type of work. If you do end up having more time, there's plenty of opportunity to improve your processes and tooling, pay down technical debt, or even bring in new work, but be sure to consider the risks and benefits of each option.

I'd also recommend looking at how you carry out refinement. Poor refinement and a lack of an understanding of stories tends to be, in my experience, a leading cause of problems during Sprint Planning and lower quality work coming out of the Sprint. Talking about refinement and how that fits into Planning may be a good discussion for the Sprint Retrospective.

If you've got work "rolling over" into the next Sprint you have no effective Sprint boundary and therefore no Sprints at all. Of course the team will have problems "cracking its velocity". How can a team estimate capacity for a Sprint timebox that does not really exist?

The end of a Sprint provides a sublime moment of transparency to review what work has been Done and what work has not been Done. Any undone work should be re-estimated on the Product Backlog so it accurately reflects the totality of work thought to remain. That work may or may not be planned into the next or a future Sprint.

Don't overcomplicate your measures. Velocity is the rate at which work is Done. Half done work may reduce the totality remaining, but will contribute nothing to velocity and the forecast of how much work Developers can take on and complete.

Don't focus on velocity or even PBIs. 

Focus on the Sprint Goal and let the PBIs come and go as they please.

The PBIs and their story points will level out over time. Ensure your team know that you are not chasing points or velocity.

Delivering what the user wants and delivering it often should be the general goal, get feedback weekly from customer or representatives.

We are using sprint goals and bring stories in to support those goals.

We also review everyones capacity before starting the sprint and assign based on availability to 50%-70% of their maximum capacity depending on if they are leads with more meetings etc to attend or engineers with more focussed dev time.

The team estimates every story coming in to sprint, we have a DOD agreed.

Our velocity has historically fluctuated between 50% - 60% complete. I constantly recommend that the team bring in only what they feel they can commit to delivering based on the past velocity, however they feel the pressure of needing to do as much as they can to hit looming deadlines and being optimistic that they can get everything done, despite the sprint reports showing they cant.

Thank you all for your feedback there are definitely some things here which we can look at, backlog detail and understanding (we dont have a PO so this is a big gap), focus on the stories which have rolled over.

We also review everyones capacity before starting the sprint and assign based on availability to 50%-70% of their maximum capacity depending on if they are leads with more meetings etc to attend or engineers with more focussed dev time.

Instead of using individual's capacity do a team capacity.  By doing individual you are promoting the practice that each individual has to be busy working on their own stories.  Team capacity can help the team understand to focus on the entire Sprint Backlog and not just the ones assigned to me.  I also suggest that you don't assign tickets to anyone. This again promotes individual effort over team effort.  

Our velocity has historically fluctuated between 50% - 60% complete.

Is this 50-60% of the story points done or 50-60% of the stories done?  It appears that the team is having difficulty in estimating the size of the effort.  I suggest shifting them away from using story points to measure velocity and have them focus on throughput or cycle time which will measure the number of actual stories being completed. Story points are guesses based upon limited information.  Cycle time and throughput are based on actual work associated to each story. After you start looking at those two metrics use them to discuss the team's estimating ability.  Ask why a story pointed as a 5 took longer than one pointed as an 8.  Or why another 5 took less time than a 3.  Have them critique their estimating skills.  You might also find that the team likes using throughput and cycle better as a way to measure their velocity and you could switch to using XS, S, M, L, XL as your estimates instead.

We also review everyones capacity before starting the sprint and assign based on availability to 50%-70% of their maximum capacity depending on if they are leads with more meetings etc to attend or engineers with more focussed dev time.

This does not sound correct.

Try looking as a team, what is the capacity of the team, what is the avg velocity over the past 3 sprints.

I would not focus on individuals.

Does the team have all the skills to deliver the goals? if people have holidays etc will this affect the delivery of any of the items?



If the team is delivering 60% then reduce the capacity for the next sprint by 40%. Measure and repeat. Even if this means your down to 2pts per sprint then so be it, that's what the team can deliver.