nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JiraAgile - Completing a sprint - Why do issues move to backlog instead of the next sprint?

Gregory Demotch

I do not understand when we complete a sprint, why do issues move to backlog ?

We are using an incremental/iterative approach, we plan our work for 3 sprints. (the sprints are running in parallel)

For us the idea that when we complete a sprint:

a) The issues that are planned or in progress automatically move to the next sprint

b) the issues which are in resolved (in test) stay in the sprint and remain visible in the work mode.

The idea is that this issues we delivered in Sprint 1 and should stay there for the QA team to know these we things developped in Sprint 1 and it's their backlog of tests of Sprint 1 and not mix them up with issues for testing in Sprint 2.

Both a and b are highly important for us, so we have no other choice but to keep running parallel sprint and only complete the sprint once all the issues are Done (tested and closed)

So the major handicap for us with this, is that we are obligated at the end of every sprint to MANUALLY move the issues to the next sprint and to make things worse, in Work mode which is comfortable, we cannot move issues to other sprints, so we have to go to plan mode for this. (I do understand that plan mode is for planning, but logically when you are in work mode, you should also be able to clean up (replan issues) your sprints before completing) ...

All of this put together, does not address our reality of incremental developpement and handicaps our useage of Jira.

Ideas?

Capture.PNG

Accepted answers

All comments

Kim Poulsen

I believe you should read the Scrum Guide:

https://www.scrum.org/Scrum-Guides

It is defilitely by design and within the Scrum framework that non-closed issues are not just propagated into the next sprint.

Most likely you have planned issues for the coming sprints and filled up your available time/points. Now when you are not finishing issues in a given sprint they will have to be re-evaluated for the purpose of assessing their importance in relation to the not yet started work. Maybe it became less important to do the the remaining work compared to other work etc.

If you are running three parallel sprints, having a QA team taking over tasks and wants issues to stay for a designated QA team you are by definition *not* using Agile Scrum.

I would suggest you drop sprints and use another (still Agile/Lean) method: Kanban.

Use swimlanes for each team and staging columns for upcoming work, and finally use low/high markers to control throughput.

If you want to use Scrum you definitely want to have a full cross-functional team that can both finish design and test (and everything else in your Definition of Done statement!) and parallel sprints should not be allowed unless you actually have a number of teams on the same backlog with these competences. (Restructure your teams)

Another way would be to not have issues containing design *and* test, but one for each and linked. It is more administrative work though as you effectively double your number of issues. However the advantage is that your QA team knows what to do when and only does it when the development issue is closed properly.

Gregory Demotch

"Now when you are not finishing issues in a given sprint they will have to be re-evaluated for the purpose of assessing their importance in relation to the not yet started work. "
- What does re-evaluation has to do with dropping my 10 remaining issues (planned and in progress)into the backlog of 300 issues ? Just on the practical side of things, it's difficult to retrieve them after. If I have 10 unfinished issues, there's 80% chance that they would end up in the next iteration (sprint) , otherwise they would not have been in the previous sprint in the first place.

Regarding Kanban, I thought about using it, but the problem is what do we base the swimlanes on ?
With the Agile Scrum we base swimlanes on sprints. A sprint (1 month) for us means one thing: by the end of the month developpement must be finished and handed over to QA. After 3 sprints we stop dev and do overall tests, then release.

So we do have this iterative planning approach, how do I do this with Kanban ?

Regarding parallel sprints we are only running them to avoid the necessity of completing sprint and each time lossing everything Not Done to the Backlog Monster

Kim Poulsen

You as well as me are aware that it is likely that not completed issues would move into the next sprint (some say they must be re-estimated, others say they shouldn't). However the Scrum framework does quite clearly specify what the flow of events is - and this is what the Jira Agile Scrum board complies with.

Just to say that non-Agile Scrum compliant teams will face issues with this board. There are lots and lots of questions here along the same lines of yours that prove that :-)

So... Looking at Kanban which I think is more looking to be your friend here:

Let's say I have three teams (Agile Lean, not Scrum):

1. Design
2. QA
3. Production

My workflow goes through Design to QA and to Production obviously and I want them all to work off the same backlog.

First of all I would create one Kanban board for each team. I would make a workflow that encompasses the three processes the three teams are using for example:

ad 1. Open->Requirements->Design->Implementation->Released for QA
ad 2. Released for QA->Test specification->Testing->Released for Production
ad 3. Released for Production->Internal deployment->External deployment->Done(Closed)

In Jira I will make a workflow with issue statuses like these above (11 statuses).

Now the (smart) thing can be done:

Each board maps only the issue statuses needed and have the rest unmapped. The effect of this is that everything on the backlog not mapped on the board will also not be shown. Also make sure the status in the last column is the one you want to designate 'closed' for that particular team. (All the unmapped statuses would stay in the "unmapped statuses" box on the left)

The dev team would not 'close' an issue they would 'release for QA' an issue and so forth.

