Jira is a great tool for tracking tasks. And Scrum is a great way of getting things done. Given this, software developers make abundant use of both – so you might not be too surprised to learn that Jira is a fantastic platform for running the Scrum methodology. Perhaps most importantly, Jira offers a huge range of options for customization. That means that you can use a default Jira Scrum workflow, but you can also build something that’s a perfect fit for your precise working needs, whatever they are.
In this guide we’ll explore everything you need to know about building the best Jira Scrum workflow for your organization – whether that’s optimizing for software development, customizing for your requirements, or implementing a simplified Jira workflow for Scrum that cuts out the extra steps.
Basics and Broad Principles of Building a Jira Workflow for Scrum
The best Jira Scrum workflow will enable you to smoothly move through the Scrum process as you’re using it – opening, tracking, and closing tasks as you need.
You’ll also want to build on Scrum’s core values, of course: helping the team learn from experience, self-organizing around challenges and delivering work that meets stakeholders’ needs and requirements. Then there’s Scrum’s most fundamental principle: not just pushing projects forward, but getting more capable and efficient as you do so.
So what are the key elements of Scrum to consider when it comes to a workflow?
– The Sprint – in Scrum, everything revolves around the Sprint. This is a fixed and agreed calendar window (typically lasting two weeks to a month), with its own agreed goals and targets.
– The Sprint planning meeting – this event kicks off the Sprint. The full team gathers to agree on the Sprint goal and to assess the specific tasks to be completed to meet that target.
– Daily Standup meetings – this is a daily meeting for the full team to identify completed tasks, upcoming work, and potential problems, in a broad overview – to be followed by breakout sessions if more discussion is needed.
– Sprint Review – the team reviews what tasks have and haven’t been completed, presents this work to stakeholders and establishes what to tackle next. For developers, this might mean demonstrating software that has been tested and documented and is ready for release.
– Sprint Retrospective – following the Review, the team gathers to reflect on the Sprint and to identify lessons and opportunities for process improvement.
– Backlog grooming– this is an ongoing process of ensuring that the backlog is prioritized correctly. This is constantly reviewed by the product owner and is presented to the team during the Sprint planning meeting.
The optimum Jira Scrum workflow will hence make it easy to push issues through the Sprint, with all the approval stages that you need.
Covering the Default Jira Workflow for Scrum
The Jira default workflow for Scrum software development will, in fact, do a lot of what you need – and for many teams, there won’t be any need to make changes.
One alternative, though, is to use the Jira simplified Scrum workflow. If you have fairly basic requirements and would like to reduce friction wherever possible, then simplified workflows may actually be ideal for you.
Issues move from “To Do” to “In Progress” to “Done”. At the same time, issues can be dragged and dropped on boards, with columns covering “Backlog”, “Selected for Development”, “In Progress” and “Done”.
In short, it’s a fast and easy way to track tasks – but it also cuts out a lot of the finer control that teams may need when working at scale. Indeed, many working groups will want more granular details on task progress that can only be achieved by adding to the default workflow.
The Scrum workflows supported by Jira Software
So, what are the steps that you might want to add to or remove from a default Jira Scrum workflow?
One example is that you might need issues to be approved before they’re closed or for conditions to be met, such as passing code review. Equally, you might want to customize how the backlog fits into the workflow.
Many teams add the statuses “Awaiting QA” and “Ready To Merge” to run after Code Review, as additional approval stages.
The Step-by-Step Process of Creating a Jira Scrum Workflow
If you want to fully customize your workflow according to your needs, then Jira allows you to start from scratch. You’ll only need to have Jira Administrator permissions to do this.
The first step is to head for the Jira workflow designer, which allows you to edit the workflow layout and how statuses and transitions fit together.
You can then start laying out the stages of the workflow and how they connect, using the following building blocks:
– Status – such as “In Progress” or “Under Review”
– Transitions – the lines connecting Status items
– Resolution – how issues are ultimately resolved
There are also points to consider such as:
– Conditions – limiting which roles can progress issues to the next stage
– Validators – blocking transitions – and superseding conditions – unless necessary information is supplied
– Post Functions – coupling additional changes to transitions
– Triggers – automating transitions when set conditions are met
– Workflow properties – setting properties for transitions (such as only displaying relevant resolutions for the issue type)
– Workflow schemes – establishing the connection between the workflow and the issue types
An alternative to starting from nothing is, of course, to customize an existing template – perhaps adding new status items and transitions to cover extra steps where needed.
There are drawbacks to customization though. The most important is probably that you’ll need to review how the changes affect plugins and integrations and the instance on a broader scale – which will have a major impact on getting work done.
We’ve previously created a complete guide to workflow customization, which you can find here. That piece tackles the fundamentals of building a new workflow as well as the questions you should ask yourself before starting. It also offers recommendations for some tools and plugins that may come in handy.
Sprint Planning, Sprint Reviews, and Sprint Retrospectives
While these are crucial stages of the Scrum process, they shouldn’t be reflected as statuses in your workflow. They are meetings where you’ll spend a lot of time handling issues, however, it’s worth thinking about how the issues themselves are presented to facilitate these events.
In your Sprint Planning meeting, you’ll be defining and creating tasks, bugs, stories, and epics. You’ll also be reviewing the product backlog, prioritizing tasks and creating time estimates, or allocating story points in order to establish the overall workload.
Then, in your Sprint Review, you’ll be taking a look at the work that has been completed and the status of your remaining tasks. This will indicate bottlenecks in the process – for example, if QC is holding things up.
You can also review how many issues have to be rolled back following Code Review and QA assessment for additional work to be completed. Additionally, you can establish how long it’s taking to complete tasks on average – if it’s taking too long, then they may need to be broken down into smaller elements.
The key things here are for statuses to clearly indicate where issues sit in the workflow; and to have accessible, visual indicators illustrating where issues sit in the system.
There are two reports that are particularly useful for tracking Sprint progress and contributing to the Sprint Review.
The Burndown Chart shows the estimated and actual amount of work remaining in the Sprint.
The report is updated automatically and shows your team’s progress through the Sprint. The chart makes it easy to review targets (for example, if there’s too much work or not enough), to see where work is being added, and to address whether work is being broken into suitable units or whether there are big jumps on the chart.
The Sprint Report, as suggested by its name, is another great tool for managing Scrum.
As well as containing the Burndown Chart, it includes a summary of the open and closed issues on the sprint as well as tasks that have been added.
Both of these tools will also be extremely useful for the Sprint Retrospective. This meeting goes one step further than the Sprint Review. It calls for the team to consider what went well and what didn’t, and to look not just at what has happened but to determine why and how things can be improved.
This can flag issues as too much work being loaded onto the sprint, work being rushed and causing problems and priorities changing, meaning that the team gets sidetracked.
All of these issues should be flagged by the workflow. If there is a large number of open issues, if issues are frequently getting reopened, or if numerous issues get added during the course of the sprint, then the team might be set up to fail.
Example Workflows for Scrum
Here we’ll present a few examples of Agile Jira Scrum workflows, illustrating the pros and cons of different models.
This is Jira’s default workflow, which allows you to smoothly slide issues from creation to closure. That said, a full Jira Scrum workflow may need several layers of approval, which would need to be handled by sub-tasks here.
This workflow is provided with the Easy Agile Scrum Workflow for Jira plugin and adds a “Ready for QA” status to the standard workflow while simplifying the resolution stage to one status.
This is a development workflow gone haywire. There’s far more detail than is needed, resulting in a hugely complex system – which will be a challenge to integrate with workflows used by anyone else, whether inside your organization or not.
Optimizing your Workflow in Jira and Overcoming Challenges
When moving issues through a Scrum workflow, it’ll be tempting to create statuses for every step of the journey – but the best advice is to keep things simple. Your workflow should make it easy to establish:
- What tasks have been finished and what’s remaining in the sprint
- Whether issues often require further work after being completed
- How long it takes to clear tasks
- And how the team is working down the sprint and product backlogs
If your workflow is a blocker to answering these questions, then you probably need to change it.
While Scrum is intended for teams of seven or less, there is some potential to scale the Scrum workflow itself, which should be fluid enough that adding more people won’t lead to a breakdown.
A more common scenario is that parallel teams, with their own projects, need to collaborate. In cases like these, having a shared set of standards – and limiting customization – is important in order to get things done.
Apps
There are a number of apps that can assist with building a Scrum workflow in Jira.
Easy Agile Scrum Workflow for Jira
This app provides a powerful and easy-to-use Scrum workflow, that makes it simple to find, track, and manipulate issues and to work from sprint to sprint. You can find it in the Atlassian Marketplace here.
Dual-Track Scrum Jira Workflow
This plugin powers a version of Scrum that sees the workload being split between discovery and delivery – having one team establishing what stakeholders want, while the other works to build the product. You can find it in the Atlassian Marketplace here.
Scrum Standup for Jira
This app makes it extremely easy to share a Scrum standup report, which is ideal when it comes to working with a remote team. It’s easy to link the report to issues; and the reports are persistent, providing a record of what has been discussed and agreed. You can find it here.
Conclusion
Jira and Scrum go together like summer and holidays – and with a few tweaks, you can ensure that your workflow is perfect for your needs. Of course, there’s plenty more to do.
For example, you can customize your dashboard to make your sprint performance visible at a glance. Meanwhile, if you’re interested in customizing workflows for specific requirements, then you might want to check out this guide for building workflows geared towards bug tracking.
And whatever customization you have in mind with Jira, the chances are good that you can implement it with minimal fuss.
Have we missed anything out or do you have any tips of your own on how to handle Scrum in Jira? Let us know in the comments below.
Recommended Reads: