Scrum with Kanban: How to Improve Your Sprints

Kert Peterson, Applied Frameworks, https://appliedframeworks.com/

Scrum and Kanban are not rivals. If your Sprints are getting bogged down or missing the mark, combining Scrum with Kanban might be the answer. We provide a comprehensive explanation of how Kanban can improve your process with Task Boards, Team Boards, and a better focus on customer needs.

Since arriving on the software development scene in 2005, Kanban has invigorated and clarified the work of Scrum teams worldwide, enhancing teamwork and facilitating flow of value in significant ways. Kanban has an undeniable place in managing workflow and value creation in three fundamental areas of a product or system's value stream:

1. Discovery - upstream of the product backlog as a means to visualize and evaluate options (candidate Product Backlog Items or PBIs) as they move through a vetting process.
2. Delivery - visualizing the workflow of the scrum development team as they take PBIs from ready (in Sprint Planning) and move them to a "done" state for the Sprint Review.
3. Deployment - tracking and visualizing the path of a work item or feature as it transitions from a state of "done" to release into the production environment and into use by customers.

This article explores the application of Kanban within a Sprint, i.e., Delivery cycle, with the intent of illuminating the ways teams can employ Kanban to improve value creation and more effectively deliver the Sprint Goal.

Applying Kanban within a Sprint

Few, if any, Scrum teams operate without some visual representation of how their work moves through the workflow in the course of a Sprint. A task board, populated with the development and creative tasks in one of three states - To Do, Doing, or Done - is the most basic and easily implemented means of visually tracking work.

The simple task board, while familiar and useful as a starting point, must be examined and evolved to foster shared ownership and sharpen the team's focus on value delivery - elements integral to high-performing Scrum Development Teams.

Visualizing work is the first and most basic of the six practices that comprise the Kanban Method as formulated by David J. Anderson. Let's take a closer look at the different ways to apply and evolve this first practice and discover how to optimize the remaining five practices in the context of Scrum.

Practice 1: Visualize Your Work

The Task Board

Scrum teams often generate tasks in sprint planning as part of decomposing PBIs and planning the work of the Sprint. A task is typically something like "design the wireframe," "code the class," "test the story," or "write training documentation," - granular activities undertaken by the Development Team to deliver a PBI that contributes to the Sprint Goal.

Tasks are often written on sticky notes or recorded in the digital equivalent with an electronic tool like Jira or VersionOne. As the work represented on the tasks is undertaken, it is represented and tracked on a physical or digital task board.

"Start with where you are now," the first change principle of the Kanban Method, asks that the visual model represents the way the team operates today. Embracing this principle can reveal interesting team dynamics and offer opportunities for the team to grow and mature.

For example, teams that pre-assign tasks in Sprint Planning may inadvertently thwart shared ownership and reduce swarming on tasks by the whole team. Some reflection questions for teams using task boards include:

• Are tasks pre-assigned in Sprint Planning or is emergent ownership encouraged?
• Do team members have interest in team activity beyond their own tasks?
• Is there a shared view of and interest in all tasks in progress for a given PBI?

As you might observe, the granularity of tasks and the simplicity of the board itself can discourage shared ownership and obscure a team's "bigger picture" view of value delivery.

Beyond the Task Board: The Team Board

While tasks may be interesting and useful to teams, they are irrelevant to the customer and the Product Owner. You can't deliver a task. As the unit of work represented on a higher-level board, a well-formed PBI or story represents the value that we want the team focused on delivering to customers and end-users.

Tracking the flow of the PBI on an appropriately designed team board can be a useful step towards encouraging shared ownership of a PBI and orienting the team towards customer value. Additionally, a team board can reveal teamwork-hindering behaviors, encourage new ways of self-organizing and invite adoption of the positive social patterns common to high-performing teams.

Adopting a team board will frequently drive re-examination of how PBIs are written. Vertical slicing becomes essential to forming work items that represent customer value and can exhibit meaningful movement across the board over the course of the Sprint. Smaller PBIs flow better and provide the desired level of insight and transparency into how the work is flowing through the development process during the Sprint. See, "User Stories: Making the Vertical Slice," for more.

In regard to the team board design and naming of columns, we don't tinker too much with how things should be working. Rather, we want the initial board to reflect how the PBIs actually move through the workflow and are processed by the team. Having a clear model that reflects how work items really move is the starting point for honest conversation and revealing dynamics that may limit the team's performance. Honesty is also the starting point for real conversation and an intrinsic improvement mindset.

As the team board is created and utilized throughout the sprint (and perhaps becoming central to the Daily Scrum), some questions can be useful in evolving the board:

• Do the columns on the board invite or restrict collaboration?
• Is there shared interest in PBIs as they move across the board?
• Do team members lose interest when a PBI exits "their" column?
• Are team members willing to engage in activities outside of their specialty?
• Do team members "cross the boundaries" of a column to help each other?

With attention and diligence, the team board can evolve to reflect an inclusive workflow that invites each team member's voice, ideas, and participation. Over time, team board columns may divide and grow more granular or they may combine and be more broad. What's important in these design choices is a focus on smoothing flow and encouraging collaboration.

Practice 2: Limit Work in Progress (WiP)

Scrum natively limits work-in-progress through Sprint Planning, an event in which the Development Team selects a small batch of work they believe can be accomplished within the Sprint. This batch of items, and the game plan for delivering the items, becomes the Sprint Backlog, an artifact that is owned and managed by the Development Team.

Development Teams that overcommit and consistently struggle to complete the PBIs in the Sprint Backlog will benefit from using work-in-progress limits within the Sprint on the team Kanban board. Teams that struggle with consistent completion could find themselves with a team board that looks similar to the one below.

In a situation like this, WIP limits on the appropriate columns will introduce a constraint that will encourage shared ownership and a focus on finishing, resulting in healthier workflow throughout the Sprint. For example, with the team board depicted above, we might introduce WIP limits within each column or queue across the board to limit the amount of work in a given stage:

With the new board, as depicted above, no new work can be started, i.e., "pulled" into Design from Selected, until at least one item is moved out of the Design stage, thus creating an opening or visual signal (literally, a "kanban") that Design is ready for another work item.

Imposing these artificial constraints onto the team's board quickly reveals bottlenecks (spots where work builds up waiting to be worked on) and encourages team swarming to clear the bottlenecks and get work items completed to a state of "Done."

Practice 3: Manage Flow

Flow can be thought of as the rate at which work items (PBIs or tasks) move through the Development Team's process, culminating in a state of "done" and presented in the Sprint Review to stakeholders for feedback. When they remove impediments, ScrumMasters are managing the flow of work by eliminating those local or systemic issues that thwart the work item's completion.

In addition to WiP limits as a means to induce better flow within a sprint, Kanban offers some other mechanisms to encourage or smooth flow:

• Split Columns - "Doing" and "Done" sub-columns provide more visibility into an item's state and thus enable the team to better see bottlenecks and how to keep the items moving through the process.
• Blocker Visualization - blocked cards (PBIs or tasks) can be flagged as blocked with a color change or additional sticky affixed to the front, keeping the issue in front of the team until its addressed.
• Expedite Lane - having a swim lane for urgent unplanned work, and tracking those requests in a disciplined manner, can surface patterns and enable the team to address issues more systematically.
• Cycle Time - tracking the total elapsed time between when a given PBI starts and when it is finished ("Done") can provide a means to measure and improve market and/or customer responsiveness
• Work Item Type - categorizing work items by work item type gives the team increased visibility into where time is being invested, enabling the team to better make adjustments as they work to deliver the Sprint Goal

Practice 4: Make Process Policies Explicit

Scrum teams who have created and are adhering to a "Definition of Done" are already familiar with the notion of making process policies explicit. Process policies are simply a written or formal agreement within the team that governs how and when work items move across the kanban board. A Scrum team that is fully embracing this kanban practice might have policies that specify when a work item can exit or enter a given column.

For example, "acceptance tests written" might be a policy determining what it means for a PBI to be "Done" with Analysis and ready to move into the Design stage of work. Driven by a team's need to clarify and collaborate, the intent of policies is to bring shared understanding and increased alignment, both of which should ultimately contribute to flow. Some ideas on where process policies could be applied include:

