A refinement board is a way for your team to visualize your backlog refinement workflow. It’s a specific form of Kanban board. The columns on the board represent the steps you follow to refine backlog items.
When colocated teams were more common, you’d often see refinement boards on a whiteboard or wall divided into columns. In that case, you’d use sticky noes or cards representing backlog items.
Now that most teams are distributed, it’s much more common to see refinement boards represented in a backlog management tool. Fortunately a board display is pretty much a parity feature in any backlog management tool.
Because I’m a freelance product manager, I use what ever tool the team I’m working with uses. That means I have experience setting up refinement boards in Azure Dev Ops, Trello, Jira, and Clickup.
An Example
Below is a sample refinement board that matches the columns I’m currently using, followed by a description of each column.
Refinement board columns
- Draft: Placeholder backlog items that I created for an item from the roadmap that’s in the Now column.
- In Refinement: Backlog items that I’m actively working on. Some items stay in this status for only a few minutes as I get them written up. Others sit in this column for a while if I need to clarify some information.
- Refinement Done: Backlog items that I’d like others to look at to make sure it makes sense. This column is a queue for the tech lead or devs to look at.
- Reviewed: Backlog items that the tech lead or another developer feels comfortable it contains the necessary information to start work.
- Approved for Work: Backlog items that someone on the team can pick up and start working.
Different teams have different columns
The columns I have on my refinement board change from one team to the next. These changes usually result from our definition of ready discussions.
The team that I use this set of columns is a globally distributed team of part time developers. We tend to use a flow approach. So when a developer looks for the next thing to work on, they’ll pull an item from the Approved for Work column. This team also has a tech lead who I ask to look at the more technically involved backlog items. If we’re making changes to an existing piece of the product, I’ll skip the Refinement Done/Reviewed column and go straight to Approved for Work.
If you’d like an example of another set of columns, take a look at the discovery board article. I decided I need to change the name of the technique. I wanted to reinforce the idea that discovery is the act of interviewing users and researching their needs.
When to use a refinement board
Refinement boards are most useful in situations where:
- you follow a specific workflow to get your backlog items ready for someone on your team to pickup
- It’s helpful to know where a in the workflow a particular backlog item is
- Multiple people are involved in getting backlog items ready.
With iterations
If your team follows an iterative approach, such as Scrum, it’s helpful to have separate refinement delivery boards. The refinement board contains backlog items you’re preparing for sprint planning. The delivery board contains items included in the current sprint. This also shows what your refinement process may look like if your team sizes your backlog items.
Without iterations
If your team doesn’t work in iterations, it’s helpful to have a single board where the first few columns represent columns I’ve described here, and the remaining columns reflect columns that you’d typically see on a delivery board.
For example, the team I currently work with as I write this follows a flow approach. We use the columns I describe above for the refinement process. Our board continues with the following columns:
- In Progress: A team member is making the changes described in the backlog item. Hopefully they’re also unit testing it and writing automated tests for it.
- Review (PR Ready): The developer made the necessary code changes and created a Pull Request (PR) that needs a code review.
- PR Merged (Staging): The changes passed code review and the changes are in the staging environment. This is my signal that I need to look at it from a user acceptance perspective.
- QA/Testing: This is a holding column that some items go into if the testing takes a while, or we explicitly want our SMEs to look at the changes before calling it done.
- QA Done: Everyone (usually me) is done testing the changes, and it’s waiting for promotion to production.
- Closed (In Prod): We’ve moved the changes to production.
We also have a Removed status for backlog items we choose not to do, but didn’t want to delete.
Why use a refinement board
The refinement board brings visibility to the state of your team’s backlog. It also shows how many backlog items are ready for your team to start development and testing.
If you follow an iterative approach (such as Scrum), the refinement board provides your team an idea of which backlog items you’ll discuss during estimating sessions and which backlog items you’ll fleshed out next. This helps your team hold much more effective iteration planning sessions.
The refinement board also provides a visual aid when you talk to your stakeholders about difficulties you may be having with the backlog, such as too many backlog items coming in with insufficient information or not enough valuable backlog items to work on.
How to use the refinement board
Creating the refinement board
- Gather the team together and discuss whether it would be helpful to visualize the backlog refinement process. If so, continue.
- Discuss the steps in the team’s backlog refinement workflow. Determining which steps warrant a separate column is a little subjective, but there are some guidelines. If different people tend to do different, or if discussions that requiring some preparation occur at certain points, those may be good column candidates. It’s also helpful to know if every backlog item will go through every step. If backlog items hit some steps only in certain circumstances, those may be candidates for tokens (see step 7).
- Determine policies for each column. You can also think of these as entry criteria: What things need to be in place in order to have a backlog item in that column?
- Determine if you need any buffer columns between the process steps. These are especially helpful if your team wants to know which backlog items are actively being worked on versus which ones are just waiting for the next process step.
- Decide what information your team wants to display on the cards you use to track product backlog items, and create a backlog item for in process work.
- Place the in-process backlog items in the appropriate column.
- Determine what tokens your team wants to use to stand in for things not indicated by the columns on the board, such as blocked backlog items or backlog items needing research.
Using the refinement board
Once you create your refinement board, use it to track the status of product backlog items in backlog refinement.
Depending on what columns are on the board, you can use certain columns as agendas for team events such as sizing discussions. And if there aren’t any items in those columns, you can cancel your upcoming sizing discussion.
Your refinement board can also serve as a to-do list for people who focus on the refinement process to determine which backlog items they need to get ready next. It also provides a clue to other team members that they need to help out to make sure your team has enough backlog items ready for the next iteration planning.
It’s often helpful to have someone on your team to own the refinement board. This means they make sure backlog items are in the appropriate column and they instigate discussions with team members and stakeholders necessary to get the right backlog items (i.e., the ones that produce the most value when completed) ready.
Finally, if your team is colocated, it’s very helpful to have your refinement board and delivery board next to each other so your team can do your stand ups the boards. This focuses your discussions on items in play on either the refinement board or the delivery board instead of having people say what they did, what they are doing, and what obstacles are in their way.
Caveats and Considerations
Each team’s columns may be different. The format and layout of each board are based on how that team approaches backlog refinement.
Backlog items progress across the board from left to right. Within each column, the position of the backlog item represents its priority, with backlog items that should be dealt with first appearing at the top of that column.
Refinement board is a special case of a Kanban board
The refinement board is roughly based on the idea of a Kanban board, where items continuously flow across the board as they are being readied for iteration planning, unlike a delivery board, which is effectively cleared off at the end of each iteration and reset.
Most teams who use refinement boards do not implement work in process (WIP) limits. That’s not to say that at some point they wouldn’t do so, especially if they found that work was not progressing through backlog refinement smoothly enough. But for those teams, using the target of having a sufficient number of backlog items ready for the next iteration planning seemed to be a sufficient regulator for items on the board.
Physical refinement boards
If you have a colocated team, you’re better off with a physical refinement board. People tend to be more likely to glance at the wall to get a quick check of status than to make an explicit effort to go to a tool and look at the status of items there. The physical board also aids with daily coordination discussions as people can physically move cards and point to them when they are discussing a particular item.
Physical boards are great for displaying status but are not as useful when the team is virtual, or the team needs to maintain detailed information about their product backlog items. An approach that works well for these teams is to have both the physical board and an electronic repository. The physical board acts as the source of record for status of the backlog item. The electronic repository is the source of record for details about the product backlog item. If the board and the electronic repository differ, trust the physical board. When you note discrepancies you should resync the two sources.
Many agile tracking tools can graphically represent boards. teams have found it helpful to replicate a view of both the discovery board and the delivery board for remote team members.