One of the big questions you may have as you’re organizing a new scrum team is, “How do we use JIRA?” and in particular, “how do we organize the JIRA board?”. Well, let me use the standard answer a consultant would chime in with here: it depends.
Unfortunately, one of the popular misconceptions that I’ve observed in many companies, is that there is only one ideologically correct approach that must be used by every single team in the company. In some cases, it is due to managers not willing to spend time understanding every team’s board, so they mandate a unified format; other times it is an issue with the JIRA support team, who intentionally limits JIRA functionality, blocking all the projects to a single workflow with a defined set of issue types and single structure of the board columns/statuses; sometimes it may be the agile coach or a Scrum master who dictate their preferred way of utilizing the tool. Whatever the reason is, JIRA is the tool – and as any tool, its main purpose is to serve the team and help increase the team’s performance. And if it doesn’t – you may be doing something wrong.
The two proven approaches.
There are two main approaches to organizing your JIRA board, as I usually coach my teams. One of them is to make use of sub-tasks for user stories. This way, every user story has a distinct sub-set of steps, in other words, a to-do list that the team has to follow in order to get the story to the Done state. It looks a little something like this:
As we follow this approach, a User Story would normally become a swim lane – a container for all of its’ sub-tasks. In this fashion, we end up moving the sub-tasks, not User Stories, through the board. And seeing as how sub-tasks represent all the activities needed to complete the story – such as development tasks, testing, automation, test data gathering, deployments, PO’s acceptance, etc. (based on individual team’s DoD and Acceptance Criteria) – usually all we need is three columns: To do – In progress – Done, as shown in the picture blow.
As we can see, stories are displayed as headers and contain all the sub-tasks that can be assigned to an appropriate column.
Obviously, this approach has its’ pros and cons.
Among pros is that this way team is forced to think through the steps at backlog refinement and sprint planning ceremonies as they identify the sub-tasks. It also helps new teams to align on who will be doing what and adhere to their Definition of Done and make sure all the steps of it are followed. If team chooses to utilize time estimates for their planning, sub-tasks approach also helps with having the level of details needed for estimates.
Now let’s think of the cons. This approach is heavy and requires investments of time to get the sub-tasks analyzed and outlined. Depending on the project and team maturity, it may take too much time off the planning sessions, that could’ve been utilized in a more productive manner.
It’s also that not all the teams are particularly good at following the process of creating and updating subtasks either. This puts additional duty at a Scrum Master to keep an eye on the sub-tasks, making sure team members are moving the sub-tasks as work is progressing.
Another big issue with this approach is that if teams have more than 6 user stories in the sprint, the sprint board becomes not necessarily informative and is too big to use during the daily stand up. The overall sprint picture can still be understood, but it will require reading through the sub-tasks, to see where the story actually is. At 80% screen zoom your JIRA looks like this:
One screen barely fits 3 stories with corresponding sub-tasks in, so that you better get ready to be scrolling or using chevrons to show/hide subtasks.
The second common way of organizing your board is to organize around User Stories. A common Definition of Done would include such steps as design, implementation, testing, acceptance, etc. In the first example, all these activities were represented by sub-tasks. However, these steps are not often adjusted over time and are applicable to all the stories that the team is working on. This way, we could drop creating sub-tasks and assign the steps to the columns in JIRA board, moving stories to completion through every column.
This way the board becomes less cumbersome, providing the overall sprint progress picture at a glance (figure 4).
This way it can be effectively used during the team sync up meetings as well as easier understood by stakeholders and executives. Focusing on user stories enables the team to easily identify bottlenecks and re-allocate people to help delivering stories that are putting sprint goal in danger. In order to do it more effectively, teams might also choose to impose WIP limits to certain columns / phases.
This way is also much less time-consuming, as no additional work needs to be done in JIRA to add a story to sprint backlog and start the work.
It also enables the pull vs. push approach to organizing the workflow, which leads to better distribution of effort and more predictable delivery.
However, building JIRA board around user stories requires a higher level of team maturity. Team members should be following Definition of Done and hold each other accountable, as it would be impossible to see it on the board if unit tests were created or if documentation has been published.
Team members should have an agreement on what activities must be completed to move story from one column to another, and make sure other team members are following it. This way Scrum Master is no longer playing a JIRA board police role, but to focus on coaching teams to self-organize.
Voice from the field: enabling teams to design their own board.
So how do we go about organizing our JIRA board? Let’s take an actual example of how we did it with one of my recent teams.
I was lucky to be coaching the team from day 1. The team was new and team members never worked together before. Many of the team members were new to Scrum, and haven’t been using Agile tools before.
As part of the initiation phase, we’ve conducted a number of activities, including the formulation of Definition of Done. After about half an hour of active work our DoD looked something like this:
As a Scrum Master I had the following goals:
- Get the team to quickly understand the new “agile” workflow
- Align team on definition of done
- Help team to coordinate activities, as well as understand who can do what
- Make sure that team follows Definition of Done
In order to achieve these goals, I made a decision to kick-start the first sprint using the first approach to organizing the board: make use of sub-tasks.
As we were going through refinement and planning sessions, we had in-depth conversations on how user stories should be delivered and what particular steps should be taken into consideration. All these steps were then converted into sub-tasks. We have avoided putting lengthy descriptions for each and every sub-task, as it would be a waste once story is delivered, however we made sure that sub-tasks are self-descriptive.
The goal of sprint 1 was to only try the water, and not to jump into the current right away. Given the level of uncertainty associated with any new project, we decided to keep the number of user stories small, as we’ve been expecting to discover many things that we couldn’t think of as we start working on delivery. The team decided to commit to only 6 stories in the sprint, which was not too much for us to make use of the board for our daily stand ups.
All the stories had their corresponding tasks outlined and the board started working. We had discussions around who could pick which tasks on daily basis, the progress under each story was clearly demonstrated by the sub-tasks movement, teams were getting used to the flow and stories were not getting closed if any of the sub-tasks was open.
As team was getting familiar with the new way of working, the happiness level was high, and team members were excited to be trying new things.
However, sprint after sprint the velocity of the team was growing, as well as the number of the stories in each sprint backlog. By the sprint 4 the board contained about 15 stories, each of which contained at least 6 sub-tasks (we have shortened the number of sub-tasks per story since sprint 1 as team better aligned on Definition of Done). This was already too much to effectively use the board on stand ups. Even with filters by team member applied, I’d still have to scroll the board back and forth as we were discussing progress. By that time a few members of the team approached me, saying that it becomes difficult to find things on the board, and technology lead also said that it’s difficult for him to track the progress.
As team didn’t need the training wheels anymore, I agreed that it was time to make the move. During the next retrospective, I have presented the team with the second option for organizing their board, and they unilaterally voted for it.
I’ve been granted administrator rights to the project before, but I was unpleasantly surprised when I found out that the JIRA support team in the bank has limited functionality to only one predefined workflow. It had only following statuses: To do, ready, reopened, in progress, blocked, done, resolved. Where “Done” and “Resolved” were essentially the same thing, and the only “in progress” statuses were “in progress” itself and “blocked”. This meant I could create additional columns in JIRA board, but I could not assign statuses for it. Which ultimately meant I could not create additional columns.
After a few emails back and forth with the JIRA support team, I’ve been told that this is the unified workflow used for all the teams in the bank, and if it fits everyone else, it should fit our project as well. My request for enabling the “simplified workflow” feature was politely declined.
This left us with the only option: move stories through basic To Do – In progress – Done, which would not even provide a basic understanding if story is in development, or in QA phase.
But a good Scrum Master should be resourceful, and after a couple of days I found a guy who knew the guy, so the simplified workflow has been activated for our project and our project only.
Figure 6: Simplified workflow in JIRA column management
We have agreed on the columns and statuses with the team and got it launched. We agreed to have only 1 status per column, as drag-and-dropping a ticket from one status to another within the same column is impossible JIRA. But even with this pitiful limitation, it worked well for us.
What this change gave us? We started looking at our board during stand ups and throughout the day again. It provided the real picture of the current state of the sprint at a glance.
As well as it helped us tracking work better. Think about it, when we organize the board around sub-tasks, if we have 15 stories with 6 sub-tasks each, we would be looking at 90 elements displayed in the single board. How easy would it be to notice when one of them moves to another column? As opposed to organizing the board around stories, where we would see 15 stories only.
Not only it allowed for better transparency for both team and stakeholders, it helped us quickly identify bottlenecks, and have team steered towards dealing with those bottlenecks before it’s too late in the sprint. It also opened opportunities for further customization. Team have chosen to have test defects displayed as separate JIRA issues for better tracking.
After all, this brought team happiness level to where it initially was, removing the dissatisfaction associated with the tool performance.
Overall my recommendation is to train teams using sub-tasks at launch, and then quickly move to working with user stories as team matures in their agile journey.
Nevertheless, no matter which way you or team prefers, it is important to keep in mind that JIRA is merely a tool. A tool that is supposed to be serving the team, satisfying needs of the team. We must avoid customizing teams’ practices to fit the tool. As we remember, it all started with boards made of sticky notes, and we probably don’t want to roll back to these days.