Scrum Board

What is Scrum Board or Task Board or Sprint Board

A Scrum Board is a physical or virtual space that represents the scope of the current sprint and its status. The current scopes are broken down into executable tasks during sprint planning. A Scrum board mostly has the stories and their associated tasks. These boards are often called task boards as well. Its also called as Sprint Board or Task Board

Physical Scrum Board

Mostly co-located Scrum Teams, keep all the committed product backlog items along with the tasks for a sprint, on a board, or even on a wall. Any space that can be used as a flat vertical space, and accessible to the development team

Virtual Scrum Board or Digital Scrum Board

A Virtual Scrum Board or Task board is the same as your physical board. But it’s programmatically generated and rendered on your screen. It has the capability to share on multiple user screens with real-time updates of other members’ changes. Typically a distributed scrum team uses a virtual scrum board, as the single physical board is not accessible to everyone.

Modern days ALM Tools like, Rally, Jira, Version One, TFS, etc. provides one or many screens with extensive customization facility to prepare the virtual Scrum Board.

When we prepare the Scrum Board

Preparation of scrum board is a one-time activity, mainly the skeleton of the board. The team needs to update the scopes of a committed sprint at the beginning of each sprint, and clean the board at the end of every sprint. And again re-update the board with the start of the next sprint.

The Basic structure of the board remains almost the same throughout the project. With the rare instances of change in the structure. Only the contents of the board keep on rotating sprint over sprint.

The ALM tools like Rally, Jira, TFS, Version one, etc. have provided basic workflow and a default board structure. The tools also provide the facility to customize it, based on the team’s needs. That customization happens mostly before the first sprint starts or during Sprint 0. At a large organization, a group of people (Admin group of ALM tool) set the structure and enforce every team to follow the same board structure. On the other hand, many organizations keep the customization space open to every team to re-configure as per their sole need.

Many Co-located teams prefer to have a physical scrum board at their workplace easily accessible. The Scrum team collaboratively prepares the board at the beginning of the first sprint or before. And before each sprint, the team populates the story cards or task cards and cleans the board just after the end of the sprint. This board can be a whiteboard or can be a flat wall surface. Or a glass window etc. It just needs to be easily accessible for the team and visible to or accessible to any dependent team.

Who Prepares the Scrum Board

Who prepares the Digital or Virtual board?

Generally, most of today Agile teams use ALM tools like Rally, Jira, Version One, and TFS. And all those ALM tools digitally render the Scrum Board from the sprint backlog. This scrum board generates the board with default structure (columns and status association). The Organization’s standardization may set the default board configuration at the organization or program level to maintain consistency. The Admin also sometimes leaves the flexibility to the team to tweak the board configuration up to a certain extent. In that case, the Scrum Master, Product Owner, and the Development team collaboratively make the necessary change, before the first sprint or during sprint zero, and to keep the consistency of the board, the team should not change the board structure (columns, Status, story cards, Task card, etc.) very frequently.

In the case of this digital or virtual scrum boards, the task cards and story cards form automatically and do not need to create story cards or task cards.

Who prepares the Physical Board?

However, in the case of a Physical Board, the Scrum Team members collaboratively prepare a board (A physical whiteboard,  A wall or glass wall, or any open vertical space) before the first sprint.

As it’s a manual physical board, the story cards and task cards need to be populated before the sprint starts. The Scrum Master and the team place the story cards, task cards, and other necessary elements (which will discuss in detail in this article) on the board. This activity happens before the first day of the sprint. Similarly, once the sprint is completed, the team primarily the scrum master removes all the story cards and task cards from the board. and set the board ready for the next sprint.

How to prepare the Scrum Board.

Yes, this is the interesting part. How we can configure or prepare our board for the first time. To make it easy let’s divide the work into two-part, First lets us prepare the structure of the board as it will be a one-time activity. And then we will populate the board with our story cards or task cards from the sprint backlog.

[Part – 1] Making the Skeleton [One Time]

