Jira is a software development tool designed to be used by agile teams. This means that the makers of Jira are taking their understanding of what it means to be an agile software development team, and what it means to work in an agile manner, and they are providing a tool for that. Where a team is at in its understanding of agility will play a major role in its experience with Jira.
It is very common for a developing agile team to start with Jira before the basics of agility, and working in an agile manner, are second nature. It’s common to see teams using Queues for Projects, Epics for Labels, Boards as Versions, Sprints as basic lists, almost as if someone bought the most complicated thing from Ikea, threw out the instructions and half of the tools, put the thing “together,” and then used it as a bed for a year .
Jira is incredibly flexible, people are very smart, and they can make it work in all sorts of ways, but without some basics and guidance, it is all too common for a team to self-organize into workflows that, while the tasks get done, just don’t feel right. Even though things are technically working, the team is at risk of death by a thousand papercuts, or worse, at risk of acceptance. A team that is breaking down is easier to fix than one that has found a way to accept that the work and workflow just kinda sucks, getting it done is just hard, and everyone on the team is bonded as one another’s coping mechanism. In this state, team members are more likely to consider a job change than a change to their workflows. You might be thinking I’m talking about your team, you might be right.
Here are some basics of Jira and some rationale for why they fit with agility.
Epics are your biggest stories
In Jira, Projects hold issues that all relate to a common goal. Issues can be categorized and tagged with labels for grouping and filtering. Two of the issue types are Epics and Stories. In Agile methodologies, these are intended to be the start of discussions rather than specification. Meaning, “this is what we want to be the case” let’s talk about it and not, “here is how it needs to be done,” do it. It’s important not to say too soon how we want something done because we might learn along the way that it would be better done a different way, or not at all.
For Epics, your biggest stories, the discussion is meant to break the Epic down into smaller Stories that can be discussed by the team that will work on them, when they will work on them. It is at that point that the team can create Subtasks to cover how the story will be completed. At the moment they are created, these subtasks make up the “how to do” the story that the team thinks is the right way given their awareness of the project at that time. Not everything needs to be a Story, some things are just straight Tasks that are understood and do not need conversation to get done.
Learn more about Epics, Stories, Tasks, Subtasks… what’s the difference ->
See also Distilling conversations into ready stories… with Confluence and Jira ->
In Jira, Stories, their Subtasks, and Tasks get worked on in Boards because they are understood, can be committed to, and are actionable. Epics, in most cases, do not belong on Boards.
Boards are for teams to Iterate or Flow
Whether a team is responsible for part of a project, a whole project, or multiple projects, it can use a Jira Board as a workflow for completing issues. Boards are configured using Jira Query Language filtering to show the team the issues it is looking to pull to work on. Whether it should choose a Scrum Board (for Iteration) or a Kanban board (for Flow) largely depends on the task size and the project’s goals at that time.
Learn about Using Boards for Iteration or Flow and knowing the difference ->
A Scrum Board may unnecessarily be forcing your team’s work into batches. A Kanban board may not be providing the structure needed to produce the most valuable iteration. Be sure to consider the workflow and the goals of the work when choosing a Board type, but don’t be afraid to experiment, as long as you meet regularly in retrospect with the goal of continuously improving.
Making it work, in Jira
If you can start out this way, that’s great! It is much more likely that your Jira is out of whack and you want to get it in order. Rather than just rearranging everything after hours and having the tool continue to drive your team, look for opportunities to improve the team’s understanding (ideally with some real-time agile coaching) of the basics of agility, and working in an agile manner, to drive their own changes. With that understanding, plus an awareness of how things are intended by Jira versus currently being used, improvements can happen very quickly and stick around.
Maintaining a sustainable pace
Once your team finds its groove, the Service Desk method helps the development team keep a sustainable pace by not overwhelming them with too many unplanned requests, but also improving the quality of the requests that do make it to their backlog. This let’s the development team stay focused on their work as their priority while their customer’s needs and feedback stay close by. This method also lets the customer be a priority in their relationship with the Service Desk agents skilled at solving the common scenarios and escalating the complex requests while setting good expectations.
Learn more about keeping a sustainable pace while Getting closer to your customer… with Jira Service Desk ->
