Community
Products
Jira
Questions
Best practices for projects vs. epics?

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

34 votes

Answer accepted

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.