Don't change your team to fit Jira, customise Jira to fit your team

[#1]

The recent 'reimagining' of 'work' in Jira, you know the one where issues are now known as work items, got me to thinking about how we actually refer to work.

This mostly came about after a recent stand up where one of the team mentioned that he had been working on a side-quest, so as a joke I created a new issue type 'Side Quest' as a direct copy of the Task issue type.  Later on the team was talking about a D&D session that they were going to do as a group at the weekend and how much they had liked being able to do side quests on the scrum board so could I please add in a Quest type as well.

The end result was that team having work item names relating to their hobby:

• Adventure (Initiative)
• Quest (Epic)
• Challenge (story) | Side Quest (task) | Wandering Monster (bug)
• Dice Roll (sub-task)

This works within our overall work item hierarchy:

1. Theme
2. Initiative
3. Epic
4. Story | Task | Bug
5. Sub-Task

However the names of the levels in the hierarchy are defined in one place and we can't set up separate schemas for different projects to actually allow us to group by Quests for example rather than Epics, but that is a topic for another time.

Having customised one team as a joke, other teams asked how we could make Jira work items more relevant to them, for example, our marketing team deals with marketing campaigns and events, and has portfolios of work so how could we fit that into a hierarchical structure?

Well we defined that as marketing campaign being a tactical tool, while a portfolio is a strategic demonstration of your abilities.  We then agreed that strategic is higher in the hierarchy than tactical.  

This gave us a hierarchy we could start with:

• Theme
• Portfolio
• Campaign | Event
• Story | Task | Bug
• Sub-Task

The marketing team then looked at the other levels in the hierarchy and decided they didn't need Story or Bug, but Task still worked for them.  They then decided to add a couple of new activities alongside Task - Article and Email, Letter & Notification.  They also didn't like Sub-Task, but Task Breakdown was acceptable, so we created new work item types and their hierarchy was now:

• Portfolio
• Campaign | Event
• Task |  Article |  Email, Letter & Notification (ELN or Ellen)
• Task Breakdown

Yes, they had also decided they didn't need Theme, but if they ever want it we can just add the Theme work item type to their project to expand the hierarchy upwards.

It's nice in meetings to hear them say they'll create an Ellen to track that.

We've still got a few placers like boards and plans where we see Epic, Stories or other names from the hierarchy but generally the Marketing team ignores those.

For other teams we've also created other specific work items e.g. Ad-Hoc Request (to handle unplanned but urgent tasks), Knowledge Transfer (KT) (for knowledge transfer specific activities), and Sprint Goal (used instead of the built in sprint goal, this includes fields like key achievements and challenges so that the team can create dashboards and reports over time).

The point I want to make out of my ramblings is that maybe Atlassian 'reimagining' work is an opportunity to think about how you can modify Jira to use terms that are relevant to the people doing the work rather than insisting that all your teams call their work by the same names, after all what does Epic or Story mean to a Marketing Team, or a Legal Team?

And hopefully Atlassian will take this further and allow us to use terms other than Epic on our boards. plans and hierarchies.

---

TLDR; You don't have change your team to fit Jira, customise Jira to fit your team

[Bill Sheboy]

Hi @Stephen_Lugton 

Yes, and...

I find it helpful to remember Jira is just another tool, and sometimes helps a team while other times not so much.  My go-to guidance for teams is always: "there are no best practices; only better or worse ones for the team and context supported."  So, turn-up-the-good and resolve / mitigate the bad when the tool cannot help as desired.  Even when that means not using a tool or its "recommended" features as specified :^)

For the approach your teams are taking, how are you documenting that to help align with other admins and onboard new team members?  Perhaps a summary / decoder ring on a Confluence page to explain the why, what, and how to others for the work item hierarchy?

Kind regards,
Bill

[Stephen_Lugton]

@Bill Sheboy , we have an Agile Information space in Confluence with a section for Jira / JSM settings which gets updated over time.  This is also mirrored into the appropriate team spaces using excerpts / labels. 

In addition, since Jira is a Production environment, we have a CAB Change Type for changes to Jira settings, with filters for teams that list implemented CAB requests on the Confluence pages, and we also link CAB tickets to Assets where we track all Apps and services that we use. 

[James Rickards _SN_]

I love this. You take this to next level (see what I did there) by dropping the Jira OOTB Scrum and Kanban boards and instead using Jira Whiteboards then adding add some D&D imagery to further highlight the theme.

Whiteboards are a bit of a pain loading new cards onto the board every day, but it can be a useful trigger to properly triage them.  The benefit for having the DOD for column visible, as well as putting goals/risks/issues all on the same board, laid out as you would on a physical wall is a game changer to using Jira.