Carrying forward unfinished work in Sprints

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”.

pasted image 0.png

If you find your team is moving unfinished work from Sprint to Sprint, here are a few suggestions of what to do instead:

 

1) Move it to the Product Backlog

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.”

Mike Cohn

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:

  • Navigate to 'Active Sprints' and click 'Complete Sprint’.
  • Select ‘Move issues to the backlog’.

Screen Shot 2017-11-08 at 5.15.46 pm.png

2) Carry it forward to the next Sprint

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:

  • Navigate to 'Active Sprints' and click 'Complete Sprint’.
  • Select ‘Move issues to the backlog’.
  • Drag the issue into the next Sprint.

 

3) Split and Plan for a Future Sprint

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:

  • Clone issue + adjust
    • Select […] > clone on the issue
    • Adjust the new issue accordingly 
  • New issue + move incomplete sub-tasks + link to old issue
    • Create a new issue
    • Using the ‘Link’ operation, link the new issue to the old issue.
  • Split
    • If you’re using Jira cloud or one of the latest server versions, you can right click an issue and ‘Split issue”.

Screen Shot 2017-11-08 at 5.17.01 pm.png

 

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.

4 comments

Ollie Guan Community Champion May 20, 2018

Thanks for sharing

What JIRA server versions are required to split stories? I am on 7.6

Splitting is found by following the 3 dots > clone then ticking the split option.....

I am finding some aspects of JIRA quite aggravating in this space, and it seems that some of the issues are quite long-standing and still have not been fixed.

There are two big problems for me if I roll-over work to a new sprint (whether via the backlog or whatever):

1. In the new sprint, the Task Allocation summary (the ellipsis button) that shows the total work assigned to each developer, is computed on the the basis of the Original Time Estimate for the task, and not the Remaining Time on the task.

2. If I start the new sprint, the Burndown computes based on this Original Time Estimate (it would seem) and not from the Remaining Time.

So, let's say I have a developer Paul who has two one week tasks on his plate and they get one complete and the other task runs into some problems and therefore needs a couple of days on the next sprint to complete. The Remaining Time on the task is set at 2 days.

I rollover the task into my new Sprint, but the Task Allocation summary shows Paul has 5 days of work assigned to him. So that's unusable, now I need to basically jot the times down on a piece of paper.

And then when I start the sprint, the burndown graph assumes I am burning down from 5 days of work rather than 2 days of work, meaning our burndown shows more work to be done than my developers have working hours for.

Now the really crappy thing in this situation is that the only practical ways I can fix this are to either duplicate the task and fix up the estimates in each task, which just results in unnecessary noise, OR I edit the Original Estimate on the time, which kind of doesn't make it "Original" anymore, does it?

Anyone got any ideas for how to handle this?

Comment

Log in or Sign up to comment
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,315 views 12 19
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you