• How to address unplanned work item requests
• Clarify and enable smooth hand-offs between roles or functions
• What constitutes a block or impediment and how to represent on the board
• Handling of critical requests within a Sprint
• Where and how to align with enterprise architecture or other organizational needs

If policies are not being utilized or updated as they're applied, or if they start feeling oppressive or overly bureaucratic, the team will want to examine and perhaps drop them. As with any agile process, the Scrum Team must own and evolve the process.

Practice 5: Implement Feedback Loops

In Scrum, the Review and Retrospective are the primary feedback loops for evolving the product and the team process respectively. The Daily Scrum is the 24-hour feedback loop for the development team to inspect and adapt the Sprint Backlog and plan the subsequent 24-hour cycle of work.

Like Scrum, Kanban feedback loops - called cadences - aim to provide information and context to plan daily work and to evolve the product/system and process to meet the needs of the market or customer. These cadences are also key to evolving the board, the workflow and process policies represented through the board.

Kanban Cadence	Purpose	Activities	Comparable Scrum Event
Daily Kanban	Keep work moving, reduce delay.	Team members coordinate, observe, and manage workflow, typically by examining the Kanban board from Right to Left.	Daily Scrum (but no emphasis on a Sprint Goal since Kanban is not leveraging iterations)
Replenishment Meeting	Determine what to do next.	Move work items from ideas or options into the "ready" column of the Kanban board, and oversee the preparation of options for selection in the future.	Akin to Sprint Planning in terms of commitment to complete work, but includes aspects of product backlog refinement as well
Service Delivery Review	Ensure software is fit-for-purpose of customers It is the Kanban way of doing retrospectives and is focused on checking the team's performance against commitments, customer-focused metrics, quality, lead time, classes of services, etc.	Examine and improve the effectiveness of a service by checking the team's performance against commitments, customer-focused metrics, quality, lead time.	Akin to Sprint Review, but with elements of a retrospective and an added focus on customer needs, context, and use/impact of the work items delivered

3 of the 7 Kanban Cadences

Of the 3 Kanban Cadences offered here, the Service Delivery review points to some areas of feedback that might be considered in the Sprint Review, including:

• Is the product achieving the desired outcome? (Is the product fit for purpose?)
• Are customer needs being understood and met?
• Work-type mix (% allocation to work item types)
• Customer satisfaction with regard to product delivery
• Responsiveness (cycle time) to customer and market needs

The Service Delivery Review focuses not just on the product delivered, but on the broader context within which the product is being consumed and applied.

Practice 6: Improve Collaboratively, Evolve Experimentally

In Scrum, the Sprint Retrospective creates a Kaizen mindset of continuous improvement. The last event of every Sprint, the output of a Retrospective, is typically a kaizen event (or work item) that will often be placed in the Sprint Backlog of the subsequent sprint. In Kanban, the Service Delivery Review provides the context, the information and the impetus to fuel internal improvements. What's common to both Scrum and Kanban is the need to challenge assumptions and design the right experiment to drive change.

Conclusion

More siblings or cousins than the rivals that many make them out to be, Kanban and Scrum both aim for sustainable delivery of high quality products and services in the shortest possible time frame. Kanban's methods to visualize and manage workflow can bring clarity and better team collaboration within the Sprint. The increased emphasis on customers and their needs offered by Kanban can assist Scrum teams in aligning their product to the needs of the market and customers. Understanding these Kanban methods will allow you to leverage Kanban to significantly improve your Sprints.

More About Improving Scrum with Kanban...

I, together with Laura Richardson, Applied Frameworks SVP, recently produced and recorded this webinar, on YouTube "Improve Scrum with Kanban." Wherein we explored the above topics, and more, in a 45 minute webinar.

This article was originally published on https://appliedframeworks.com/scrum-with-kanban-how-to-improve-your-sprints/ and is republished here with permission from Applied Frameworks.

---

Related Kanban and Scrum articles

Kanban for Skeptics

Making Your Culture Work with Agile, Kanban & Software Craftsmanship

Open Source Kanban Tools

More Agile and Lean Knowledge

Scrum Expert

Project Management Planet

---

Click here to view the complete list of Methods & Tools articles

This article was published in October 2020