Scrum and Kanban Boards

 

The Scrum Board is an important component of the Scrum methodology. This board is used by Agile teams to track their development work within time-boxed iterations called Sprints. The Scrum Board shows all backlog items that need to be completed within the current Sprint. Team members use the board by completing work and making updates continuously throughout each Sprint. Scrum team members typically make updates to the board daily because of progress made the previous day. The board’s layout consists of rows and columns, where each row contains user stories (units of work), and columns that show the status. Scrum boards provide a fast, simple view of the user stories selected for a Sprint that the development team is working on and have been completed. Figure 1. shows a typical Scrum Task Board used by the Scrum team.

Figure 1. Scrum Task Board

Every row on the Scrum board contains user stories that represent product backlog items that have been selected during Sprint Planning. Following is a description of the columns on the board:

• The “Story” column identifies the user story that is ready to be worked on by the development team.
• The “To Do” column represents tasks that need to be completed.
• The “Work in Process” column represents tasks that are currently being worked on.
• The “To Verify” column represents tasks that need to be verified and tested.
• The “Done” column represents completed tasks.

The Kanban Board

The Scrum board, as well as the Kanban board, is used to show the progress of development work. Both boards are categorized as whiteboards in the “To Do-In Progress-Done” categories. The Kanban board is used to display the work process flow and the number of items in the work in progress (WIP) column. According to Lean concepts, WIP should be limited to where it is small enough to avoid wasteful tasks, but large enough to reduce the number of idle workers. In terms of WIP limits, the following applies:

• Scrum limits WIP per Sprint. The Scrum team can have unlimited items in the “In Progress” column.
• Kanban limits WIP per workflow status (Ready, Kick-Off, In Progress, Review, Accepted). A number in the “status” sections means that the maximum number of items cannot be greater than that number. Figure 2. Shows an example of limits on the Kanban board. Observe that the Kick-Off Column has 1 as its limit, In Progress has a 3, and Review has a 2.

Figure 2. Kanban Board with WIP Limits

Kanban vs. Scrum Board

With a Scrum board, the entire team is responsible for each task. With the Kanban board, the team is not responsible, but each person has responsibility for their step on the task flow (development, testing, verifying, etc.). If a team member has completed their task, that person can choose what to do by either helping another team member with their taskings or take on another activity from the queue. A Scrum board is used by one Scrum team whereas the Kanban board is a workflow that is not required to be owned by a specific team. The Product Owner should not be able to make changes to a Scrum board because of the team’s commitment to complete a specific number of user stories. The Scrum team members are the only parties that can make changes to the Scrum board. With Kanban, the Product Owner (or proxy such as Service Delivery Manager) can edit the Kanban board. The Scrum team should not add any new items to the Scrum board during a Sprint. Work items are set in stone during Sprint Planning before iterations begin. Kanban has no established time frame for making updates to its board because it has limits on the work in progress activities. When tasks are moved from the In-Progress column to the Done section, capacity is released and new work items goes to the Development queue.

Team Utilization                  

In some cases, an Agile team may decide to add additional categories to their Scrum Boards that match their actual workflows. Most boards have a minimum of three categories: To Do, Work in Progress, and Done. The optional categories may be, for example, Testing or Verify columns. A virtual Scrum Board adds a lot of value to Product Owners and Scrum Masters can create metrics that help improve the Scrum team’s processes. Often, teams use a combination of physical and virtual boards to the relevant advantages of both. Additional categories that are used on Scrum boards include but are not limited to the following:

• New Features
• Tasks
• Defects
• Change Requests
• Technical Requirements
• Knowledge Attainment

Physical vs. Virtual Boards

When a team is physically located in the same space, it’s better to use a physical Scrum Board. The board is better utilized when it is in a common area where the team can view and access it very easily. In some companies, this board is placed by the water fountain, a place where many people gather and communicate. This can result in a better collaborative work area. If a team is geographically dispersed, it would be better to use a virtual product such as for example, VersionOne, Rally or JIRA. Following is a comparison of physical and virtual Scrum Boards as shown in Table 1.

Table 1. Virtual and Physical Scrum Boards Comparison

Keywords: scrum, board, teams

References:

Gunter, Stuart. (2012). Experimenting with Horizontal WIP Limits in Kanban. Retrieved from https://www.stuartgunter.org/posts/experimenting-horizontal-wip-limits-kanban/

Kanban Tool. (2017). Scrum Task Board: Apply Scrum Methodology with Kanban Tool. Retrieved from http://kanbantool.com/scrum-task-board

Mountain Goat Software. (2017). Scrum Task Board. Retrieved from https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/task-boards

RealtimeBoard, Inc. (2017). Scrum vs Kanban Boards: 11 Major Differences. Retrieved from https://realtimeboard.com/blog/scrum-kanban-boards-differences/#.WZsybSh97Zs

Scrum Inc. (2017). Scrum Board. Retrieved from https://www.scruminc.com/scrum-board/