What's Hidden in Your Jira Workflow

Too often, I start on a project where the team uses a default workflow template from Jira. Every time, I see it as a missed opportunity to understand and improve the delivery.

Here are a few thoughts about why workflows in Jira (or similar backlog management tools) should not be neglected.

In Jira, each issue type (user story, bug, task, epic, etc.) may have a unique workflow. But I don’t want to bore you with Jira admin mumbo jumbo about different issue types and schemes (that’s another story for another day or just RTFM). I also do not want to touch on the workflows in Jira Service Management - it is a different beast, though it uses the same workflow engine. Let’s talk about workflows for stories, the most commonly used backlog item.

In short, a workflow is a collection of different statuses/steps through which your story travels from creation to “Done”. You define the workflow by thinking about your process and mapping the main delivery activities and transitions between them. Understanding all the steps your team needs to take is useful per se - it adds some clarity and helps define working agreements for the team. Nevertheless, other dimensions are hidden behind the simple sequence of workflow steps.

Data Points

Each transition from one status to another creates a data point you can analyse and track.

Ultimately, metrics and data are among the reasons we use Jira, it is not just for moving cards on the board.

You may derive a lot from this data, but only if it reflects the actual picture of how your team delivers. If your workflow is not good, you generate wrong data with every status change. Well, maybe it's not entirely wrong data, but it needs to be more reliable. That means you will be missing opportunities for tracking useful metrics (think of lead time and cycle time, for instance) and enabling better transparency for your team and stakeholders.

The quality of data about your delivery is extremely important. If you do not generate reliable, meaningful data, you will be flying blind with your estimations and planning. You won’t be able to make any decisions based on this information; you will need to find a substitute or live with something too generalised (velocity?).

Team Dynamics and Relationships

To some extent, every workflow is a compromise. You may have all sorts of characters and roles on your team, and they must agree on how they work together. This is usually reflected in a workflow; the best result is when the team owns and follows the process. Achieving this state may take time and require a balance and application of common sense. An over-complicated workflow usually produces frustrations, while a simple workflow (To Do - In Progress - Done) hides problems and data points.

This impacts the team’s dynamics and collaboration and affects your interaction with other teams. Sounds important, right? So why not think about the workflow that reflects the way you work?

Project Context

The workflow does not live alone. It is bundled with other working agreements, such as using XP practices (pairing, automation, etc.), risk management, definition of ready and definition of done, etc. Good workflow supports the agreements without complicating them. If it is too general - it might require a lot of additional agreements.

Do not misunderstand me - the simple three-step workflow might work well for your team. It usually suits small teams with high-bandwidth daily communications on a short project. In such cases, there is no need to collect additional data; you focus on ensuring things are being done, that’s all. But imagine you are in a more sophisticated setup, with multiple NFRs, funny governance and many teams working together from the same backlog. In that case, you can better understand your process by introducing a workflow that reflects how your delivery organisation works.

Smart Transitions for Better Data Quality

Some PM tools, such as Jira, allow changing information automatically during the transition between workflow statuses. When you change the status of a backlog item, the tool will execute some rules associated with the transition. It may set or clear some values, prompt you to add a comment or provide approval.

This behind-the-scenes magic may save time and visibly improve data quality in your backlog, thus making it more reliable and metrics-friendly.

Well, it may also complicate everything if you use it without thinking… so do it in moderation.

Workflow is Not Your Kanban Board

Well, at least in Jira. Boards are based on Jira filters, i.e. on a selection of tickets. You may have multiple boards in your project, and the workflow may span several boards. Again, you may only need one board on your project, but usually, it is not a problem to build a board per team. Do not be afraid to have multiple boards, but it would be good for the project if each board had an owner - at least, it will be maintained.

Another consideration is that in Jira all internal reports are board-based. So, sometimes, you may need a separate board for reporting only, which might not be convenient for your teams to use in their daily work… Looks like I need to write another post about boards.

There is More to Think About

The workflow is really a simple thing - when your project is small and isolated. Things can get complicated when you need to analyse data on a multi-project, long-running programme. But the last thing I can recommend is to build a unified one-size-fits-all workflow. Instead, think about introducing Jira hygiene on your programme, which means some agreements between teams around what issue types and statuses to use, how to use the Resolution field, etc. All this helps to produce reliable data for analysis and metrics.

Atlassian Jira documentation about workflows might be slightly confusing, especially now that we have company-managed and team-managed projects. Anyway, I would recommend reading this article and a more formal documentation entry.

Have some thoughts about workflows? Let's have a chat.