Maximizing Efficiency with Scrum Boards
Scrum boards serve as the cornerstone for visualizing the progression of sprint backlog items within a workflow, offering unparalleled practicality and insight.
Embrace Boards Over Lists
It’s a common sight to find teams gravitating towards lists, citing their apparent convenience and comprehensive nature. Lists, they argue, contain all pertinent information in a succinct format. However, while lists indeed consolidate data effectively, grasping the holistic status of sprint items within a workflow is anything but straightforward. Our cognitive faculties grapple with translating a linear list into a cohesive workflow, navigating through overload and scarcity within the process, and comprehending the overarching progress. As the volume of backlog items grows, deciphering the overall status from a one-dimensional list becomes increasingly arduous. Conduct a brief experiment — compare a list view to a board view. Allocate a mere 5 seconds to each. Where did you absorb more information? Did you tally the items in each column? Note the completed tasks? Identify those pending? This is precisely why boards wield such potency — their visual representation is pivotal. This insight isn’t novel; it traces back to the foundations of the Toyota Production System, heralded by the use of Kanban boards long before the advent of the agile movement.
Build the Board
Map Workflow Steps into Columns
When establishing the structure of your board, the initial step involves defining your workflow steps, which outline your delivery pipeline. Once your workflow is defined, the subsequent task is to align each step with the corresponding column. The leftmost column signifies the starting point — work committed to the sprint but not yet initiated by the team. On the opposite end, the rightmost column encompasses workflow states classified as ‘Done’. While different teams may employ the same workflow, they may utilize varying column setups (except for the rightmost column, which should maintain uniformity across teams to ensure a cohesive ‘Done’ state).
Optimize Column Counts
Every organization tailors its workflow, describing steps through various statuses like New, Design, Ready For Dev, and more. However, the richness of statuses in the workflow needn’t translate to a flood of columns on the board. Several workflow statuses can (and should) be combined into a single column on the board, fostering clarity and efficiency in the process.
Consider the following workflow: New, Design, Ready For Dev, Dev In Progress, Dev Verification, Ready For Testing, Test In Progress, Ready To Deploy, Post Deploy Testing, Done. Building a Scrum board with 10 columns to represent each status is undoubtedly excessive. Instead, we can consolidate these statuses into 4 columns: ToDo, Dev In Progress, Test In Progress, and Done. Fewer columns streamline board management and enhance comprehension of the overall sprint status. While a flood of columns may offer a sense of control, it often leads to confusion and turns techniques like WIP limits ineffective (read more here), as each column represents only a fraction of the workflow.
Sub-tasks vs. Columns
Some teams attempt to mirror workflow steps using sub-tasks under backlog items, such as creating sub-tasks for design, development, and testing. However, this approach compromises workflow visualization and overflows the board with excessive tickets. For instance, with 20 backlog items, creating 60 additional sub-tasks (3 sub-tasks per ticket — design, develop, test) results in a total of 80 items on the board, overwhelming and unmanageable. Hence, it’s essential not to represent workflow steps as sub-tasks under backlog items.
Note About Workflow Steps
Certain activities within the development pipeline may not constitute deterministic steps in the workflow. For instance, “Blocked” serves as an indication as part of a workflow step rather than a state itself (read more about the Blocked column here). Another example is when activities like code review can occur before or after testing. In that case, code review should not be treated as a workflow step. Instead, code review should be indicated atop the workflow using integration between backlog management tools like Jira and source control tools like BitBucket.
Representing All Backlog Item Types
A robust Scrum board should accommodate various backlog item types, such as stories, tasks, and bugs, by mapping their workflows to a unified set of columns on the board.
Pre-Sprint Workflow Steps
Oftentimes, a backlog item undergoes several preliminary stages before it’s ready for execution. The product owner initiates comprehensive business research, carefully defines the backlog item, refines its details, and so forth. These early stages are often represented by workflow steps, such as ‘New’, ‘Design’, and ‘Ready For Dev’, marking the preliminary journey of an item pre-sprint. The challenge arises in how to effectively enable the product owner to track these stages and how these stages are seamlessly integrated into the Scrum board.
To address this, the product owner can employ a Kanban board for managing the early stages of the workflow. Within this Kanban framework, columns such as ‘ToDo’, ‘Designing’, and ‘Ready For Execution’ can be utilized. The ‘ToDo’ column encompasses the initial ‘New’ state, while ‘Designing’ corresponds to the subsequent ‘Design’ phase. The final column, ‘Ready for Execution’, combines all remaining steps, serving as the rightmost column on the Kanban board.
Meanwhile, on the Scrum board, the leftmost column includes the ‘New’, ‘Design’, and ‘Ready For Dev’ states. Here, the journey of the backlog item starts for the Scrum team once it is pulled into the sprint, marking the handover from the product owner to the development team.
The rationale behind incorporating steps preceding ‘Ready For Dev’ into the Scrum board may prompt inquiry, but the reasoning is clear-cut. While it’s usual for teams to exclusively include backlog items in ‘Ready For Dev’ states into the sprint, exceptions do exist. Take, for instance, a scenario where an urgent item necessitates immediate attention, despite not being fully prepared. By accommodating these pre-development stages on the Scrum board, teams uphold flexibility to address such exceptions seamlessly.
Post-Sprint Workflow Steps
There are instances where workflow steps extend beyond the traditional ‘Done’ status, particularly from the development team’s perspective. Consider a scenario where a backlog item has been successfully deployed to production but necessitates subsequent testing on the live system, termed ‘Post Deploy Testing’. In such cases, it’s essential to accommodate these ‘post-done’ workflow steps on the rightmost column of the Scrum board.
A pragmatic approach to tracking these steps involves leveraging a Kanban board. Here, the leftmost column of the Kanban board can be designated for backlog items in the ‘Post Deploy Testing’ step. As progress unfolds and testing is completed, these items transition smoothly toward the rightmost column of the Kanban board, symbolizing the conclusion of testing on the production system.
This setup not only provides clarity regarding the status of each backlog item but also ensures a structured approach to managing post-deployment tasks. By integrating Kanban principles into the Scrum workflow, teams can effectively navigate these additional steps while maintaining visibility and cohesion across the development lifecycle.
Use the Board
Board Review Approach
In the review of boards, use a method that moves from right to left (from the ‘Done’ column backward). This strategic approach streamlines the identification of delivery opportunities by concentrating on tasks nearest to completion. Moreover, it effectively targets and resolves bottlenecks systematically, beginning from the right and progressing towards the left.
Workflow Moves Forwards (Only)
To maintain workflow integrity, it’s advisable to advance items only forward within the workflow (left to right), avoiding backward movement. Reverting backlog items to previous workflow steps disrupts workflow visibility and damages opportunities for expedited delivery (as we are losing visibility on backlog items that were advanced in the workflow).
Sequential Workflow Doesn’t Prevent Parallel Work
The linear nature of a workflow, with its predetermined sequence, doesn’t restrict our ability to prepare for subsequent stages while still in the early ones. Take testing, for instance: while coding is underway, test scenario development can proceed concurrently. Enhanced board visibility aids teams in recognizing opportunities for efficient parallel work. In our scenario, once a tester observes that an item is being coded, they can immediately commence constructing the necessary test scenarios.
Identify Starvations and Bottlenecks
Regularly observe the flow of backlog items across the board. Look for areas where items are lingering longer than expected or where there’s a shortage of items in certain stages.
Starvation occurs when certain board columns consistently have fewer items than others, potentially leading to underutilization of resources or skills. Monitor board columns where items are too few and investigate the reasons behind the imbalance.
Bottlenecks are points in the workflow where tasks accumulate, causing delays in overall progress. Keep an eye on board columns where items tend to pile up, indicating potential bottlenecks.
Once you’ve identified areas of starvation or bottlenecks, get into the underlying causes. It could be due to resource constraints, dependencies, inefficient processes, or other factors.
Collaborate with the team to brainstorm and implement solutions to prevent starvation and resolve bottlenecks. This might involve redistributing items, optimizing processes, addressing dependencies, or allocating additional resources.
Use the insights gained from monitoring the scrum board to continuously refine and enhance your workflow. Regularly revisit and adjust your processes to maintain a smooth and efficient flow of work.
Set WIP Limits for Columns
Using Work-in-Progress (WIP) limits in Scrum boards helps teams maintain a smooth and efficient flow of work. Assign WIP limits to relevant columns on your Scrum board. It’s common to set WIP limits for columns like In Progress and Testing to control the number of tasks being actively worked on and tested. Determine the appropriate WIP limit based on the team’s capacity and the flow of work.
In each of the board columns, I recommend setting an initial WIP limit number that is twice the size of the people involved in that stage. For example, if we have 4 developers and 3 testers on the team, the In Progress column will be set with a WIP limit of 8 and the Testing column will be set WIP limit of 6. Regularly review and adjust (usually reduce) WIP limits based on the team’s experience and performance. If the team consistently doesn’t hit the WIP limits, consider reducing WIP limits to optimize flow.
Leverage the Board
The Scrum board serves as the central hub where task data is recorded and updated throughout the sprint. This data is then used to generate agile graphs such as sprint burndown, control chart of cycle time, and velocity graphs, which offer valuable insights into the team’s progress, efficiency, and productivity.
Sprint Burndown Chart
The Scrum board displays all the items planned for the sprint. As the sprint progresses, team members update the status of items on the Scrum board, moving them through different stages of completion. By regularly updating item statuses, the Scrum board provides real-time data on the remaining work for the sprint.
The sprint burndown chart is generated based on this data, plotting the remaining effort against the total planned effort. It visually illustrates whether the team is on track to complete all planned efforts by the end of the sprint.
Control Chart of Cycle Time
The Scrum board captures the start and end times of each item as it moves through the workflow stages. These timestamps provide valuable data on the cycle time (the duration taken to complete an item from start to finish) for each item. Using this data, a control chart of cycle time can be generated, plotting the cycle time of items over multiple sprints.
This chart helps in identifying trends and variations in cycle time, enabling the team to make informed decisions to improve efficiency and predictability.
Velocity Graph
The Scrum board records the effort of items completed by the team in each sprint. At the end of each sprint, the total number of completed tasks or story points is calculated. This data is used to generate a velocity graph, which depicts the team’s productivity over time by plotting the completed effort for each sprint.
Velocity is a key metric in Agile development, providing insights into the team’s capacity and helping in sprint planning and forecasting.
Conclusion
In essence, maximizing efficiency with Scrum boards isn’t merely about adopting a tool, but rather a strategic mindset that optimizes workflow management, fosters collaboration, and enhances productivity across teams. By embracing boards over lists, we lay the foundation for transparency, visualization, and adaptability within the Agile framework.
Constructing a board involves more than just mapping workflow steps into columns. It’s an intentional process of streamlining, optimizing column counts, and avoiding the complexity of sub-tasks. Integrating pre-sprint and post-sprint workflow steps into Scrum and Kanban boards ensures a holistic view of the development lifecycle, allowing teams to seamlessly transition from planning to execution and beyond.
Using the board effectively entails more than just moving items from left to right; it’s about creating a culture of continuous improvement. Reviewing the board from right to left, identifying starvations and bottlenecks, and setting WIP limits for columns are essential practices that drive efficiency and mitigate workflow constraints.
Moreover, the power of the Scrum board extends beyond task management; it serves as a driving board for data-driven insights and actionable metrics. Leveraging the board to generate graphs such as sprint burndown, cycle time, and velocity empowers teams to get invaluable insights into performance trends, identify areas for improvement, and optimize their processes iteratively.
By exploiting the full potential of Scrum boards, teams can navigate complexity with clarity, unlock productivity gains, and ultimately deliver value with precision and agility.
