This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams.
Reduce Repetitive Work by Employing a Smart Workflow
I am a fan of automatization. Because I am lazy. That is a good thing, because the human brain should not be used for doing the same thing over and over. At least mine should not. That is why I use a solution to automatically add acceptance criteria and definition of done to stories. For that, usually, people use a variety of approaches, like copying them into the description, printing them out, discussing them in meetings, or even adding them again and again as subtasks.
Well, there are better, automated solutions—with Jira.
Let’s first talk about what the “acceptance criteria” and “definition of done” are. Technically, they are not needed. Just write down all the steps of a story, including testing, documenting, deploying, product owner approval, code quality, etc., as subtasks. Done!
Now, that is an impossibly laborious task for anyone involved, but we need to make sure that all the points are accepted by the product owner. What to do? We could rely on the team to memorize at least the most common steps. After all, we do not include specific programming steps in the subtasks. But in contrast to acceptance criteria and definition of done, code is self-explanatory and all the steps of the actual work are already recorded in your versioning system. Part of the definition of done can be enforced by the continuous integration system. Every commit could be automatically checked for unit tests or code quality in general (e.g., using the tool Checkstyle). While I encourage this very strongly, it will not cover everything…what to do with the acceptance criteria and definition of done?
Let us define our concepts. In Scrum practice, we have basically four kinds of tasks the team can work on:
BUG REPORTS · Bug reports are added by anyone testing a released version of the product. They refer to either previous incomplete or erroneously implemented stories or to legacy code not developed with Scrum (or errors resulting from using third-party libraries). For the former, we refer back to the original story; for the latter, we might have to write a new story describing the expected behavior that the new bug contradicts.
ACCEPTANCE CRITERIA · The acceptance criteria are a story-specific set of conditions that need to be met in order for the story to be accepted and checked off by the product owner. A better expression for acceptance criteria is actually “business-facing tests.”
SUBTASKS · Subtasks are specific and usually unique pieces of work related to a specific new feature. If we find that, over the course of many stories, certain types of subtasks repeat, we can elevate them to “definition of done”—like “updated documentation” or “added unit tests.”
DEFINITION OF DONE · The definition of done is a story-independent list of general tasks that apply to all stories to ensure proper quality assurance, documentation, testing, and so on. This list can grow over time.
How do we implement these in Jira? Implementing subtasks and bug reports should be obvious. For story acceptance criteria, they go into the description of the corresponding story (see more below). But the definition of done is usually made available to the team as a regularly updated document at some other place. So, how can we merge this definition of done document into Jira?
First, some organization is required. Even if we find a way to add the definition of done automatically, the list is typically in bad shape and requires additional thinking by the team when implementing stories. For example, maybe it is a story with business value but it does not need any programming. Think of editing a page in a content management system like WordPress: asking for unit tests might cause some bewildered looks. Hence, we need categories. And with epics, we have already created such categories. We might just have to double-check and cross-reference with our definition of done. For example, a publishing company might require that all WordPress articles show a featured image. We have an epic called “WordPress article” and for each epic like this, we add that definition of done element to newly created articles.
How do we do that in practice?
We look at the easy part. Instead of adding subtasks for each definition of done item to a story, we add them to the story as checkboxes. For this, we need a plugin. There are two options, depending on whether you run your Jira in the cloud (yourjiraname.atlassian.net) or on your own server.
ISSUE CHECKLIST FOR JIRA · The Issue Checklist for Jira add-on allows users to add simple ToDo list items to an issue and watch the progress when items from the list are completed. It is only available on the Atlassian Marketplace for a Jira Cloud installation [che, 2017]—check sim [2017] for a similar plugin for a Jira Server installation.
This way, the programmer can easily mark which parts of the definition of done are already done, and the product owner can track the progress as well. In addition, we can add the acceptance criteria to the list. All nicely integrated into the workflow with templates! This even makes the description box mostly superfluous; remember that the story itself goes into the summary line!
In case you need more control of the story creation process (like adding special instructions to the description), you need to change the workflow yourself. This is a little bit of hacking as we need to add a separate transition for each type of story. Any global instructions can be added to the initial “Create” transition of your workflow. Those will be added to all new stories. If your instructions differ only from project to project, not from epic to epic, you can create individual transitions for each project. If you use the epic-based approach, mentioned before, you will need to add another state. Let’s call it “Ready,” meaning that the definition of ready is fulfilled (all the acceptance criteria and definition of done are entered and the story is formally correct).
DEFINITION OF READY · The definition of ready is an agreement between the team and the stakeholders (represented by the product owner) that new stories have to conform to a certain standard before they are added to a sprint. It is up to the product owner to make sure that the team has sufficient information to know what the individual story is about and when it is accepted (acceptance criteria, definition of done). Obviously, the Scrum Master can help to clean up the stories so that they also conform in terms of visual and grammatical formatting.
From the initial “Open” status, create one new transition for each group of epics, with individual “Update Description Field” commands. You can even combine the global instructions from the “Create” transition with the later “Ready” transition. Another option is to directly fill out the epic field by the transition, with a lot of buttons in your initial detail view of the issue.
Whether you use the plugin’s features or the manual workflow approach (or both), a big plus of this approach is that you can centrally control the instructions you want to add to stories. All new stories of all your teams will automatically contain the current set of instructions. You won’t need to waste lengthy meetings to update every single user of your Jira system to include a proper list, nor will you have to spend endless hours fixing invalid entries.
