Tickets consistently being rolled over to next sprint
Hi all,
I’m a Scrum Master working with a team that consistently runs into the same challenge: in a 2‑week sprint, we complete development on a number of Jira tickets, but testing often can’t be finished before the sprint ends. This means many tickets roll over into the next sprint, which impacts our velocity and makes our reporting look unstable or inaccurate.
A few things we’ve noticed:
- Development is usually done on time, but QA capacity becomes the bottleneck.
- Tickets end up carried over even when they’re “dev complete.”
- Our velocity ends up lower or inconsistent because many stories don't reach “Done.”
- It creates friction during sprint planning because we start each sprint with a pile of unfinished work.
My question:
What approaches have you used to reduce or avoid unfinished tickets rolling over due to testing delays?
Do you adjust your Definition of Done, restructure your workflow, change how you slice work, or handle Jira tickets differently?
I’m looking for practical strategies or changes that have helped your teams get more work to “Done” within the sprint—or improved the accuracy of velocity reporting when full completion isn’t always possible.
Thanks in advance!
Some questions:
- It sounds like Development and QA are two separate groups with a hand-off. Why do you need this hand-off?
- You don't mention the Sprint Goal at all. Are you defining a Sprint Goal at Sprint Planning? Are you able to achieve this Sprint Goal with the work that the team completes within the Sprint?
I’m looking for practical strategies or changes that have helped your teams get more work to “Done” within the sprint—or improved the accuracy of velocity reporting when full completion isn’t always possible.
Limit the work in progress during the Sprint. All of the Developers -- including testers -- ought to focus on completing one or two tickets at a time, Done, finished, and tested. Then they can pull the next into progress and focus on completing that one.
In other words, at any given moment everyone ought to be focused on completing the same one or two tickets. With that discipline and agile hygiene in place, by the end of each Sprint they could complete more than enough work to meet their Sprint Goal. Remember that in Scrum contingency is found in scope. Not all of the work in the Sprint Backlog might be completed, but any remainder might be contingency which they can afford to sacrifice, and then re-estimate on the Product Backlog for consideration in a future Sprint Planning session.
There is no "rolling over" of work in Scrum, since that would erode the Sprint boundary. It would rob the team of an inspect-and-adapt opportunity, and disfranchise the Product Owner from deciding whether that work is still a priority or indeed necessary at all.
This comes up often and I agree with above posts that removing silos, involving QA early, and limiting WIP are needed practices. Maybe some ideas to consider:
During Sprint Planning, estimate everything required to reach Done; not just development work.
Avoid overcommitting. QA becomes the bottleneck when too much work is started and testing is left late in the Sprint.
Slice stories smaller. Break work into 2–3 day slices so testing can start earlier.
In short:
- Plan all work needed to get to Done
- Avoid overcommitting
- Slice backlog items smaller (vertical or horisontal)
- Entire team is responsible for testing
A dissident view. If automation is not part of the Definition of Done, it can be split into a follow-up PBI as a horisontal slice, provided the Increment remains releasable. The idea is to move automation away from the "QA peak" at the end of a Sprint and complete it during the "QA lull" at the start of the next Sprint. However, the team must be disciplined in following through, otherwise automation work will slip.