When working during a iteration (or referred as sprint) within the Scrum framework the team can use a Kanban board. “Kanban” is the Japanese word for “visual signal” and is like Scrum, a framework within the Agile model. A Kanban board is used to visualize the work to be done as cards on a board, in different states. This allows you to easily see the “big picture” of where the project currently stands. As well as identify potential bottlenecks that could affect productivity. When you are using Scrum and Kanban in combination this is also referred as Scrumban.
One can choose to use an physical board or a digital board, or even both. Both have pros and cons. One of the benefits of having a digital board is that most digital boards automatically add all kind of details on the cards of the board. Such as the person working on the card, the amount of story points, the priority, the status and more. In addition, digital boards are flexible. You can filter, search or change them very quickly depending on your needs at that moment.
I want to share with you how we setup our Kanban board for the iteration execution and the backlog refinement. Keeping in mind that we use the Scaled Agile Framework. Within our work environment we use JIRA as the issue-tracking and project-management software. As such we have a digital board. There are many alternatives for JIRA, such as Microsoft Planner, Trello, et cetera.
Iteration Board
During the daily stand-up the iteration board (Scrum board, storyboard, Kanban board) is used to check upon the progress of the iteration. The progress is defined using 4 separate columns and different statuses. Furthermore we use swimming lanes to categorize work per feature.
| Column | Status | What |
|---|---|---|
| ToDo | n.a. | Iteration backlog, issues which were planned during the iteration planning event. Currently in waiting to be picked-up by the team. |
| In Progress | • In progress • Testing • Analysis | Issues which are in progress. Testing and analysis are added as status to give a little extra context. |
| Waiting | • Review • Blocked | Issues which are in waiting, such as a review or being blocked for any reason, e.g., due to a dependency to a different team or supplier. |
| Done | n.a. | Issues which are resolved. |
Additionally one could add an extra column called “Verify”. Team members put the card to “Verify” when finished. The Product Owner of the team asses the card to determine if it is really done. If so, he moves it to done. This makes the handshake between the Product Owner and the team more vivid.
Backlog Refinement
The backlog refinement board is created to check and make the refinement of the backlog more visual and explicit. During the iteration the board is impromptu checked by the team. Likewise as the iteration board it has different columns to distinguish the status of refinement. Additionally “exit” criteria are defined. These elaborate on when a card is allowed to be moved to the next column.
| Column | What | Exit criteria |
|---|---|---|
| Funnel | Issues which are created but still need further refinement. Anything can be put here. | • Assigned to Program Increment • Feature is known |
| Refinement | Issues which need to be refined more. | • Title gives context • Assigned to a person • Acceptance criteria known • Story points known • Team definition of ready is applied • Assigned to iteration |
| Review | Issues which are refined by the team and need to be reviewed by the Product Owner. | • Reviewed by Product Owner • Handshake between Product Owner and team |
| Backlog | Issues which are agreed upon and are ready to be picked-up in an iteration. | No exit criteria, issue is now assigned to iteration and can be picked-up by the team. |
| Rejected | Issues which are rejected by the Product Owner and the team. | Not applicable |