Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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.

15 comments

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?

Sure I know how to handle this! :-) 

Submit an issue to the Atlassian Support team, when they prioritize it after it's been voted on, they will select a release to add it to... If and ONLY IF, they're are enough votes.

 

More on that here -> https://confluence.atlassian.com/support/atlassian-server-bug-fix-policy-201294573.html

 

@Jabreal_Johnson - are you sure about that?

388 votes...... entering its 16th year of request and still no closer. Better still, the last update from the 18th February last year states that it will be reviewed in 'about' 12 months time. I'll hedge my bets and say this won't see the light of day, this side of 2020.

If it's not going to ever get done - I just don't understand why they don't say so?

https://jira.atlassian.com/browse/JRASERVER-2780

@Kevin Frey  @Kevin Frey  Did you ever find a solution for what you described above? 

Some sort of bulk move from one sprint to another sprint would be very helpful without having to first move to the backlog.

This feature request has indeed sat unfinished in Atlassian’s weekly sprints, but at end of each sprint it gets moved to Backlog and then subsequently manually added back into the next sprint -- Rinse/repeat.  It's a vicious cycle.

Its all about hope ;) haha

I have faced this similar problem. But how about creating more subtasks if parent story gets moved to next sprint? For eg., having two 'Implementation' subtasks can be normal but make sure their Fix version is different (in our case a sprint is a new version. So this might not work for all). 

 

@Andrew Sand @Kevin Frey Allocating separate tasks to single developers and measuring how much of it they have accomplished during the sprint isn't Scrum och Sprints. It is classical (old-school) task allocation. If this is important to you, you should probably look at some other tool or Jira template.

Scrum assumes the team is working on all of its work and that it will try to finish them in the order they are in the backlog. Iff this is the case *and* the team knows its velocity (in terms of stories statisticaly being finished in a sprint) then you will sometimes get a story or two that has been started but not finished. This limits your work in progress to one or two items and the effort that it "steals" from the next sprint is limited.

In the case you allocate one task/story/issue per person then you get as many items in progress as you have persons and the chance of all of them being finished at the same time (at the end of the sprint) is very unlikely. This gives you a very high risk of much undone work at the end of the sprint, and all in different tasks, leading to a lot of the administration you describe.

So I'd say that the feature you are looking for is not there by design. But there probably are a lot of other ways, even using Jira, that could give you what you want, just not Scrum and Sprints.

@Thomas I'm not exactly sure how to consume your response to be honest. To paraphrase your conclusion it feels like you are essentially saying "Suck it up princess, you shouldn't have that many tasks rolling over to the next sprint anyway."

So, let's just accept that maybe we have a couple of tasks that roll over into the next sprint. Guess what? Now the problems I have complained about above come into play just as much as if I rolled over 20 tasks in a sprint. I have to manually compute Developer time because JIRA uses Original Time Estimate not remaining to advise developer utilisation, and the Burndown for the next sprint is still wrong.

JIRA's job is to make my life easier managing a sprint, and this behaviour does not make my life easier.

When unfinished stories are moved to the backlog at sprint close, do they automatically go to the Top of the backlog ?

@Kevin Frey The same problem I'm dealing with. I exported data to excel to summary some reports, but I can't calculate the exact numbers because the Original estimates lasted in two or more Sprints.

Please assume that the developer is doing Task 1 at Sprint 1. Because of many reasons, Task 1 is not completed. My solution is to create Task 1 (phase 2) and rename Task 1 to Task 1 (phase 1) and change the status to Resolved. Based on this trick, I can calculate the developer's total time spent in Sprint 1.

Does it make sense to you?

Comment

Log in or Sign up to comment
TAGS

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you