How to Use Scrum Board for Agile Development

How to Use Scrum Board for Agile Development

A Scrum Board or an Agile Board is a visual representation of the work planned, progressed, and completed by a scrum team in a sprint or iteration at any given point of time. The board is comprised of columns that represent various successive states of the workflow progressing from left to right. The work items appear in the column as per their current state in the development workflow and then move across the board from one column to the next till they reach completion or last stage.

The “To Do / Ready” and “Done” states appear in almost every Scrum Board, the “In Progress” items can be further categorized into various states e.g. – Analyse, Design, Code, Test etc. These states are solely created as per the needs of the Scrum Team and Project.

Image 1: Simple Scrum Board  

The Scrum Board visually represents the amount of work along with their current states in a Sprint.  The Board speaks to the team everyday about the holistic progress made by the entire team towards their Sprint Goals and provides a sense of accomplishment and achievement when work items are completed. 

It avoids creation and progress of “Hidden Work” or “Shoulder Tap” injected work that may not be prioritized. In the event of an interruption (like production issue, any new or changed requirements, changed priorities), it helps Business to reprioritize the work items quickly looking at the current state of the planned items in the Sprint.   

It also keeps reinforcing road blocks and impediments faced by the team to all the major stakeholders. Any number of written and verbal communication may not be able to visually represent the state of the entire sprintas a whole as effectively as this visual radiator.Scrum board allows teams to manage the flow of work across the sprint as it helps in avoiding multi-tasking, overloading one person because everything is visible and traceable. 

Teams that are entirely collocated can benefit from physical boards that caneven just be a whiteboard placed near their work cubicles. A physical board could also be on a wall having coloured tape for columns and sticky notes for cards.  Team members typically swarm around the board /agile wall/task wallduring their daily stand up or whenever there is a need. 

  Image 2: A typical physical scrum board

Image 3: A typical Jira scrum board

Distributed teams on the other hand find virtual boards easy to use. There are many tools available in the market to set up Scrum Boardssuch asJira , Rally , Monday.com etc.  

In some companies, the Scrum boards are displayed on giant monitors placed near the teams work cubicles. 

Cards and Columns are the two basic entities on the scrum board.Card is the entity on the board that represents a “Work Item”. A Card can be a User story /Production Bug/Technical Task. During the course of the Sprint these cards travel through the board from left ,“To-Do” to right “Done”.  

The Scrum Board below is an example of a typical team board in a software project. 

Image 4: Typical scrum board for a software project

The items on the Product Backlog are discussed and as per priority and their readiness, pulled into the “To Do” or “Ready” column during Sprint Planning. At the beginning of a Sprint all items in the “To Do” or “Ready” column comprises the Sprint Backlog of the team. 

As the Sprint progresses, the items move into the downstream columns until “Done” is reached. A clear “Definition of Done” helps to conclude if the story / task is completed. 

Usually beginner teams build the board translating the current workflow of their work items into columns on the board. As the teams evolve, they adjust the board accordingly. 

Physical Cards usually are post-it notes or sticky notes that carry the User Story/Description, Acceptance Criteria and the Story Points as a minimum. Using post-it notes is a deliberate attempt to keep the story small and avoid loading a lot of work into one story.  

In a Virtual board, cards can have exclusive fields to carry information like Project Name/Assignee/Reporter/Created Date etc. These might serve multiple purposes like metrics/reports. 

Colour coding is an excellent technique used to convey important information to the audience at the first quick glance.Cards can be colour coded based on their work type like User Story/ Technical Task/Production Bugs. Cards could also be flagged (in the case of a Virtual board) or overlaid with a (preferably) Red coloured card to convey a risk/dependency that needs attention. 

Defining Swim lanes is a very useful mechanism to categorize the work items on a Scrum Board. They are horizontal rows on the board that carry a specific type of work that is different from the normal/ work categorized by a certain parameter. 

