It’s really easy to get lost in a sea of boards and tickets; here is one approach for structuring the breakdown of your work from top to bottom in Jira.
This problem isn’t unique to Jira
Actually, this could just as easily be about structuring work on a white-board with post-it notes; except for the fact that time after time I encounter organisations using Jira as their work visualisation tool of choice. While there are some tips and hints to using Jira effectively, the core of this article is really about choosing how you want to represent the work you are doing as a team and wider organisation; the trap you are trying to avoid is having boards and boards full of post-it notes or Jira tickets and no sense of how it all fits together.
Jira has some … quirks
There are two exceptions that separate Jira from a plain old whiteboard or any other tools you might have used in the past:
Every work item in Jira is described as an issue. This reflects its origins as a bug tracking tool. Don't worry about this - it's just a thing.
Epics are a special concept. Far from being a loose shorthand for a really big user story, they are imbued with special characteristics; for example, you get the option of grouping your issues into swimlanes by their related epic. Atlassian defines epic like this:
An epic is a large body of work that can be broken down into a number of smaller stories.
In the Atlassian Agile Coaching site they add more clarification on how they see the epic in Jira:
The idea is to break work down into shippable pieces, so that large projects can actually get done and you can continue to ship value to your customers on a regular basis.
Making an information hierarchy
Here is a JIRA strategy for representing your work from top to bottom; things at the bottom contribute to the things above them:
Tasks (more specifically, sub-tasks, in Jira)
Let’s define these in more detail, with examples for each.
OKR stands for objectives and key results. It's a tool for setting strategic objectives with a structure for measuring progress against them. For example, an objective could be Reduce customer complaints and a key result could be 50% reduction in complaint calls compared to last year.
An idea or a change to how the business works (internally or externally). Initiatives should come with a potential cost of delay, assumptions, constraints, and any key dates. Initiatives should contribute to the key results described in a related OKR.
For example: Make customer support accessible over in-app chat so we don't force people to waste time phoning up and queuing. This could link to an OKR about reducing the cost of running customer support or one about improving customer NPS.
A unit of customer (or organisational) value that we could release to customers and users. If you think about epics like MVPs you won't be far off. An epic should define the what, why, when and who of something concrete that the user, customer or collegaue would recognise and see value in.
For example: Basic chat support for colleagues who are customers, iPhone chat support, Chat support with integrated video chat.
Stories are a short narrative about something or someone interacting with what we are building. The narrative is written from the outside-in; in other words, we step outside our product and describe how it will work from the perspective of our users or customers.
An epic represents a related set of smaller stories that come together to make a viable and usable solution. If you want to learn more about how to get from a big idea (e.g. an initiative) to a backlog of stories and epics then I'd encourage you to explore Jeff Patton’s story mapping technique.
N.B. It’s important to remember that stories are not requirements in the traditional sense of IT projects; instead, they are an aide-mémoire for collaborative work and a handy place to make notes; a place holder we can use to prioritise our cooperative and collaborative delivery activities. For more on this, read about the 3 C’s (Card, Conversation and Confirmation) - a technique that goes back to the early days of agile software development.
For example: Start Chat - When the customer has a problem they can send a help message that gets them into a queue for the next agent.
Please do not feel like you have to write stories in a template like As a... I... so that... You can if you like, of course, but don’t feel that is the only way to write a story.
Tasks (more specifically, Sub-Tasks)
Jira really confuses people by having both a Task and a Sub-Task issue type. Let me attempt to clear that up. Jira is endlessly flexible and Atlassian probably wanted to cater to teams and organisations where not everything could be described as a story. Tasks are an alternative to stories in Jira. Let's ignore them now for the rest of this article.
Sub-tasks are what we would commonly think of as tasks if we were using the Plain Old Whiteboard approach... the things we have to do so that we can complete a story. Usually these will be technical (e.g. coding) things but they could describe preparation for testing or even individual tests we need to pass to show that the story is working as we expect. In Jira you might even create different variants of sub-tasks for tests, bugs etc. It’s really up up to you. The key thing is that they belong to the stories.