Carrying forward unfinished work in Sprints

[#1]

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:

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

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

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.

[Ollie Guan]

Thanks for sharing

[Kira]

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

[Reg Hawkins]

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

[Kevin Frey]

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?

[jabrealmoe1]

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

[Darren Smith]

@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

[Andrew]

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

[GASPARE BONVENTRE]

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

[Neil Sheridan]

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.

[Andrew]

Its all about hope ;) haha

[Sujit Joshi]

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

[Thomas Nilefalk]

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

[Kevin Frey]

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

[S J]

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

[Nguyễn Đăng Quang]

@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?

[Danno]

Interesting to see other's have some of the same issues. We are trying Agile in a more traditonal hardware engineering company and have a software team that was using Jira beofre the rest of us had to come into the fold.

We typically have things go longer than one two week sprint. We let them migrate to the next sprint first and then decide if it stays in the next sprint or moves to the backlog before we start the next one. Most of the time it is because we don't break the work into small enough chunks and haven't gotten the hang of estimating difficulty especially since we try to have people estimate if it can be done within one sprint.

[Ian Taylor]

It sounds like to me that folks are assigning tickets that are too big for one sprint. If you're estimates are off, then re-evaluate your keystones. if it's too big, then break up the task into smaller increments. Clone and split as it says above if you need to. 

[davesoft11]

When I go to Complete the Sprint, it says "Sprint cannot be completed as there are incomplete subtasks on the following issues". And it's right. But that's the whole point of this thread: I want to be presented with the option to roll those incomplete ones forward to the next sprint (or move some to the backlog). So why is it complaining that some aren't done?

[davesoft11]

Update: since sprints wait for no man, I was forced to use the Bulk Edit feature to Edit the sprint field with the numeric value of the new/active sprint in order to keep things moving forward.  But this is a clumsy, tedious, and broken workflow.

So if someone can please comment on my previous post, I'd very much value the feedback. Thanks!

[Danno]

@davesoft11 I get the issue with sub tasks being a problem. We made it a rule that all tasks are tasks in SCRUM teams. You can force that issue by removing sub-tasks from the project. Secondly, you could "enforce" the SCRUM artifact of delivering a working increment. If it isn't finished it should go back to the scrum backlog for evaluation in the planning process unless the team decides they should carry it over to the next sprint with the idea that it just s need a bit more work to complete.

You can also bulk move the unfinished tasks back into the backlog first and then close the sprint and then repopulate the new sprint with those tasks that need to continue on.

I don't think bulk editing the sprint field is the way to go as you would lose the information that that block of work required more than one sprint even if they weren't consecutive. It should help with future planning/scheduling if another similar project was started. The team should recognize it was more difficult than the first time it was estimated and Stories and tasks were created. Hopefully they will break it down into smaller chunks of work.

I hope that helps.

[davesoft11]

@danno, thanks for the reply. See my comments...

I don't think bulk editing the sprint field is the way to go as you would lose the information that that block of work required more than one sprint even if they weren't consecutive. It should help with future planning/scheduling if another similar project was started. The team should recognize it was more difficult than the first time it was estimated and Stories and tasks were created. Hopefully they will break it down into smaller chunks of work.

Agreed. All previous sprint IDs are deleted in the process; that's why I called it broken :-)

You can force that issue by removing sub-tasks from the project.

If you mean to live without the ability to create sub-jira, hopefully you get that that is not plausible :-) I'm open to input. But we use subjira to break down an atomic deliverable into specific action items. Those action items can be developed by separate staff and may involve different software components. But none of them is independently deliverable: they must deploy as a unit.

Secondly, you could "enforce" the SCRUM artifact of delivering a working increment.

Believe me, I try to break down deliverables into smaller, more agile components that can be deployed more rapidly. But in this case, there's nothing ready to deploy. In fact, that's why the subtask it's complaining about is not marked as done.

