nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Hsn · 2018-12-19T15:09:36+00:00

* We would like to plan issues across multiple projects, ideally on one single agile board * 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…

Hsn

We would like to plan issues across multiple projects, ideally on one single agile board
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.

Accepted answers

Scott Theus

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

All comments

Scott Theus

Hi @Hsn,

Hope this helps,

-Scott

Hsn

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

Hsn

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-server