For e.g. a team that has to resolve emerging high priority production bugs would prefer to use a “Fast Track” swim lane to progress the bug and then continue with their original Sprint work. 

A team that works on hardware, firmware and software components in a sprint might want to use different swim lanes for each component.  

Swim lanes are for the teams. Creating a swim lane for each team member may not be a good idea since the basic guideline for scrum is to work as a team and this representation might affect a team’s mindset. 

In the board below blue cards are User Stories and green Cards are tasks. Red cards are Production bugs. Some cards are flagged red indicating risks or impediments. 

Image 5: Example of scrum board with colour-coded cards and swim lanes

A common challenge encountered in projects is when tasks accumulate or pile up in a phase or stage of the workflow. There could be several reasons why that happens. But identifying them is the key to solving that challenge and the Scrum Board effectively helps in this. 

Assume that Cards D, E, F, G have completed development and ready for testing. Cards B, C are being tested. It is day 6 of a 10-day Sprint.  

Developers might now bring in H, I from the Ready Column to start development work, creating a bottleneck at Testing. 

Image 6: Scrum Board without WIP Limits

Concepts of Kanban can be borrowed into a typical Scrum board to address this. One of the techniques that can be used is to split the column into “In Progress” and “Ready”. This will set the stage for a “Pull” mechanism at every stage in the workflow of a story.  

Introducing “WIP Limit” or “Work in Progress” Limit at the columns ensures multiple work items do not pile up at one stage of the process, do not get “pushed” downstream but rather gets “pulled” by downstream process and there is a steady flow created in the system. 

Considering the team is at day 6 of the iteration, it is recommended the team “stops starting and starts finishing”.  If the team swarms and completes the testing of D, E,F,G there could  be more business value delivered rather than starting development of H and I and having only few of the Development complete cards partially tested. 

In this scenario, a WIP Limit of 4 at development prevents the team from bringing in more work items into the development phase. The team can now swarm to complete the testing of the developed items taking them to completion.  

Image 7: Scrum board with WIP limits and columns split into “In progress” and “Ready”

Scrum board is owned by the team and it is the team’s responsibility to update the board to reflect the reality.The team also has the responsibility to evolve the board to suit the need of the project by experimenting on concepts of WIP Limit. 

Scrum Board can be used to identify bottlenecks in the flow of work. If bottlenecks are identified in one stage of the workflow, the team can resort to Swarming or enforcing WIP Limits. 

Seeing the work items move through the Scrum board and reach “Done” during the Sprint provides the team a sense of accomplishment. 

Easier said than done, updating the board is one of the biggest challenges faced especially in beginner teams. Not every team member will be prompt in updating the board. To overcome this challenge, updating the board could be one of the team ground rules with non-compliance attracting fun consequences decided by the team, such as the defaulter treating the team with chocolates/coffee or updating everyone’s scrum board the next day. 

The Scrum Master can immensely help the team realize the power of the board by using it during agile ceremonies like planning, stand up and retrospectives. Facilitating the scrum by traversing the board from right to left (i.e.“Done” to “To-Do”) is another tactic to keep reinforcing the value of the board and motivating the teams.Having conversations in stand-ups by traversing the board from right to left will first bring up cards that are done or almost done and helps see what has been accomplished in the sprint.  

A Scrum Board cannot replace the conversations and interactions that are always encouraged in Agile projects. Flagging a card on the scrum board / posing queries on a card should not solely replace the conversations around these. 

A Scrum Board is not for executives to monitor the team’s progress and efficiency, but it is for the team to monitor their sprint items as a whole. 

A Scrum Board is an excellent tool for the team to visualize their work, look at everyday progress, identify bottlenecks, make immediate course corrections, so that they can meet their Sprint goals. 

Used rightly, it will serve the team and benefit them. However, if it is used by management to monitor the team or if the team members consider it as a tool to update management then it loses its purpose and becomes just another overhead. 

Research & References of How to Use Scrum Board for Agile Development|A&C Accounting And Tax Services
Source

Leave a Reply

Related Post