Each team will only see what is relevant for them as well. This means that bottlenecks can be easily identified if one team runs out of issues which are ready for them, or vice versa if they are flooded.

This can be done using the Scrum board as well running sprints, but as I see it it is more a hindrance than a help for you when teams are split like this (non-cross-functional).

Swimlanes can be used for sorting on Epics, versions, components, priority, or whatever will aid the team (as they have their own board) sorting out what to do next.

unknown

This sounds more like a process/scrum issue than a JIRA issue.

Our scenario is such

Sprint 55 - Started and In progress

Sprint 56 - Not started but stories added for release planning purposes. Work is not being done in this sprint

When I complete Sprint 55 any stories/tasks with subtasks that are not closed, are moved to my next available sprint, Sprint 56.

I think the issue lies that you have started all 3 sprints so when you complete a sprint it won't allow you to add to the next sprint as this would be considered scope change and therefore will go onto the backlog.

Could you maybe not looking differently at how you structure your stories so that the definition of done is limited within the sprint? This would negate the need for the testing to be in a different sprint.

Gregory Demotch

Thanks for your excellent & useful comment. I've now settled into several Kanban boards for our different teams, yet still linking them to my "master" scrum board with parallel sprints. the reason is to base swimlanes on the sprints in work mode.

I'm only concerned with my original problem, finishing a sprint and manually moving issues. how hard would it be to develop a few settings to configure moving issues when completing a sprint?

Luckily we don't slice the devs too thinly so I've 40 issues for a sprint, but this is likely to get problematic lately when we start slicing like suggested in usecase 2.0. I've read the Scrum Guide, nothing there says that you shouldn't plan future sprints and nothing there indicates that the unfinished items should move to the backlog. The whole point of planning iterations is to be able plan things with a certain degree of certainty. In fact what upsets me is whenever people start talking about Scrum, Agile, JiraAgile, they forget the forest for the trees: these are ADAPTIVE practices and must adapt to the reality of companies.

Our reality is that a sprint is an iteration deadline for DEVELOPERS. the testers are less concerned about that, they start testing as soon as the features are delivered and will keep testing for the upcoming weeks these features. A sprint = maximum 1 month. We cannot fit analysis, protype, dev, testing, debug into 1 month, that's why we sort of a follow the sun.

IMHO - major problem with JiraAgile, it's so unbereable tight and not configurable. While previously named greenhopper - that's could mean it could hop left and right. JiraAgile captures it better - an perpetually moving in one Agile direction, that's pissing off 90% of its clients who cannot confine themselves (and bend the reality of their companies which they do not control) to one rigid, and frankly quite arrogant vision. We are paying for Jira + Agile (a tool that could help us be more agile in Jira), not Jira + someone's vision of the Scrum Framework

Radu Dumitriu

Well, not entirely true. We developed JJUPIN Agile ( https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.jjupin-agile ) to help people automate JIRA Agile tasks. You can create scripts to automatically move up from backlog to current sprint(s) the issues, rank them, etc, and run them via a gadget ...

Gregory Demotch

I'll try testing what you suggested, it surprises me what you say... What about stories which do not have subtasks ? do they get sent to the next sprint ?

unknown

Hi Gregory,

I did a test on a sprint that we just closed. Before the current sprint closed I created a new sprint (Sprint 67) but didn't start it. I then added to the current open sprint (Sprint 66) a story without sub-tasks, a story with sub-tasks and a task and left in an Open state.

When completeing Sprint 66 the remaining open tasks/stories with sub-tasks and stories without sub-tasks were automatically added to the not yet started sprint, Sprint 67.

Hope this helps.

Kim Poulsen

Hi Gregory. I totally agree that Agile Scrum is an adaptive approach to real world development in situations where there is more unknown that known material.

However the how "Agile Scrum" is practiced is not the adaptive part. Either you run Scrum or you don't. In particular if you are not using all of daily scrum, sprint planning, sprint review, sprint retrospective, having a backlog etc. you are not using Scrum.
Your teams might well still be behaving in an Agile manner - just not in the Agile Scrum sense.

As I experience Jira Agile its Scrum board is built for Agile Scrum, not "Agile Scrum - but..." if you get me. There comes the "tightness" of it.

I believe this is a design choice and unfortunately lots of Agile (but not Agile Scrum) teams regard this as a bad choice. I chose to embrace the full Scrum framework because we don't know anything better so we have no issues. I suppose once we get more mature we'll do most of it naturally and the rest we will try to make the tool assist us in doing or switch tool entirely.

Personally though I think the Scrum framework is pretty solid and promotes behaviour you'd want from any team regardless of the name of the framework.

Trying to change the way a company is working due to a tool is at best an up-hill battle. There is only one tool out there rated highter than Jira Agile and that is VersionOne (according to the 7th annual state of Agile Development survey).

Others would be LeanKit, Vendor Y, MS TFS at the 3rd place and down.

