Using Boards for Iteration or Flow and knowing the difference

08.20.2018

Boards are available in many issue management tools now. Widely known as “you know, like in Trello,” this form of visualizing work is an immediately obvious improvement to how we understand getting things done. Typically boards are used to represent issues, as cards, moving across columns, which represent value states progressing from To Do to Done, with various states in between. The purpose of our work can inform us on optimizing our board setups. Jira, for example, has a couple Board options, which are highly configurable. Knowing some concepts will go a long way here to really maximize this tool for our teams.

Boards are for teams to Iterate or Flow

Whether a team is responsible for part of a project, a whole project, or multiple projects, it can use a Jira Board as a workflow for completing issues. Boards are configured using Jira Query Language filtering to show the team the issues it is looking to pull to work on. Whether it should choose a Scrum Board (for Iteration) or a Kanban board (for Flow) largely depends on the task size and the project’s goals at that time.

Scrum Board for Iteration

A team that is working toward completing epics will typically want to use a Scrum board to iterate toward a project’s overall desired outcome. A team in this situation will find itself faced with a Backlog that has Epics that have been broken down into Stories. The Stories have been prioritized within the Backlog and also within their Epics. The Epics should also be prioritized amongst themselves. Jira has a view for planning Sprints that takes advantage of this prioritization by allowing you to build a Sprint out of the most important Stories from the most important Epics. When you do the top tasks from multiple Epics in each Sprint, it ensures that each Sprint is working toward the most valuable iteration possible.

In reality, a true iteration cannot be expected to be produced each Sprint. Iterations provide an optimized awareness into a larger effort and that is not always the case at the end of each Sprint. In a Jira Scrum project, Versions can be made up of issues done across multiple sprints, and you can use one to release an iteration of a project.

Kanban for Flow

A team that can expect to be working on smaller tasks that are all about the same size will likely want to use a Kanban board to optimize for the flow of tasks through the boards. Jira provides column limits you can experiment with to discover where tasks are too slow to come into a column (that column’s issue count is below a minimum you set) and where bottlenecks are prone to occur (that column’s issue count is above a maximum you set). As you learn, flow will improve and issues will complete faster, reliably making it to the Done column. In a Jira Kanban project, releasing uses Versions to mark the end of a cycle where the team can reflect on how it is progressing toward an overall desired outcome.

To experiment with column constraints, discuss each column with your Component Team about what it would mean for each to be too low of a number of issues, and also too high of a number. It will be different for each column, including possibly not mattering for a given column. The goal is to pick minimum and maximum numbers for columns where it will matter and try it until the next retrospective.

For example:

What might it mean if the To Do column had too few issues in it? How would that be best corrected? Maybe increase backlog grooming efforts?
What might it mean if the To Do column had too many issues in it? Are we overloading ourselves?
What might it mean if the Review column had too many issues in it? What might we try to alleviate that?

To experiment with encouraging increased collaboration, try setting the In Progress maximum issue constraint to one less than the number of developers on the team. This will encourage looking at other columns for issues that could be moved along before pulling in something new to be In Progress.

The goal is continuous improvement, meaning better and better flow of issues across the boards. Columns should not run dry, nor should they have a pile up. Column constraints are there as indicators to alert the team that something is happening that it wanted to be alerted to so they could consider the flow state given a current situation. A breached column constraint can mean many things, but it should not be seen as a failure of the team. That is not what they are for.

But wait, there are Epics on my Boards!

Having Epics on your Boards can happen when a project evolves to a point where optimizing for flow and delivering continuously becomes more important than larger iterations. Since Epics typically do not belong on Boards, you can manage this by using Epics as Swimlanes. Since this configuration is not a fit for everyone, and to restore flow on your todo column, Jira introduced the Kanban Backlog in Server 7.4 (Cloud has it too, of course) which allows a view similar to Jira’s Sprint Planning view, with Epics and Versions on a side column. Here one can groom and prioritize a Backlog and choose items which are ready, Selected for Development, and prioritize them. At that point they are made available to the Kanban Boards to be pulled from the top of the list into the In Progress column.

The difference

Since good flow is always valuable, the difference between these board choices comes down to whether or not iteration is of value to your project. Is the team working toward an idea big enough that it needs the time to finish a reviewable version that is representative in some way of the whole idea? If so, the team would be planning to use that iteration as a point of awareness, through which they could reasonably decide how to continue with their work. If this is the case for this team and what they are setting out to do, then it’s better to work in a way that focuses on iterations as a point of optimized awareness into a version that is working in some way. Otherwise, we might cancel our project if we had to make a decision from reviewing a broken thing.

If the team’s work is past the point where iteration is valuable, then there is no reason to delay the awareness into its work, nor to delay the flow of value to the customer.