The Scrum Board

The Scrum Board is an important component of the Scrum framework. 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 makes 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.

Every row on the Scrum board contains user stories that represent product backlog items that have been selected during Sprint Planning. The 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 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 limits the quantities of tasks that are in the in progress column. According to Lean concepts, the quantity of in progress tasks should be limited to where it is small enough to prevent wasteful tasks, but large enough to minimise 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.

Kanban versus the 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 must not add any additional 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 quantity of in progress tasks. When tasks progress from work In-Progress to the Done column, the development team will have the additional capacity to progress with new work items.  They can then move a new tasks into the In-Progress column.

We found these books great for finding out more information on Agile Scrum:

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, In Progress, and Done. The optional categories may be for example, Testing or Verify columns. A virtual Scrum Board adds a lot of value in that 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 Scrum Board

When the scrum team (Scrum Master, Product Owner and Development Team) are physically located together, it is often considered better to use a physical Scrum Board. A physical board is better utilized when it is in a common area where the team can view and have access to the board  very easily. The scrum board should be in view of the entire scrum team and should ideally be located in a place where the team can gather and communicate around the board.  This gathering and communication in front of the board helps during the daily scrum meeting for example.  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. The following is a comparison of physical and virtual Scrum Boards as shown in Table 1.

Physical Boards	Virtual Boards
Forces co-location and face-to-face communication.	A geographically disbursed team can work seamlessly together and the Scrum Board is always visible to everyone at any time from any place.
The discipline needed to create consistent cards with the relevant information is easier to accomplish.	The virtual board has much more customization options that can be matched to the needs of a business.
Ease in changing the process workflow.	More ease with workflow analysis and report preparation.
Physical boards create focal point for daily stand-up meetings.	Historical data is readily available.
Physical cards have space limitations.	Virtual cards have greater information capacity.

Table 1. Virtual and Physical Scrum Boards Comparison