Best practices for projects vs. epics?

Kevin (Fake) February 4, 2014

I just started at a new company and I'm in the process of figuring out how things are configured in JIRA. The dev team here is fairly small and all of the tickets they need to work on get lumped into 1 master "Tech" project. However, the tickets themselves span several about a dozen different products and initiatives. To signify which ticket relates to which initiative they use epics within the master "Tech" project.

Thoughts on this approach? Since each of these initiatives is a project unto its own, my instinct is to create standalone projects for each one, then create a MASTER agile board that spans every project we are working. This would give the product managers better control over their individual backlogs (since they'd now have their own JIRA projects), and when it's time to plan a sprint, we could pull tickets from all the various projects at the portfolio level.

I guess the root of my question is this: If you are PMing a team that is responsible for multiple initiatives (ie. each sprint will have a mishmash of tickets), is it better to house EVERYTHING inside 1 project and plan/start/close sprints from there (using epics to denote what the items relate to), or create a standalone project for each initiatives and manage a master board at a higher level?

Thanks for the help!!

3 answers

1 accepted

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

34 votes
Answer accepted
Kim Poulsen
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 6, 2014

I'll give you my opinion based on my experiences with multiple projects and Jira for what it is worth.

Rule 1: 1 product == 1 project

Why? Because your products will develop in different speeds, with different features and over time probably/hopefully with more developers on them.

Some of the benefits of this rule are:

  • Each product can have its own unique component setup - even though some component types like "Documentation", "UI" etc. likely will be common for all SW products
  • Each product will likely follow it's own release schedule. You will definitely want separate versioning for each product. Having this in one big heap in a single project is asking for trouble.
  • Bug reports for a specific product is much easier to perform if it is in its own project.
  • Stopping a product entirely is as easy as archiving the project - gone it is.
  • Setting up separate boards per product is much easier
  • Using Epics as epics are designed (if you are doing Agile Scrum) is easier/possible
  • Sprints can be designed/planned per project if wanted. They can also be planned on a "master board", så double benefit there.
  • Tracking the progress of each product is much (much much) easier when it is in its own project.
  • Having swim lanes for each project in the master board is easy to achieve.
  • Having a quick filter/card coloring per project is easy to create.
  • Looking at the project key in the planning view on the master board makes it clear which product an issue is for with a glance

Disadvantages of the rule:

  • Getting the total overview on a single board requires a slightly more advanced filter (project in (proj1, proj2, ..., projn) ORDER BY Rank ). But it is not that hard. Many of us do this rutinely. Adding "OR assignee in (John, Joe, Beth)" is also nice when you have a scrum team with members which are assigned issues in projects which are not part of your master board filter (large company illness - don't go there if you can avoid it).

If you are going to use Agile Scrum (and I will highly recommend that you do) use Epics per large feature and spin off Stories from that. Use Stories for features you can complete (for release) within a timebox of max. 4 weeks. Break down Stories to Task or Subtask for individual work planning.

I hope you can use this input.

Nandish Ajani November 25, 2017

the downside here is that you would never really be able to close the epic, so I wouldn't choose this path

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 25, 2017

Although, that is covered in Kim's answer.

0 votes
Daniel Sedlacek September 22, 2014

Depends on how big the projects are I would consider using Components instead of Epics to separate them. 

0 votes
Kevin (Fake) February 20, 2014

This is great! Thanks so much for the detailed answer, super helpful. Now we'll see what management says :)

Sarel Bar Ilan February 22, 2017

@Jeff Foss i wonder what management said and how it all turned out eventually smile