A Scrum Board is a physical or virtual space that represent the scope of current sprint and its status. The current scopes are broken down into executable tasks during sprint planning. A Scrum board mostly have the stories and its associated tasks. This boards are often called as task board 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, in a board, or even on a wall. Any space that can be used as a flat vertical space, and accessible to the development team
A Virtual Scrum Board or Task board is same like your physical board. But its programmatically generated and rendered on your screen. It has the capability to share on multiple user screen with real time update of other member’s change. Typically a distributed scrum team use a virtual scrum board, as single physical board is not accessible to everyone.
Modern days ALM Tools like, Rally, Jira, Version One, TFS etc provides one or many screen with extensive customization facility to prepare the virtual Scrum Board.
Preparation of scrum board is one time activity, mainly the skeleton of the board. The team needs to update the scopes of 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 start of next sprint.
The Basic structure of the board remains almost same throughout the project. With rare instance of change on 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 provides the facility to customize it, based on the teams need. That customization happen mostly before the first sprint starts or during Sprint 0. At 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 organization keep the customization space open to every team to re-configure as per their sole need.
Many Co-located team prefer to have a physical scrum board at their workplace easily accessible. The Scrum team collaboratively prepare 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 clean the board just after end of the sprint. This board can be a white board, 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 prepare the Digital or Virtual board
Generally most of today Agile team use ALM tools like Rally, Jira, Version one, TFS. And all those ALM tools digitally render the Scrum Board from the sprint backlog. These scrum board generates the board with default structure (columns and status association). The Organization’s standardization may set the default board configuration at organization or program level to maintain the consistency. The Admin also sometime leave the flexibility to the team to tweak the board configuration up-to 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 consistence of the board, they 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 forms automatically, and does not need to create story cards or task cards.
Who prepare the Physical Board
However in case of a Physical Board, the Scrum Team members collaboratively prepare a board (A physical white board, A wall or glass wall or any open vertical space) before the first sprint.
As its a manual physical board, the story cards and task cards needs to be populate before the the sprint starts. The Scrum Master and the team place the story cards, task cards and other necessary elements (will discuss in details 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 remove all the story cards and task cards from the board. and set the board ready for the next sprint.
Yes this is the interesting part. How we can configure or prepare our board for the first time. To make it ease lets divide the work into two part, First lets us prepare the structure of the board as it will be one time activity. And then we will populate the board with our story cards or task cards from sprint backlog.
When the team start preparing our board for the first time, The team mutually finalize a structure and then start implementing the board. If the team use a ALM tool, they configure it accordingly based on the options available on that ALM tool.
if the team use 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. lets first have a high level understanding of Scrum workflow.
To prepare the structure we need a workflow, in other way what could be the possible states a story can travel through, from starting to ending, within a sprint cycle. For an example we can have any one of workflows mentioned here, or we can create our own work flow.
Now secondly you needs columns where we will assign status to each column. these columns are the visual distribution of the workflow status we had. each column should assigned to at least one states, can be two or three or can even more.
For example if we decide to pick the 2nd workflow for our board
Then we can have 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 association of columns and workflow status as below.
Consult with your agile Coach
Preparing or configuring the workflow or columns are one time activity and 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 are mostly influenced by the agile coach or a experienced scrum master. if you are new to agile you many not have to do it. And in case you think you are the only person of the team can do it, and new to agile please consult with any Agile coach. Because understanding the organization 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 on structuring your first column and last column. Keep in mind that movements of your action item must be in the teams control and achievable with in Sprint time box. with in all the columns.
If the team members can not participate and enforce the end user to complete the UAT with in sprint duration. don’t configure a UAT column before Done Column. If you think the team can complete the UAT with in sprint duration, and UAT pass is one of your definition of done, make sure all the person involved to complete the UAT, is participating on your major scrum ceremony. This rule is applicable for any activity like 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 business fund approval stage in our scrum board.
If you are solely into any ALM tools. Then the functionality of configuring the board is depend upon what ALM tools you are using, and what access rights you have.
For an example within Rally you can not create custom status. You have to deal with 4 inbuilt status like 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 have wide range of flexibility on creating custom workflow and custom scrum board.
All these will get clarified once you will watch the video tutorials on different ALM tool.
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 how the board will looks like if we distribute 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 through out the project. You can create many useful reports on those swim lane level.
- Backlog or New : When a Story created for the first time in product backlog it use to have this status.
- Groomed or Defined or Ready or Refined : When a Story is passed the Grooming session and become ready (as per the definition of ready) to pick for the future sprint.
- In-Progress or Committed : When a story is committed for a sprint, and the sprint is started.
- Completed or Resolved : When the construction of the story is completed and ready for review. Means the functionality of the story is analysed, developed, tested and meets the definition of done.
- Accepted or Done or Verified : This use to be the final state of the story workflow. where the story get verified by the product owner by checking the expected functionality is implemented and its meeting the acceptance criteria.
- These were the typical stages of user story.We may create sub tasks for each story, during our sprint planning meeting. Many teams may not create tasks, and directly working on user story. In that case you can have a story board where columns will be mapped with each stages 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 internally mapped with the main In-Progress States.However I always suggest to breakdown task in specially in Scrum for better transparency, management, effort distribution, and optimize use of capacity.
- So if we have task breakdown, we will like to flow our tasks as per Task’s workflow. Task workflow mostly be different than story, as tasks needs not to be travel through all the stages a story does. example of tasks could be Analysis, Development, Test case creation, Testing, Web Design, UI Design etc. All these tasks flow in there 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 independently assigned to one team member and travel through the task work flow. So we will create our task board based on our task workflow.
Below I mentioned two example one for a Story Board another for a Task board.
We so far we learned how to prepare the space for story / task cards with in columns and different swim lanes. There are few components or area you can also maintain to support the sprint, Daily stand up meeting etc. as below
- Sprint Name
Its good to have the sprint name on your board, as each sprint the contents of the boards changes. The Name Represents the current active sprint this bod is representing.
- Sprint Day(s) remaining
Its important to shows the remaining day(s) of the sprint time box. As in Scrum we commit stories to complete with in a limited time frame. the day(s) remaining gives a quick relation of amount of work remaining and amount of day(s) remaining.
- Sprint Goal
During sprint planning, we achieve two outcome, 1 Sprint goal and 2. Sprint Backlog. from the sprint backlog we will populate the scrum board with story card and task card, as executable action item. Having the goal visible will remind why we are doing it, and far the team is, to achieve the goal.
- Burn down chart
Burn down chart is an important artifact of scrum, which represents the trend of amount of work remaining since the first day of the sprint, with compared with an ideal trend. It helps the team they are progressing in a sustainable pace or too slow or too aggressive. This can be draw using white board marker, or a print out can be pasted.
- Definition of Done
The Done column is usually the last column of the board. each agile team define the checklist to mark a story is 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 with in 15 minutes. we may encounter a discussion point that may take longer. Its a good practice to park those 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 white board marker.
A sample Task board with the above mentioned content area is attached below.
Note : preparing of these content area is only required for a physical board. These informative contents, charts etc are also available in your digital board. the location or accessibility of the contents varies from one ALM tool to another ALM tool
Now we have our Story board ready to place our action item in 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 in 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 gets 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.
Lets first try to understand what is Story Card and Task Card is.
Story cards are normally a rectangular area (close to a playing card or School book label), for 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 a digital board these cards generate digitally, how ever the lay out 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
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
Sample Story Cards from Jira
Sample Story Cards from Rally
Sample Story Cards from TFS
Lets try to understand about the task card. its looks like same as story card, as stories are parents of tasks similarly story cards are also parents of task card. Where story cards contain the content at little higher level, mainly the requirement, acceptance criteria etc. the task cards contain the executable level action items. The contents of a task cards are typically are as below.
- Parent Story (Id / Name)
- Task ID
- Task Name (e.g. Analysis, Development, code review, Test Case creation, Test case execution etc)
- Assigned to
- Estimated effort hours
- Remaining effort hours
These task cards 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 stories in sprint backlog.
In case the team don’t use a ALM tool, and work 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 a sample of task cards created from Excel. and few task cards from different ALM tool 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 have prepared your cards for your board. Its time to place the card in board. ALM tool till 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. Then cut the cards and place in your board.
I have attached few sample board diagram below, after the story cards and task cards are placed.
Note : In the below diagram the story cards or task cards are in different column. When you will start the sprint all the cards will be at 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, Definition of Done, organized differently on different ALM tools, will cover them separately on the ALM video tutorial of 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 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 keep the cards up to date are
- Update the remaining hours on each board
With in ALM tool team members update the remaining hours against the tasks or stories every day (at least once a day). The ALM tool take care of rest of the calculation like Parent level total remaining hours, including all the sibling Tasks. update the burn down etc. In case of a Physical board, team members usually update the remaining hours during Daily scrum call, and update the burn down chart manually.
- Moving the cards from one column to another.
As and when the tasks and stories are getting executed its 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 work flow. In case of Physical board team members move the story card and task cards manually from current column to next column. We will learn more in details on 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 remaining time of the sprint and remaining efforts. Then the team may try to reassign the tasks to other member who have bandwidth available.
- Identify and Mark Impediments
Its Important to highlight a task or story’s block state, with its blocked reason. its will be a good practice to maintain the block age. A scrum team should highlight the story card or task card is currently blocked. Few ALM tools provide a straight forward mechanism to marked a story is blocked or impeded. In few other other ALM tool the scrum team create a mechanism to highlight blocked story card or impeded. If you are creating the mechanism, remember to maintain the states of the card. 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 , or small sticky notes (use for price tags) etc to highlight the task card as blocked. At the same time, at some place of your board , write down the Task id /story id with the blocked reason and blocked date, using board marker
Its a good practice to assign the blocker to some team member as primary responsible to resolve it. Scrum Master is primary responsible to resolve all impediments or blocker.
Discuss about the blocker everyday during your daily scrum call.
Its very easy in ALM tool, as in ALM tool the cards can be moved by drag and drop. Where in physical board, the team member moves the card manually from one column to another column
During end of the sprint you realize that most of the cards moved from left side to right most column.