my highlights from the Kanban Guide for Scrum Teams

how it was made

I've read the Kanban Guide for Scrum Teams on my tablet using the Moon+ Reader Pro. While reading, I've highlighted parts of text that I've found important. Then I've exported those highlights as a text document and pasted it into a Hypothesis page note here. So, here you'll basically find the quotes from the Guide without any comments. I strongly suggest reading the whole guide and annotating it yourself.

higlights

01-2021 Kanban Guide.pdf (Highlight: 66; Note: 0)

───────────────

▪ This guide does not replace or discount any part of The Scrum Guide. It is designed to enhance and expand the practices of Scrum.

▪ Kanban (n): a strategy for optimizing the flow of value through a process that uses a visual, work-in-progress limited pull system.

▪ Flow is the movement of value throughout the product development system

▪ frequency of the transparency, inspection, and adaptation cycle - which we can also describe as the Cycle Time through the feedback loop.

▪ they provide a focus on improving the flow through the feedback loop

▪ Work in Progress (WIP)

▪ work items started but not finished

▪ Cycle Time: The amount of elapsed time between when a work item starts and when a work item finishes

▪ Work Item Age: The amount of time between when a work item started and the current time. This applies only to items that are still in progress.

▪ Throughput: The number of work items finished per unit of time.

▪ Little’s Law,

▪ Little’s Law reveals that in general, for a given process with a given throughput, the more things that you work on at any given time (on average), the longer it is going to take to finish those things (on average).

▪ Most of the other elements of Kanban are built upon the relationship between WIP and Cycle Time

▪ flow theory relies on empiricism by using flow metrics and data to gain transparency into historical flow and then using that data to inform flow inspection and adaptation experiments.

▪ Scrum Teams can achieve flow optimization by using the following four practices: · Visualization of the Workflow · Limiting Work in Progress (WIP) · Active management of work items in progress · Inspecting and adapting the team’s Definition of Workflow

▪ Kanban practices are enabled by the Scrum Team’s Definition of Workflow

▪ Scrum Team members’ explicit understanding of what their policies are for following the Kanban practices

▪ shared understanding improves transparency and enables self-management

▪ the scope of the Definition of Workflow may span beyond the Sprint and the Sprint Backlog

▪ Creating and adapting the Definition of Workflow is the accountability of the relevant roles on the Scrum Team as described in the Scrum Guide. No one outside of the Scrum Team should tell the Scrum Team how to define their Workflow.

▪ Visualization using the Kanban board is the way the Scrum Team makes its Workflow transparent.

▪ Defined points at which the Scrum Team considers work to have started and to have finished.

▪ A definition of the work items - the individual units of value

▪ flowing through the Scrum Team's system (most likely Product Backlog items (PBIs))

▪ definition of the workflow states that the work items flow through from start to finish

▪ Explicit policies about how work flows through each state (which may include items from a Scrum Team's Definition of Done and pull policies between stages).

▪ Policies for limiting Work in Progress (WIP).

▪ work items the Scrum Team has started but has not yet finished

▪ Scrum Teams using Kanban must explicitly limit the number of these work items in progress.

▪ an explicitly limit WIP however they see fit but should stick to that limit once established.

▪ primary effect of limiting WIP is that it creates a pull system.

▪ the team starts work (i.e. pulls) on an item only when it is clear that it has the capacity to do so.

▪ WIP drops below the defined limit, that is the signal to start new work

▪ different from a push system, which demands that work starts on an item whenever it is requested.

▪ Making sure that work items are only pulled into the Workflow at about the same rate that they leave the Workflow.

▪ Ensuring work items aren't left to age unnecessarily.

▪ Responding quickly to blocked or queued work items as well those that are exceeding the team’s expected Cycle Time levels

▪ service level expectation (SLE) forecasts how long it should take a given item to flow from start to finish within the Scrum Team’s Workflow

▪ uses its SLE to find active flow issues and to inspect and adapt in cases of falling below those expectations.

▪ SLE itself has two parts: a range of elapsed days and a probability associated with that period (e.g., 85% of work items should be finished in eight days or less)

▪ based on the Scrum Team's historical Cycle Time

▪ the Scrum Team should make it transparent

▪ If no historical Cycle Time data exists, the Scrum Team should make its best guess and then inspect and adapt once there is enough historical data to do a proper SLE calculation.

▪ The Scrum Team uses the existing Scrum events to inspect and adapt its Definition of Workflow

▪ aspects of the Definition of Workflow the Scrum Team might adopt

▪ Visualization policies

▪ How-we-work policies -

▪ Kanban in a Scrum context does not require any additional events to those outlined in The Scrum Guide.

▪ Sprint and its events provide opportunities for inspection and adaptation of both product and process.

▪ misconception that teams can only deliver value once per Sprint. In fact, they must deliver value at least once per Sprint.

▪ Scrum Teams rely on the Sprint Goal and close collaboration within the Scrum Team to optimize the value delivered in the Sprint

▪ flow-based Sprint Planning meeting uses flow metrics as an aid for developing the Sprint Backlog. Reviewing historical throughput can help a Scrum Team understand their capacity for the next Sprint

▪ flow-based Daily Scrum focuses the Developers on doing everything they can to maintain consistent flow. While the goal of the Daily Scrum remains the same as outlined in The Scrum Guide, the meeting itself takes place around the Kanban board and focuses on where flow is lacking and on what actions the Developers can take to get it back.

▪ What work items are blocked and what can be done to get them unblocked?

▪ What work is flowing slower than expected? What is the Work Item Age of each item in progress? What work items have violated or are about to violate their SLE and what can the Scrum Team do to get that work completed?

▪ Are there any factors not represented on the board that may impact our ability to complete work today?

▪ Have we learned anything new that might change what the Scrum Team has planned to work on next?

▪ Have we broken our WIP limit? And what can we do to ensure we can complete the work in progress?

▪ Inspecting Kanban flow metrics as part of the review can create opportunities for new conversations about monitoring progress towards the Product Goal.

▪ Reviewing Throughput can provide additional information when the Product Owner discusses likely delivery dates.

▪ A flow-based Sprint Retrospective adds the inspection of flow metrics and analytics to help determine what improvements the Scrum Team can make to its processes

▪ Scrum Team using Kanban also inspects and adapts the Definition of Workflow to optimize the flow in the next Sprint.

▪ Scrum Team should consider taking advantage of process inspection and adaptation opportunities as they emerge throughout the Sprint.

▪ changes made during the regular cadence provided by the Sprint Retrospective event will reduce complexity and improve focus, commitment and transparency.

▪ Kanban helps manage the flow of these feedback loops more explicitly and allows the Scrum Team to identify bottlenecks, constraints, and impediments to enable this faster, more continuous delivery of value

▪ The flow optimization practices of Kanban provide Scrum Teams with additional opportunities to inspect the right thing, at the right time, and then based on that inspection, adapt as needed. Kanban's hyperfocus on transparency, visualization, and flow maximizes feedback, empiricism, and ultimately the delivery of value.