Jira Cloud: Issues in Sprints without dates show up on Advanced Roadmap with dates

[Charles Jamison]

This is a problem for me as I am the administrator of the advanced roadmaps at a large company with many teams.  Some of the managers - all of whom control their own Jira projects - like to use sprints as "bins" to divvy up their work.  Thus they create "fake" sprints that never get dates.

As this might seem counterintuitive, let me explain the rationale for these "fake" sprints:  they are used as holding tanks / bins - which in essence means they get to have more than one backlog.  And the dates are NEVER set on these "fake sprints"/bins - doing so would defeat the purpose of them being de facto extra backlogs.  Inside of their projects and their boards, these "fake sprints" have no effect and serve their purposes well.  They get to have their cake and eat it too.  In essence they can split up their backlog by dragging issues into the sprints that are functioning as bins and nothing more.  One rational for doing this is if they have a giant backlog (and many of them do) they don't lose important story and tasks etc in a giant never-ending backlog that spills off the screen.  They can open and collapse the sprints that are "bins" and then when the time is right expand them, and actually drag issues out of these "fake" sprints and into sprints that have dates.

The problem for me in advanced roadmaps is this:

1. I have dates in the advanced roadmaps inferred from sprints.
2. I have the board as the issue source (this is necessary to infer the dates from the sprints)
3. Advanced Roadmaps seems to treat all sprints as having inferred dates even when there are no actual dates given for some of the sprints.  The dates are inferred from the way the sprints are arranged on the board's backlog page from top to bottom, so that when the algorithm for the advanced roadmaps gets to sprints that are "fake" sprints that HAVE NO DATE, it assigns dates to them by inferring the dates in sequence (descending downward on the page with a date range assigned for each "fake" sprint).
   
   

Is there any way to stop this behavior?  So sprints that are LITERALLY without dates DO NOT cause inferred dates in advanced roadmaps?  I do understand the necessity of this behavior for auto-scheduling - but it still seems like something that should be able to be turned off - as the sprints HAVE NO DATES.

And before anyone tells me I should tell the managers NOT to use Jira this way, I can only say I do not have the power to tell them what to do in their own Jira projects - so that is not an option for me.

[Walter Buggenhout]

Hi @Charles Jamison and welcome to the Community!

You took quite some time and words to explain how people in your organization are using sprints as something they are not intended to be used for. It is perfectly valid that people try to find ways to deal with challenges they face and it is equally valid and understandable that they try to use things they see and think are fit for purpose.

At the same time, it is also perfectly normal that a tool built for long term planning of agile projects may assume that a well defined agile concept of a sprint is being used as it was intended: as an recurring time box with a fixed length that helps teams create focus on current work and improve the way they plan and track this work along the way.

At a point when your organization seems to be scaling to a point where there is a need to start start looking at progress across different teams and projects, I don't see what would be wrong by telling people to make adjustments to the way they work, since now there clearly is an impact caused by individuals' behaviour on the teams / people around them. I have always been told that freedom is absolute, until the point that this freedom starts having an impact on other people's freedom ...

So, going against your last paragraph, I am going to tell you that the right thing to do here is tell people to do things differently. Simply because that is the truth. But I am telling you that with all the understanding that you are facing a change and that it would be easier if the tool could just fix things for you rather than having to tell people to change their behaviour. That is why I am going to also provide you with a few alternatives to managing these huge backlogs ...

Workflow

When people show up with huge backlogs, I am always wondering where these are coming from. Are people dropping all their ideas on a huge pile as soon as they pop up? Are they trying to run work that is actually service management work as if it is a project, thus facing a never ending stream of incoming request? Are they running a waterfall project taking many hundreds of days by importing hundreds issues at once into a single project, without any refinement?

In many scenarios, large volumes of work are not immediately ready for your delivery team. If you add the steps needed to get these issues from NEW to READY FOR IMPLEMENTATION as statuses to your workflow, you can perfectly separate the preparation work from the items ready for sprint planning by filtering out the irrelevant statuses. That will immediately reduce the size of your backlog as well as the need for fake sprints in your board.

Versions

If you let your team managers replace their fake sprints by versions in your project, they can keep working in almost the exact same way as they are doing now, but you are getting rid of the fake sprints immediately as well. Versions can be displayes alongside the epic panel in your scrum board, where issues can be added to them with a simple drag and drop.

Hope this helps!

[Charles Jamison]

Thanks much for the swift reply!  Very well thought out and I appreciate it a lot!  Kudos to you!