, I want an option where the board will include *all* of the stories associated with an Epic, regardless of whether the stories meet the criteria of the board filter

[Omar Atta]

I want an option where the board will include *all* of the stories associated with an Epic, regardless of whether the stories meet the criteria of the board filter. That way, I can filter on just the Epics, and not have to worry about setting the same field values on all the stories in order for the stories to appear in the board.

[Nic Brough -Adaptavist-]

That renders the board filter pointless, and hence it's not implemented (or particularly useful in the places I've worked)

Closest I can think of is using a board filter that says "epic link is not empty", but that won't be fully automatic, it will simply catch all issues that are in any epic, irrespective of what epics are on the board.

[Ken Marsh]

Why does that render the board pointless? 

This is a very simple request to me.  Here is what I'd like to achieve and please help me understand why I should eat the horse in one bite instead:

1. We would like to put in all of our conceivable epics and associated stories (may be hundreds or thousands)
2. We would like to collaborate to decide which epics we are currently committed to delivering.
3. I'd like to see a board which shows currently committed epics and their associated stories.

That, to me, doesn't make a board "pointless" it makes it quite useful to visually digest the information.  If you could help me understand where my thinking is unhelpful for managing a backlog, please enlighten me.

Or better yet, suggest how I can achieve this view of my epics and associated stories from which I can plan sprints.

Thanks.

[Ken Marsh]

To the original point.  if the epic is committed, the stories may not yet be committed so they won't show in the board: hence the desire to show and/or be able to filter on the story status independently from the epics.  Is it not common for stories, epics, bugs to have different workflows?

[Nic Brough -Adaptavist-]

A board is supposed to represent a set of issues you deliberately select to work with.  So having it include a swathe of issues you are not selecting contradicts it.  It makes your choice of filter utterly pointless.

Except in the one case where your board filter really is "everything in these epics".  Which you can, of course do - that's not pointless.  It's just all the cases where the users have selected different criteria where the board is useless.

Anyway, you've got some good points here, which I can take a swipe at

>We would like to put in all of our conceivable epics and associated stories (may be hundreds or thousands)
Humans can't work at that scale (and the server would struggle with such a board).  That's why we have things like stories and epics - to break it up into chunks humans can plan at.  With thousands of stories, forget it, work with the Epics for the overall planning and then go into them for the details once you've got the broad overall stuff outlined.

I'd be tempted to look at other planning options there too.  I'm a bit biased as I've been playing with Portfolio recently, but that could be a help here (no boards, but lots of extra planning tools like .themes and initiatives)

>We would like to collaborate to decide which epics we are currently committed to delivering.

Absolutely what an overall plan should be for

>I'd like to see a board which shows currently committed epics and their associated stories.

If it's going to cover everything, you're going to struggle.  Again, you probably want to focus on parts of it and drill down when required.  I'd be leaning towards a Kanban board (or many of them) only showing Epics as a starting point.

>if the epic is committed, the stories may not yet be committed so they won't show in the board:

And that's correct, because a Scrum board only shows work in the current sprint.  It's not supposed to show you work that you have not committed to, as you don't care about that work in the current sprint.

I think you need to be looking at that outside your Scrum boards, because showing non-sprint stuff on the board makes the board useless by cluttering it with irrelevant things.

>Is it not common for stories, epics, bugs to have different workflows?

Very, and it's fully supported by JIRA (Core, Software and Service Desk), even expected - if you create different types of projects, you'll find they have different workflows even before you start building your own!

[Ken Marsh]

Hey Nick,

First of all, thank you very much for sharing your insights on this.  I appreciate getting your view on it.  I think I was hoping for something that would let me more easily manage a multi-year initiative and it sounds like I'm kind of approaching it from the wrong direction.  I'm going to go have a think about this more and see how I might make it work.  Likely the pain of moving from a hierarchical way of thinking to something else (whatever agile is; which I'm still trying to get the whole picture of)

Thanks again, I'll take a look at Kanban and see what that does.  I definitely get that a scrum board would only logically show the current sprint stuff.  On the bigger picture, selecting what should go in a sprint is more what I'm struggling with in the current implementation.  The reason I asked about the different workflows for different items is that it seems the board can only easily be filtered by a single status or set of statuses and those will apply equally to epics and the associates stories.  So if I filtered on epic status "committed" (to start doing) then none of the stories (currently "proposed") wouldn't be shown on the planning board.  There may be a neat way around this with some JQL I was just surprised that it wasn't more natural. 

All the best,

-Ken