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

[Dan Walker]

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?

[Tarun Sapra · Accepted solution]

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.

[Dan Walker]

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]

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!

[Tarun Sapra]

Hello @Dan Walker 

Thanks for your detailed reply.

One of the central pillars of Agile is "Inspect and Adapt", which enables Agile teams to respond to change.

You have stated

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.

I feel this is not a good practice and the team is not mature in terms of agile delivery.

Based on the priority of the undone items of the sprint, they should be allocated to future sprints or at the top of the backlog. The future planned sprints should be flexible in terms of scope (staying still 2 weeks long), thus if an undone issue is moved to the future sprint then an currently planned issue should be descoped from that sprint. If descoping the future sprint is not possible then there is some serious lack of trust among all the stakeholders involved (SM, PO, Business).

I suggest you to read this article along with all the comments, it's very insightful.

https://www.mountaingoatsoftware.com/blog/three-mistakes-scrum-masters-make-and-how-to-correct-them

https://www.knowledgehut.com/blog/agile/incomplete-stories-tasks-in-an-agile-sprint

https://blog.codecentric.de/en/2016/09/scrum-unfinished-user-stories/

[Dan Walker]

Hi @Tarun Sapra

Many thanks for the further reading and your reply! You are right that as a team and/or organization we are not Agile mature, we are trying to adopt it however to give you some background we are a design and production agency first and foremost. I am a lead in the digital side of the business and for the most part we (digital) are embracing Agile with greater ease than the rest of the business!

The Account Management team for instance do lack alot of digital management knowledge, being evolved from a client services, production and design point of view, and the old business logic still exists whereby work is briefed, specced, time estimated, cost quoted on those times and deadlines set. This is where our challenge lies with the descoping aspect and why I elude to pushing issue to the top of the backlog, as the sprints tend to be defined according to time estimates and deadlines, often (but not always, depends if the issues are truly prioritized for the project in question!)  backlogging one feature is preferable to the business and client in order to deliver downstream functionality within said deadline.

So you're right, not so much a lack of trust from the stakeholders but maybe a lack of understanding!

I'd like to express my thanks for your time and advice Tarun, obviously you understand every business is different and adopting new methods can throw up all sorts of challenges, such as adapting the company or the methodology to compliment one another, as we discuss above!

To bring it back to the issue within the OP, we can't display backlog items in the active boards, and without parallel sprinting in Next Gen we can't make a "pseudo backlog" sprint to achieve this either, therefor it's a Project Management learning exorcise to keep sight of any tasks not complete at the end of sprints (if that's checking the backlog or otherwise the next sprint). Of course w can use the standup's as well to ensure PM's and AM's have good sight over issues that are overrunning or blocked.

Thanks again, I'll mark as the answer and get to reading your referenced material!