Jira Roadmaps -- how to extend stories across multiple sprints

[PabloS]

We have many sprints created going out several months into the future.

We are now trying to position stories on the roadmap, but it looks like Jira wants them each to occupy a single sprint.

This is not how the world works. 

Is there a way to make the bar representing a story's start/end date stretch across multiple sprints? 

[Nic Brough -Adaptavist-]

There is a fundamental misunderstanding here.

You say "... but it looks like Jira wants them each to occupy a single sprint.  This is not how the world works. "

Jira expects them to be in a single sprint because that is how Scrum works.  It's irrelevant how you think the world work, because one of the main things about Scrum is that stories should be deliverable within a sprint.  It does not always happen, and Scrum recognises that, but when it does not happen, the fact that it has failed is an important part of the feedback into improving your processes.

Jira is just following the principles.  If you think a story should go across sprints, you have not understood what a sprint is for.  When a story goes across sprints, it shows an exception - we got the story estimate wrong, we should have split it up, something else got in the way, we got something else wrong, etc

In the real world, a story never goes across sprints.  Not without screaming "something is broken, this is an exception, and your reporting should be saying so"

[Nic Brough -Adaptavist-]

Sorry, I should have also said - Epics are what you are looking for here, not stories.

Epics contain stories.  Epics are expected to last for many sprints (and not be part of sprints - they only become "complete" when all of the stories within them are done.  How the stories get done is an irrelevance to the Epic, it just gathers things together)

[PabloS]

Thanks. I appreciate your perspective but we are not talking about scrum here.  Scrum has nothing to say about roadmaps. Roadmaps are not scrum planning tools. Roadmaps are business tools.  In that world, feature development often extends across multiple sprints. 

Note: I'm scrum guy, so no disrespect is meant, but that world is more "real" IMO that scrum. 

[PabloS]

Agreed that Epics are a better solution.  I can roll with that. 

[Guilherme Coelho]

Hi @Nic Brough -Adaptavist-, thanks for the feedback.

And can I use the start date of an issue to change the bar on each issue?

All issues show a bar for the duration of the entire sprint but it would be great to be more granular than that.

Thank you,

[Nic Brough -Adaptavist-]

No, that's the point - an issue should be dealt with in a sprint, you don't micromanage it down to when it's going to get done in the sprint, that's up to the team.  You can only assume "they said they'd do it in sprint X", so the start/end date is drawn from the sprint plan.

And the bit I didn't see last year - " Scrum has nothing to say about roadmaps".  Indeed it does not.  But your roadmaps are using Scrum's sprints as markers here.  Which takes us back to "if a story doesn't fit in a sprint, it's not defined correctly, it should be split or made into an Epic"

[John Ineson]

I never asked for my roadmaps to be bound to sprints, but if it's a Scrum project, I don't seem to have any choice. That is the mistake.

For example, in some of my epics, one step is an external process that needs 6 weeks. I want to represent that on a roadmap. Impossible without creating a whole new epic for that process. And that would clutter up the roadmap.

[Tim Brown]

@Nick When a story happens to go longer than one sprint (QA testing or a bug to be resolved) how can the timeline show that it was started in one sprint and ended the next?  It currently only shows the single, active sprint. 

[Nic Brough -Adaptavist-]

Yes, that's correct.  Where you started on a story is irrelevant in scrum, the timeline is showing the sprint you have said you will complete it in.

[Tim Brown]

It is very deceptive when looking at a gaunt chart format. 

From a management perspective, how do I evaluate if the story or team completes the stories in the sprints or are rolling over sprints? Did we evaluate and scope the story correctly if we can't see that history?

[Nic Brough -Adaptavist-]

A scrum team doing sprints should have a scrum master who reports the velocity or success and failure rates for their team up to management.  If managers decide to investigate, then yes, one question that the team will be able to answer is whether the problem was scoping.  Or estimation, or committing to too much in the sprint or under-resourcing, or any one of many other reasons.

The fact a story rolls over tells the team they need to be able to explain it, the rate of rollover tells management nothing on its own.

[Ilze Leite-Apine]

Hi @PabloS 

You may want to explore the possibilities of Jira apps. eazyBI for Jira is reporting and chart app, and analyzing issues over multiple sprints is possible there.

You may want to check out the eazyBI demo report Sprint timeline in epic: all sprints where the epic stories were included are displayed in the report timeline. 

To get this report for multiple epics, you may move the "Epic Link" dimension (or use "Issue" dimension Epic hierarchy if you want to see similar information for stories as well) in the report rows:

Please do not hesitate to contact support@eazybi.com if you have any questions!

Best, 

Ilze, eazyBI Customer Support Consultant