You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The plan looks great. The team is on the same page. Your Product Owner is happy. But then it happens…
“We need to get this done, ASAP!”.
Your team is now in firefighting mode. And the plan that was once feasible, well, it’s not so feasible anymore. The only way to complete the original plan is to “get it done next Sprint”.
If you find your team is moving unfinished work from Sprint to Sprint, here are a few suggestions of what to do instead:
First and foremost,
“When a product backlog item is not finished at the end of an agile sprint, it should first technically be put back onto the product backlog. Work never moves automatically from one sprint to the next.”
At the end of a Sprint, any unfinished work moves to the Product Backlog for the Product Owner to prioritise. It’s very likely a team will continue to work on this unfinished piece(s) of work, but it shouldn’t be assumed.
To do this in Jira:
If the unfinished work will be completed in the next Sprint, leave it untouched. But, if you’re using story points to estimate, only count points completed for the piece of work when it is completely finished in the next Sprint.
To replicate this in Jira, do the following:
If the unfinished work will be deferred to a future Sprint, then create a new issue describing the subset of the work that will be delivered in the future Sprint.
If you’re using story points to estimate, you can count partial points for the original piece of work. For the new issue, as always, estimate it like you would anything else.
To get this going in Jira, you want to either:
It’s natural for some work to spill over into future Sprints from time to time. It’s just one of many pitfalls teams face during their Sprints. Make sure to gather data, inspect and adapt and you’re team will be back up and running in no time.