What I did was to introduce more and more of the Agile Scrum thinking into my team and gradually we eased into the change - and got out of the issue of us adapting to the tool or the tool adapting to us. We just fit eachother now.

Alexandru Bararu

I have a similar issue here, related to where an incomplete issue goes once the sprint is closed.

I could not find the attribute that makes an issue that is not "DONE" (in Testing for example) from a sprint that gets closed, move either to either the backlog or the next planned sprint.

I found JIRA working in dual mode, for some issues move to backlog and for some others to next sprint and I cannot find how to control that.

I believe it has something to do with either the status or the resolution of the issue but I find no exact answer.

In JIRA manual it sais:

Any issues not completed at the end of the sprint will be moved to the next planned sprint, as they did not meet the team's definition of "Done". If you do not have a next planned sprint, they will be returned to the backlog

But I cannot find how this definition of "Done" can influence the behavior.

Please help.

Kim Poulsen

Well that is new to me. I have never had what would amount to "random" issue moves on the planning board. Either all spill-over moves to the Backlog (and only if there are zero unstarted sprints available), _or_ everything moves to the next unstarted sprint. Regarding "Done", this is not a Jira property, but a team property. The DoD is the quality bar the team has set for itself. The DoD sets the standard for all non-functional requirements and maybe a few key functional ones (like response time or capacity). The conformance to the DoD is tested latest at the sprint review where stories are either accepted or rejected based on the DoD and functional requirements. In short: It has no influence on Jira whatsoever.

Andrew Wozniak

Hi, this is not an answer but a followup question.

What is the latest behaviour of an incomplete task in a closed sprint? Does it move to backlog or to next sprint if one has been created?

Thanks

Krishna_90207o

As of version 7.2.8, the behaviour is the same. When you try to close a sprint witn un finished stories, you will get a pop-up asking what you want to do with the unfinished stories. There you have the option of moving them to the backlog or to any available planned sprint. This option will only showup if you have planned sprints.

Krishna_90207o

Greg Carpenter

"It is definitely by design and within the Scrum framework that non-closed issues are not just propagated into the next sprint."

That's debatable and counter to what I was taught in Scrum Master Training. Here's how we work with Sprints.

As always, stories in the the backlog are in relative priority order.

We're a smallish team and we don't run parallel or overlapping sprints.

Unfinished stories in a completed sprint are, by definition, higher priority than anything in the backlog.

We don't debate priorities in sprint planning meetings (and definitely not in standups). When a team member feels strongly that the relative priority of one or more stories needs to be adjusted they make the case to the Product Owner out-of-band.

As the Scrum master I don't care about priorities in any other than an operational sense. During sprint planning meetings I start popping stories off the backlog stack until the next sprint is full.

I want a "Close Sprint" option to "move unfinished stories to the next sprint". Those stories are, by definition, higher priority than anything in the backlog.

In my experience, stories might be unfinished for several basic reasons:

The project is an early state and the team hasn't yet nailed the team's burn down rate
The initial sizing of a story was a bit off
The story is really an epic (the initial sizing was way off)

I was taught that a team should strongly resist the urge to re-size stories or change relative priorities.

(2) and (3) typically stem from a team not giving pre-scrum agile processes their due. The Agile Boot Camp I went through was four days long and the trainer didn't get to Scrum/Kanban until after lunch on the fourth day.

Johan_yi2m6g

When cancelling a Sprint, it is explicitly mentioned that the incomplete Product Backlog Items are put back on the Product Backlog.

During a Sprint Review, it implicitly says the same:
"The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities."

It doesn't say that incomplete Product Backlog Items are automatically put in the next Sprint. It talks about the Product Backlog being ready for the next Sprint.

You can always decide that incomplete PBI's are immediately put in the Next Sprint, but that's not always the case. In your team, it is by default the highest priority, but what if the tickets of the next Sprint are high priority tickets and the tickets of the to be closed Sprint are low priority? Do they still have a highest priority?

Remember, the Product Backlog is not a static list and can be changed at any time. Unfinished tickets can become less important, due to market change, requirement change, or any other change.

In practice, I agree that most of the times, the tickets are pulled into the next Sprint, but by default, this is not clearly stated anywhere.

Max Waterman

One supplemental question...

We are completing a sprint where we hugely over-committed, so we actually think we don't want to just move everything to the next sprint. However, we also know we don't want the issues in the backlog in some 'random' order...so, we are missing the option to specify 'top of backlog' vs 'bottom of backlog' which is on other screens. We want to move all the non-done issues to the top of the backlog, and re-choose (more realistically this time) which issues we want to commit to by moving those into the new sprint.

Is there a reason we don't have this option any more?

Sachin Raj_ychq42

Hi All,

I have an issue where all the closed issue in my sprint 1 goes to next sprint and I am using unique boards so that there is no duplication of the issues.

Can anyone help me in solving this issue.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

sprint

backlog