Guidance for Organizing Boards in a Company-wide Project with Multiple Engineering Specializations

[Lance Waldrop]

Within our engineering team, individuals specialize in different areas such as automation, cloud computing, and on-premises solutions. While some engineers may focus solely on one area, others might work across multiple domains. Tasks within each specialization tend to be distinct and don't overlap significantly with others. We aim to maintain simplicity by consolidating all issues within a single project but segregating them effectively across various boards. What specific techniques can be employed to categorize issues according to their respective areas upon creation?

[Mark Segall · Accepted solution]

Hi @Lance Waldrop - The two most common options would be to either use Teams or Components to segregate the type of work and then build your boards accordingly.  The main difference is that a "Team" is singular where you can only assign to a single team and Component is multi-select. 

In your note, you mention that "Tasks within each specialization tend to be distinct and don't overlap significantly with others" and that leads me to think Team is the right solution.

You would just need to ensure that the Team field is required in your field configuration to ensure you do not end up with "backlog purgatory" scenarios where someone creates an issue but does't assign a team causing it to be absent from every board.

[Lance Waldrop]

Hi @Mark Segall

I really liked the Teams idea, but I encountered a couple of issues during testing. Firstly, if our PMO were to create an Epic and then proceeds to create Stories, Tasks, and Bugs within the workflow the child issues won't show up.  I attempted modifying the JQL for the board filter to look for both Team and Child Issues but without success (I found examples where you can do this with issue key hard coded, but none where it's not.)

JQL functions | Jira Work Management Cloud | Atlassian Support

The second potential issue although more minor is when creating a Team, you have to add an individual to that Team, so does this mean that someone will have to join the team (potentially requiring admin control) or can issues still be viewed without membership?

If you have any suggestions around these, I'm open. 

[Mark Segall]

if our PMO were to create an Epic and then proceeds to create Stories, Tasks, and Bugs within the workflow the child issues won't show up

Is the Epic following the team or will work regardless of team roll up to the Epic?  If the former, you can just use the Team field on the Epic as well.  However, if the Epic can include work for say, both automation and cloud computing, that may be an indicator that Component is a better path to take.  In that situation you could apply both components to the Epic so the Epic shows on both team boards, but they only see their respective child issues.

As for "won't show up", this comes back to making sure the Team or Component field is a required field.

when creating a Team, you have to add an individual to that Team, so does this mean that someone will have to join the team (potentially requiring admin control) or can issues still be viewed without membership?

Issues can still be viewed without team membership.  There's a separate feature for managing visibility (Issue Level Security). So, you could create your teams with just you as a member and still view.  Where it becomes helpful to have accurate team membership is if you want to take advantage of some of the Team features like

• @mention a team
• Getting the most out of the Sprint Capacity Management view with the Plans feature

[Lance Waldrop]

As for "won't show up", this comes back to making sure the Team or Component field is a required field.

To clarify what I mean, I created an Epic using the Create Issue screen in Jira, Team is an available field but within the Epic Issue type itself if you select 'Add Child Issue' it only requires the Subject and no other field. Is there another area to specify the required field? 

[Mark Segall]

Ahh yes... I think you would either need to sacrifice creation of child issues that way or consider a filter/board that shows all issues that are in purgatory.

[Lance Waldrop]

Ahh okay. Well, I'll leave that up to our PMO team, I guess. Thanks for your advice! I took another look at Jira Components too (Compass Components have an extra charge so I initially didn't look further into it), which also was a really good suggestion. 

[Lance Waldrop]

@Mark Segall as an update, we were able to accomplish this utilizing an automation. Once an issue is created any child issues will inherit the Component field. Between this and setting the field as required for ticket creation all the instances we saw where orphaned tickets was created got mitigated.