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; } } }

JIRA - Next Gen - Is it possible to show backlogged issues in current sprint board?

Dan Walker_evvse5

Hi there,

We are using JIRA Next Gen project template with sprints enabled and have just completed our first sprint!

However a few tasks where started and not completed. These where put to the back log and the next sprint begun.

However these issues, currently Status of In Progress sitting in the backlog, do not show up on the "Board".

It would be advantageous to see any issue that has been started (i.e. not ToDo) in the board so that should time allow these delayed, backlogged items can be progressed and not "disappear into the eather" for the developers and contributors that use the board and not the backlog (which is quite full of about 200 issues, mostly separated into sprints).

Is this possible?

Accepted answers

Tarun Sapra

Hello @Dan Walker

When you complete the sprint in next-gen project, then JIra offers the option to move the "not-done" issues to next sprint or backlog. If you choose next sprint then the issues remain on the board otherwise they are pushed in the backlog. But as there are too many issues in the backlog then ofcourse there is a chance of losing sight of these issues but that's how it is right now.

A small hack is that, you can create a dummy sprint called "Backlog sprint" and when you close a sprint then choose the non-done issues to movie to this sprint instead of the overloaded backlog.

All comments

Tarun Sapra

Hello @Dan Walker

A small hack is that, you can create a dummy sprint called "Backlog sprint" and when you close a sprint then choose the non-done issues to movie to this sprint instead of the overloaded backlog.

Dan Walker_evvse5

Hi @Tarun Sapra ,

Thanks for this, not sure if this makes sense however bear with me. We have already structured all our issues into sprints, so the Backlog area within the Backlog view (#Confusing!) is quite empty, the idea is that if new tasks appear and can't be scheduled into a sprint (becasue of storypoint limits) they go into the backlog area, likewise if an issue is not done by close of sprint it is backlogged.

Because we are using storypoints to limit the sprint payloads there's not really enough excess time in the next sprint to consume any incomplete tasks ergo they are backlogged.

This is fine in theory however as stated and as you point out once they are backlogged they disappear from the active board, not the end of the world but I did wonder if there's any way to keep sight of backlogged items that are not ToDo.

Good thought with the "Backlog" labeled sprint, however this does not work either as only one sprint can be run at once and they are not part of the active sprint (As above, I'm using Next Gen so there is no Parallel Sprints functionality JSWCLOUD-17195).

I guess I can create an issue filter with JQL to show Issues that are not ToDo, with no sprint assigned, then its just a matter of the project manager/lead monitoring this filter to ensure issues are not forgotten about

Thanks for your input!

Tarun Sapra

Hello @Dan Walker

The reason I suggested a "backlog sprint" was to track and monitor the in-progress issues which were not completed in the sprint. Ideally they should move to the next sprint because they are higher priority then the issues in the next sprint.

So, yes I understand about the sprint payload limit, but the non-done issues should always move to next sprint. It's upto the Scrum Master and PO to be aligned on what the team is working on based on the priority laid down by the business roadmap.

Still, if you don't want the non-done issues to go to next-sprint and as there are no-parallel sprints. Then I suggest you to create a Kanban board for all such issues so it becomes easy to track and work on them. But I reiterate that ideally the non-done issues should always move to next-sprint.

Dan Walker_evvse5

Hi Tarun,

Forgive me for asking then, this is purely Agile methodology semantics I guess (I have been studying and using agile a long time but there's always something to learn or do to make it fit a specific purpose!). I am curious over what happens specifically around the transition from one sprint to the next and dealing with overrun, incomplete and/or blocked tasks.

I understand your example but this in turn suggests there is resource spare in the next sprint to accommodate the tasks as they move into it. Indeed JIRA does throw warnings when you try to push new issues into an active sprint, saying it will affect delivery time ect.

Given that a sprint is likely to be defined before development cycles begin (businesses rarely give you a project that "ends when it ends" so often the dev roadmap is laid out already), the developers have provided time or complexity estimates (be it hours or storypoints), the sprints do not have spare time in them and are planned out to run concurrently in Agile how do you deal with potentially pushing that bloat/block/extra time from sprint to sprint?

To me, it seems that is what the "Backlog" is for, both semantically and in reality. An issue that is not complete but can't be completed in the allotted time should be backlogged until some time opens up in the future or hand around until the post project wrap up.

In summary, assuming pushing an issue (that is not a higher priority or a blocker for the next sprint issues, of course!) into the next sprint affects that sprints delivery time and thus can not be accommodated (communicating creeping deadlines to customers and clients is a big no-no for us!) what is the best Agile course of action?

> Extend the next sprint and deal with that issue of creeping deadlines?

> Backlog the offending issue and deal with it when time might be available or post project?

> Some other management method?

I appreciate your time discussing this with me and your knowledgeable input! Thanks Tarun.

I suppose this is one of those "making a methodology fit a real business process cycle" (hence why its a more semantic discussion now!) challenges. If you just want to fire some links my way for further reading please feel free!

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud