Organizing Sub-Projects with Components and Epics

Kyle Miller October 4, 2013

I am trying to set up JIRA after switching from an overly customized Redmine install and am looking for some advice on how to best organize our projects and sub-projects across various business units and development teams without too much customization. Our product team is relatively small (25 people) and most of us are using scrum.

I am thinking about creating a master project called Product, and using components to organize sub-projects that do not have defined start or end dates (e.g. API, Mobile App, Website, etc.), and using epics to organize sub-projects that do have defined start and end dates (e.g. Holiday Campaign, Supply Push, etc.). I would then create an agile board for each scrum/kanban development team, filtered by assignee and relevant component, and swimlaned by epic to show what teams need to be working on.

Is this crazy? Are we preventing a more useful usage of epics in the future by using them to group our sub-projects now? How should we organize larger epics that could be broken up into smaller chunks (e.g. Holiday Campaign Frontend vs. Holiday Campaign Backend)? And finally, could we accomplish the same thing without using epics at all with an add-on like Structure?

Any advice would be very much appreciated!

2 answers

1 vote
Igor Sereda [ALM Works]
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.
October 6, 2013

Hi Kyle! It's cool to get in touch here :)

From the Structure perspective, here's what you can do - and we know people are doing something like this:

  • Create a separate issue type that represents a project. The issues could be in your "Product" project. The benefit of having an issue for the project is that you get custom fields and search.
  • Organize projects hierarchically in the Structure Board.
  • Define your Agile boards by using a filter with S-JQL conditions (with structure() JQL function) based on the structure -- for example, you can select all stories under a specific "project" issue in the structure. See details here: https://wiki.almworks.com/x/coPE

Then you'll have Epics freed for any other purposes. If you use epics to group stories in the structure, you can also use Agile synchronizer to translate that into epic-story relationship in the Agile board.

Hope this helps!
Igor

Kyle Miller October 6, 2013

Thanks, Igor! I installed Structure and the team is giving it a look. I really like the visibility it provides but we are trying to avoid creating too many custom issue types and fields unless we absolutely need them. Let me see if we can accomplish the same thing without a custom "Project/Product" issue type.

Igor Sereda [ALM Works]
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.
October 7, 2013

Sounds reasonable. Btw, we're now starting working on Structure 3.0, which will let you have other things in the structure besides issues - such as projects. So you'll be able to set up a project hierarchy made of projects. (No ETA yet)

0 votes
Kyle Miller October 6, 2013

To make this even more complicated, we have some Scrum teams and some Lean teams (using Kanban boards), so if we go down the epic route, those teams won't be able to view their workload by epic swimlanes without a lot of JQL queries.

Suggest an answer

Log in or Sign up to answer