Best practices for projects vs. epics?

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

25 votes
Accepted answer

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.

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

Although, that is covered in Kim's answer.

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

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

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

Community showcase
Posted Tuesday in Statuspage

Introducing Statuspage Getting Started guides! First up: What is Statuspage?

Over the next several weeks we'll be sharing some of our Getting Started guides here in the community. Throughout this series of posts, we'd love to hear from customers and non-customers ab...

191 views 4 1
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you