If it isn't finished it should go back to the scrum backlog for evaluation in the planning process unless the team decides they should carry it over to the next sprint with the idea that it just s need a bit more work to complete.

Yes, carry it over to the next sprint, which is exactly what I'm trying to do and it isn't working.

You can also bulk move the unfinished tasks back into the backlog first and then close the sprint and then repopulate the new sprint with those tasks that need to continue on.

Can you explain this bulk move? Since you don't recommend using the Bulk Edit feature to change the Sprint field, how do you do this bulk move? Do you work from the Backlog page and just drag them from the active sprint to the backlog panel? 

I get the issue with sub tasks being a problem. We made it a rule that all tasks are tasks in SCRUM teams.

I'd love to understand the design philosophy that you're touching on better. When you say "all tasks are tasks", can you explain further? What is the alternative model that you use in other types of teams?

[Danno]

@davesoft11 Whew! that is a lot to cover.

If you mean to live without the ability to create sub-jira, hopefully you get that that is not plausible :-) I'm open to input. But we use subjira to break down an atomic deliverable into specific action items. Those action items can be developed by separate staff and may involve different software components. But none of them is independently deliverable: they must deploy as a unit.

My scrum master training reinforced this idea that any sub-tasks that are created should really be a task unto itself. It could be the reason for the tasks not getting done in time. The sub-tasks weren't created in the planning process. My point is we do w/o sub-tasks in our teams using sprints. Sub tasks are fine with Kanban boards but as you found out there are issues in sprints. I'm curious about your comment of having other team members due the sub-tasks of the main one. Can you confirm that you are actually capturing that in your sprints? To simplify, it sounds like you might be missing out on some critical data to help with resourcing projects. Since I don't use them in sprints I would have to run a quick sandbox experiment to prove that out.

Believe me, I try to break down deliverables into smaller, more agile components that can be deployed more rapidly. But in this case, there's nothing ready to deploy. In fact, that's why the sub-task it's complaining about is not marked as done.

I gotta ask. What exactly is your role where you are at. It is a mistake for a scrum master or product owner to break down the project into the needed work. Yes, it is the product owner to prioritize what should be worked on but now how to work on it. That should be the Team giving that input.

Can you explain this bulk move? Since you don't recommend using the Bulk Edit feature to change the Sprint field, how do you do this bulk move? Do you work from the Backlog page and just drag them from the active sprint to the backlog panel?

Sorry for the confusion. I meant bulk edit > Change Status. If it's one or two, right click or drag an issue back to the backlog or if it's a large number bulk edit the Status.

Keep asking questions. That's how we all learn. Even though I'm a certified Scrum master it's not my day to day job but I do suggest you look at getting some training or reading up as much as you can.

[davesoft11]

Slightly different problem at the end of this sprint cycle. 

I am avoiding the bulk edit feature to roll (incomplete) jira forward to the next sprint, because of the previously discussed issue where it erases the sprint history. Instead, I'm dragging on the Backlog page, at which point the below message is presented:

Since I didn't remember 6 issues being done, I cancelled this and spot checked 6084. Sure enough, 6084 is at a status we call "READY ON STAGING", which is blue (aka In Progress). It does have one sub-jira, and that one is CLOSED (and green). But 6084 is most assuredly NOT DONE. And it would be very bad for Jira to remove it (it will disappear from filters and never get deployed). Worse, this screen isn't enumerating what the other 6 jira are that would be adversely affected this way, so I don't have an easy way to go hunt them down and "fix" them manually. 

So this is a mess.

Can someone clarify what the definition of "done" is in this context? 

Tip: it must NOT be that it has a Resolution, since many more than 8 jira have a (non-NULL) resolution.

Thanks in advance!

[davesoft11]

No one knows the definition of "done" in this context?

[Kevin Frey]

I am guessing (but do not know) that it is the same set of statuses that is used to define the "Done" swimlane for the Active Sprint?