How best to plan issues on an Agile board using Epics, Versions, sprints etc

[H]

1. We would like to plan issues across multiple projects, ideally on one single agile board
2. We would like to group those issues into sequential blocks of time, each block corresponding to a target milestone.  Some of the issues need to be fixed by a given milestone. The rest can be assigned to a block based simply on priority (as each time block has a fixed resource that should be used effectively). The time period between project milestones can range from 2-6 weeks approximately.

I can create a Scrum or Kanban board and can use a JQL query to associate multiple projects to that board. But I am stuck as to what is the best approach for point 2 above. Should I use  the concept of JIRA Epics to group issues in accordance to milestones? Or 'Versions'? Or should I even group those milestones into sprints?

Currently I am using Epics, but this causing a bit of confusion amongst the team, because after some iteration our backlog currently shows epics in a mixed order, in the sense that some issues for epics for 'Milestone A' appear in priority lower than some issues for 'Milestone B'. This can be fixed of course by re-distributing the issues to the correct Epic, but I wonder whether this is the correct approach, or if there is an alternative approach that is recommended.

As a side-comment, I was planning in the future to use Portfolio to view work in a Gantt-chart manner, so if there is a recommended approach to organizing issues such that it works with Portfolio, any advice would be appreciated.

Another relatively minor confusion is that some team members have been using Epics in the past to capture issues for a given feature needed in our project, so cannot relate Epics to milestones. I plan to remedy that by using components for features instead. Thoughts appreciated.

[Scott Theus · Accepted solution]

Hi @Hsn,

I'd use versions to track your milestones. That would free up Epics for features, keeping them chunks of development work that are larger than a story, have several stories/tasks with subtasks associated, and cross sprints. Generally speaking, the team that is doing this currently is using what I would consider a best practice for Agile. I've always kept Components reserved for feature sets.

Release versions, however, can be timeboxed and road-mapped more easily in Portfolio, BigPicture, Structure, etc. when you start looking at the Program or Portfolio level. Versions can cross sprints and contain features that are defined in the Epics and Component feature sets. You can then set up a main Kanban board to track everything, and use a sprint board to prioritize the backlog and manage the sprint schedule. You can also set up Kanban boards for each release version that will help prioritize and track the release in relation to the current sprint. 

Edit...This also works when you have a sprint board that pulls issues from multiple projects; each Project would have its own release version, I do not believe you can use the same version across projects, but you can edit the sprint board's filter to pull from multiple projects and releases.

Hope this helps, 

-Scott

[H]

Many thanks for the fast response and comprehensive answer. This is very helpful, thanks.

One problem with moving to versions is, as you say, that it is not possible to create versions from within a board that contains issues from multiple projects. So I would have to present versions from the individual projects in that single board, which could get a little messy, which could again result in confusion amongst team members. It's a pity boards do not have an intrinsic feature for time-boxing issues. (Incidentally, I've noticed that other organizations seem to group all their JIRA issues into single JIRA projects, which I thought was strange but now I am starting to see why).

In any case I will see whether viewing the versions of each project in our single board will be clear enough or not. The board only maps 2-3 projects, so it may not be too problematic.

[Scott Theus]

I'm glad it helped. A quick clarification though...You can create boards with issues that are from multiple projects, and from multiple versions; boards are based on filters, so they are very flexible. You cannot, however, associate an issue in one project with a version in another; rather each project will have it's own set of versions. This works well when you have multiple software applications that have inter-dependencies managed at the program level. 

Since this is the case, now that I'm thinking of it, you could use individual projects as your milestones, track Components across projects, versions within projects, Epics for features, and still use a single sprint board and backlog based on a filter that pulls from the projects. That may make things easier for the teams to handle.

-Scott

[H]

Thanks again @Scott Theus. Sure, I think the points you made in your 'quick clarification' are already understood - specifically, versions are specific to JIRA projects. Sorry I was not wholly clear in my response.

Regarding your second paragraph, are you suggesting that I could set up a dedicated JIRA project for each individual milestone? Sounds like a nice idea, but the problem is that I won't be able to see the time-ordered grouping of issues on a board as I would with Epics and Versions. Moreover, my organization wants strict control on the creation of projects (although this could be reviewed). But perhaps I misunderstood you.  

Thanks again for your quick responses and help on this.

[Scott Theus]

Yes, that is what I was suggesting...a project per milestone. I tested this in my sandbox projects, here are some samples...

I created a filter: project in (PMTEST, PMTEST2) ORDER BY created DESC

I then created a new Scrum board using the new filter and started a sprint. (Note the issues from the two projects)

I added an issue from Project PMTest2 to Sprint 1

Then I pulled them into the gantt chart using BigPicture. I could drill down on these, but it's too hard to see in a screen shot. Expanding these out will show me the time ordered grouping I think you are looking for (if I had more sprints, versions, etc. set up) 

That may not work well for you, since the organization has such control over the creation of projects, and getting application add-ons can be tricky to negotiate as well. 

In any case, I hope I've helped you move in the right direction and not confused matters further! There are a number of different tools you could try, like Labels or a custom "Milestone" field that may be cleaner for you. 

-Scott

[H]

Once again, thanks for the quick response and in-depth investigation! Lots of things to think about. I need to go away and think/play with scenarios etc.

A minor comment: both of your screenshots look the same, so I couldn't see the extra PMTest2 issue you added to Sprint 1. But I believe you!

Another comment: our organization has provided Portfolio, and from what I can see so far can only provide Gantt charts around Epics or Stories. So I may be stuck with Epics after all. I'm pretty new with Portfolio so if I am wrong and this can be configured I appreciate hearing from you (or anyone else in the community).