When the team starts preparing our board for the first time, The team mutually finalizes a structure and then starts implementing the board. If the team uses an ALM tool, they configure it accordingly based on the options available on that ALM tool. if the team uses a physical board then they start preparing the skeleton of the scrum board on a physical area accessible to the team. To Create the scrum board. Let’s first have a high-level understanding of Scrum workflow.

To prepare the structure we need a workflow, in another way what could be the possible states a story can travel through, from starting to ending, within a sprint cycle. For example, we can have any one of the workflows mentioned here, or we can create our own workflow.

Now secondly you need columns where we will assign status to each column. these columns are the visual distribution of the workflow status we had. each column should be assigned to at least one state, can be two or three, or can even more.

For example, if we decide to pick the 2nd workflow for our board

2nd workflow

Then we can have a column set like this as below.

Once we have our column ready we can have our workflow status mapped with the column. form the above example we can have two different associations of columns and workflow status as below.

Please Note.

Consult with your agile Coach 

Preparing or configuring the workflow or columns is a one-time activity and is mostly done by the Administrative group of the ALM tool. If you are using a physical board, then the decision of making the workflow or columns is mostly influenced by the agile coach or an experienced scrum master. if you are new to agile you may not have to do it. And in case you think you are the only person on the team who can do it, and are new to agile please consult with any Agile coach. Because understanding the organizational structure and nature of business and practice etc. is very important to plan the structure.

First & Last Columns.

When configuring your columns, always be careful in structuring your first column and last column. Keep in mind that movements of your action item must be in the team’s control and achievable within the Sprint time-box. within all the columns. For example, If the team members can not participate and enforce the end-user to complete the UAT within sprint duration. don’t configure a UAT column before Done Column. If you think the team can complete the UAT within sprint duration, and a UAT pass is one of your definition of done, make sure all the person involved to complete the UAT, is participating in your major scrum ceremony. This rule is applicable for any activity like a release to production or any beyond control action.

Similarly, your first column should with some action that the team can start immediately after sprint planning, and continue till done column or state without any interruption of external interference. We will not like to have a column on the business fund approval stage in our scrum board. If you are solely into any ALM tools. Then the functionality of configuring the board depends upon what ALM tools you are using, and what access rights you have. For example, within Rally you can not create a custom status. You have to deal with 4 inbuilt statuses Defined, In-Progress, Completed and Accepted. with addition to max two custom status, 1 at before Defined, and another after accepted. On the other hand, Jira has a wide range of flexibility in creating custom workflow and a custom scrum board.

All these will get clarified once you will watch the video tutorials on different ALM tools.

Once you have your Status and column ready, optionally you can have different swim lanes to categorize your work items. it can be distributed by the business unit of the work item, it can be divided based on whom it is assigned to, or most commonly you can divide it by the work items parent (Epics / Features ).

 In The example on the right, I have explained what the board will look like if we distribute the board by three Epics. Don’t create too many swim lanes, then the board will be too crowded or very hard to manage. And try to keep the swim lanes consistent throughout the project. You can create many useful reports on those swim lane levels.

Taskboard Vs Story Board

It’s Important to understand the fundamental difference between the Task board and Storyboard before we proceed to the next section. Task and Stories use to have a different workflow.

As a Story travel through the stages is like as below.

1. Backlog or New: When a Story is created for the first time in product backlog it use to have this status.
2. Groomed or Defined or Ready or Refined: When a Story is passed the Grooming session becomes ready (as per the definition of ready) to pick for the future sprint.
3. In-Progress or Committed: When a story is committed for a sprint, and the sprint is started.
4. Completed or Resolved: When the construction of the story is completed and ready for review. This means the functionality of the story is analyzed, developed, tested, and meets the definition of done.
5. Accepted or Done or Verified: This used to be the final state of the story workflow. where the story gets verified by the product owner by checking that the expected functionality is implemented and it meets the acceptance criteria.

1. These were the typical stages of a user story. We may create sub-tasks for each story, during our sprint planning meeting. Many teams may not create tasks and directly work on the user story. In that case, you can have a storyboard where columns will be mapped with each stage of the Story workflow. Many times in case we distribute the in-progress column into multiple sub-columns like Analysis in Progress, Development in progress, Testing in Progress, Code Review in Progress, etc. All those “Sub in-progress” Columns are internally mapped with the main In-Progress States. However, I always suggest breakdown tasks especially in Scrum for better transparency, management, effort distribution, and optimize the use of capacity.

