Jellyfish Releases Industry's First In-App Benchmarking Feature! FIND OUT MORE

Best Practices

Best Practices for Your Jira Workflows

Evan Klein | September 14, 2021

Engineering Operations

Jira Best Practices

Engineering operations are increasingly a focus for modern software development teams and their leaders. Many of these teams are using Jira for issue tracking, but Jira can be quite complex and confusing if you’re using it to manage and improve engineering operations. In this blog series we’re looking at some best practices that teams use to organize their work and optimize their workflows in Jira. Guide your team to adopt these best practices and you’ll be able to significantly improve visibility and reporting, and take steps to optimize your organization’s engineering operations.

In Parts 1 and 2 of this series, we dug into ways that teams successfully organize and structure their projects in Jira. In Part 3, we’ll look at best practices we’ve seen employed for improving Jira workflows.

Best Practice: Balance consistency with autonomy when building workflows across teams

Building out a workflow that works effectively takes some time, but it’s worth the investment. Jira workflows are highly customizable, and this will likely be an iterative process, but don’t settle with a sub-optimal workflow. When you’ve developed a workflow that functions well, think about how much of that you want to standardize across different teams in your organization. A one-size-fits-all approach likely won’t work and could limit efficiency on some teams, but some amount of consistency around workflows can be helpful for driving communication and collaboration across teams, for comparisons and sharing of learnings, for cross-team mobility, and for reporting and analytics to improve processes. 

While we’ll stop short of being prescriptive in exactly how to build and what to include in your workflows, here are some suggestions:

  • Different teams and projects will need to have different statuses, but it may be helpful to guide your team to think about how statuses align to the value stream of their software development process. Simplicity almost always trumps complex and convoluted workflows. Too many statuses and transitions will likely leave you unable to see the forest for the trees.
  • Consider who has permission to transition issues and in what circumstances, especially whether they can revert issues to a previous state.
  • Use the “Assignee” component as you move issues through the workflow. Too often teams will leave this step out, which results in issues sitting unworked for long periods of time, a lack of visibility both during and after the process (who do you turn to with questions about a particular piece of code or decision?), and a lack of accountability on teams.
  • Don’t make Jira workflows more complicated than they need to be by unassigning people when the work is done or passing all Jira tickets through a single person for approval.
  • Ensure that statuses in your workflow are tied to specific resolutions. Jira does not consider work on an issue to be finished until the “Resolution” field has a value. By linking the “Complete” or “Fixed” or “Won’t Fix” status to a corresponding resolution, you will ensure issues will not be accidentally left as active. 
  • For more guidance check out Atlassian’s guide to building an awesome Jira workflow.

Best Practice: Automate your workflows as much as possible

The benefits of automating development processes are well documented by now, and in fact many consider it to be a key to success for modern software engineering organizations. But when it comes to Jira workflows, a process that is so central to software development for many agile teams, most still manage in a relatively manual way. That does not need to be the case. By linking coding and development work done outside of Jira to associated projects, teams can remove a lot of manual, and error-prone process management and create projects that are simpler to manage, easier to collaborate, and cleaner to report from. 

The most obvious, and most important linking should happen between Jira and Git, but linking should also be done for Incident Management (Pagerduty, Splunk On-Call [formerly VictorOps], etc.), Customer Support (Zendesk, Freshdesk, etc.), and other tools common in your development process. By linking coding, bug fix, support, and other work to its related Jira project, each engineer and their teammates will be able to see work done in relation to their projects, which means less context (and platform) switching, greater visibility for other teammates working on the same project, and better communication as issues move through the workflow. Proper linking can also enable automation of issue status changes and assignment to team members (we recommend teams standardize the practice of putting the Jira ticket number in the title of the commit or PR in Git (i.e. ABC-123)).

Linking also ensures that code work is limited to specific Jira issues, avoiding the submission of large blocks of code to tick off multiple issues. Proper hygiene in this sense creates a record of work that is easier to parse and cleaner to report. Automation has the added benefit of maintaining standardization. By removing manual tagging or labeling, automating issues movement through workflows, and assignment, it becomes clear to see how much of each type of work is taking place, and how that breakdown affects your engineering teams. This will help you track Allocation, or the categories of work into which teams are investing time, which will be helpful for operational planning, team and hiring decisions, and more. 

For many software development teams, Jira is essential for tracking issues and projects, which means it is central to engineering operations. In this blog series, we’ve covered some best practices teams can use to streamline a tool so central to their success and ultimately improve engineering operations and drive meaningful impact for the company.

To learn more about how Jellyfish works with Jira to help drive alignment and improve engineering operations, head over to

Evan Klein