1. So if we have a task breakdown, we will like to flow our tasks as per Task’s workflow. Task workflow mostly is different than story, as tasks need not be travel through all the stages a story does. Examples of tasks could be Analysis, Development, Test case creation, Testing, Web Design, UI Design, etc. All these tasks flow in their workflow with mainly three different states as below.

• To-Do: Task execution is yet not started.
• In-Progress: Task execution is in Progress.
• Done: Task executed.

Each story may have multiple tasks, and all those tasks are independently assigned to one team member and travel through the task workflow. So we will create our task board based on our task workflow. Below I mentioned two examples one for a Story Board and another for a Task board.

Important Board Contents

So far we learned how to prepare the space for story/task cards within columns and different swim lanes. There are a few components or areas you can also maintain to support the sprint, Daily stand up meeting, etc. as below

• Sprint Name

It’s good to have the sprint name on your board, as each sprint the contents of the board change. The Name Represents the current active sprint this body is representing.

• Sprint Day(s) remaining

It’s important to show the remaining day(s) of the sprint time box. As in Scrum, we commit stories to complete within a limited time frame. the day(s) remaining gives a quick relation between the amount of work remaining and the amount of day(s) remaining.

• Sprint Goal

During sprint planning, we achieve two outcomes, 1 Sprint goal and 2. Sprint Backlog. from the sprint backlog we will populate the scrum board with story cards and task cards, as executable action items. Having the goal visible will remind us why we are doing it, and for the team is, to achieve the goal.

• Burndown chart

The Burndown chart is an important artifact of the scrum, which represents the trend of the amount of work remaining since the first day of the sprint, compared with an ideal trend. It helps the team they are progressing at a sustainable pace or too slow or too aggressive. This can be drawn using a whiteboard marker, or a printout can be pasted.

• Definition of Done

The Done column is usually the last column on the board. each agile team defines the checklist to mark a story as done. That definition of done (DOD) is good to have on a board for a quick reference point. to move a story as done.

• Core Hour discussion area

During our daily scrum call, we try to conclude the discussion within 15 minutes. we may encounter a discussion point that may take longer. It’s a good practice to park that discussion item in a parking lot, and after the daily scrum call, only the interested team member can stay and continue the discussion. This area can be a corner of your scrum board, where someone can write using a whiteboard marker.

A sample Taskboard with the above-mentioned content area is attached below.

Note: preparing these content areas is only required for a physical board. These informative contents, charts, etc are also available on your digital board. the location or accessibility of the contents varies from one ALM tool to another ALM tool

[Part – 2] Placing Story Cards and Task Cards

Now we have our Storyboard ready to place our action item on your board, to get a visual representation of real-time sprint status and progress. Remember, All ALM tools generate those Cards automatically and place them on the board based on status. As each story and task have a status, and each status is mapped with a column. the auto-generated cards on your AML tool always get aligned to a board column. However, to work on a physical board we need to create these story cards and task cards manually and put them into our board. Let’s first try to understand what is Story Card and Task Card directory cards are normally a rectangular area (close to a playing card or School book label), for the physical board, we used to generate the story card from excel or MS word (Mail Merger Label) or any application, and print them. Then we use to cut the paper based on the card size. For a digital board these cards generate digitally, however, the layout can be configurable.

Typically the contents of a story card can be

1. Story ID
2. Story Title
3. Beginning of Story Description
4. Parent Object (Feature / Epic etc)
5. Story Points
6. Owner
7. Total Estimated Task Hours
etc. You can configure it based on your need.

An excel generated story card

Generation of Story Cards in Excel

Sample Story Cards of popular ALM Tools

Task Cards :

Let’s try to understand the task card. its looks the same as a story card, as stories are parents of tasks similarly story cards are also parents of task cards. Where story cards contain the content at a little higher level, mainly the requirement, acceptance criteria, etc. the task cards contain the executable level action items. The contents of a task card are typically are as below.

1. Parent Story (Id / Name)
2. Task ID
3. Task Name (e.g. Analysis, Development, code review, Test Case creation, Test case execution, etc)
4. Assigned to
5. Estimated effort hours
6. Remaining effort hours
7. etc.

These task cards are generally auto-generated by the ALM tools for a digital scrum board. In this case, the team members just need to create the stories under each committed story in the sprint backlog.

In case the team doesn’t use an ALM tool and works on a physical board, The team can use excel, MS word’s mail merge, or any other application to generate the task cards. I will explain in practical on the video on Scrum Board. To understand here attached here is a sample of task cards created from Excel. and a few task cards from different ALM tools as below.

Sample Task Cards Generated in Excel

Sample Task Cards from Jira

Sample Task Cards from Rally

Sample Task Cards from TFS

Now you have prepared the cards, or the ALM tool has prepared your cards for your board. It’s time to place the card onboard. ALM tool will do it for you. If you are using a physical board, you need to print the cards from excel,  word, or any app you have used to generate them. Then cut the cards and place them on your board. I have attached a few sample board diagrams below,  after the story cards and task cards are placed.

Note: In the below diagram, the story cards or task cards are in a different columns. When you will start the sprint all the cards will be in your first column.

A Physical Task Board (Grouped by Story)

Task Board in Jira (Grouped by Story)

A Story Board in Jira (Grouped by Epic)

Task Board in Rally (Grouped by Story)

A Story Board in Rally

Task Board in TFS (Grouped by Story)

The important contents of the board like Sprint goal, Burndown Chart, and Definition of Done, organized differently on different ALM tools, will cover separately in the ALM video tutorial of Scrum Board.

How to Use the Scrum Board

So far we have learned about Scrum Board, Story cards, Task cards, and also placing the cards on the board. Now we need to use the board effectively so that it represents the real-time states and progress of the team commitment of the particular sprint.

The main steps we do to keep the cards up to date are

• Update the remaining hours on each board

Within the ALM tool, team members update the remaining hours against the tasks or stories every day (at least once a day). The ALM tool takes care of the rest of the calculations like Parent level total remaining hours, including all the sibling Tasks. update the burn down etc. In the case of a Physical board, team members usually update the remaining hours during Daily scrum calls and update the burndown chart manually.

• Moving the cards from one column to another.

As and when the tasks and stories are getting executed they need to move from one column state to another, like todo to in-progress or In-Progress to done. The ALM tools provide the flexibility to drag and drop the story or task cards from one column to another, based on the defined workflow. In the case of Physical board team members move the story card and task cards manually from the current column to the next column. We will learn more in detail in our upcoming video tutorial.

• Reassign to team members if required.

In case the team found, at some given point of time, one team member is overloaded based on the remaining time of the sprint and remaining efforts. Then the team may try to reassign the tasks to another member who has bandwidth available.

• Identify and Mark Impediments

It’s Important to highlight a task or story’s block state, with its blocked reason. It will be a good practice to maintain the blockage. A scrum team should highlight the story card or task card that is currently blocked. Few ALM tools provide a straightforward mechanism to mark a story that is blocked or impeded. In a few other ALM tools, the scrum team creates a mechanism to highlight blocked story cards or impeded. If you are creating the mechanism, remember to maintain the states of the card. A blocked state is not a workflow state, don’t create a column for that. highlight the blocked state within its current state.

If you are using a physical board, you can use the red magnet button, small sticky notes (use for price tags), etc to highlight the task card as blocked. At the same time, at someplace on your board, write down the Task id /story id with the blocked reason and blocked date, using the board market’s a good practice to assign the blocker to some team member as a primary responsibility to resolve it. Scrum Master is primarily responsible to resolve all impediments or blockers. Discuss the blocker every day during your daily scrum call.

It’s very easy in the ALM tool, as in the ALM tool the cards can be moved by drag and drop. Where in the physical board, the team member moves the card manually from one column to another column

At end of the sprint, you realize that most of the cards moved from the left side to the rightmost column.