Kanban Practices
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
Definition of Workflow
The four Kanban practices are enabled by the Scrum Team’s Definition of Workflow. This definition represents the Scrum Team members’ explicit understanding of what their policies are for following the Kanban practices. This shared understanding improves transparency and enables self-management.
Note that the scope of the Definition of Workflow may span beyond the Sprint and the Sprint Backlog. For instance, a Scrum Team's Definition of Workflow may encompass flow inside and/or outside of the Sprint.
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 of the Workflow – the Kanban Board
Visualization using the Kanban board is the way the Scrum Team makes its Workflow transparent. The board's configuration should prompt the right conversations at the right time and proactively suggest opportunities for improvement.
Visualization should include the following:
- 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 (stakeholder value, knowledge value, process improvement value) that are flowing through the Scrum Team's system (most likely Product Backlog items (PBIs)).
- A definition of the workflow states that the work items flow through from start to finish (of which there must be at least one active state).
- 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).
Limiting Work in Progress (WIP)
Work in Progress (WIP) refers to the 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. A Scrum Team can explicitly limit WIP however they see fit but should stick to that limit once established.
The primary effect of limiting WIP is that it creates a pull system. It is called a pull system because the team starts work (i.e. pulls) on an item only when it is clear that it has the capacity to do so. When the WIP drops below the defined limit, that is the signal to start new work. Note this is different from a push system, which demands that work starts on an item whenever it is requested.
Limiting WIP helps flow and improves the Scrum Team's self-management, focus, commitment, and collaboration.
Active Management of Work Items in Progress
Limiting WIP is necessary to achieve flow, but it alone is not sufficient. The third practice to establish flow is the active management of work items in progress. Within the Sprint, this management by the Scrum Team can take several forms, including but not limited to the following:
- 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 (See Service Level Expectation - SLE).
Service Level Expectation (SLE)
A 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. The Scrum Team uses its SLE to find active flow issues and to inspect and adapt in cases of falling below those expectations.
The 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). The SLE should be based on the Scrum Team's historical Cycle Time, and once calculated, 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.
Inspect and Adapt the Definition of Workflow
The Scrum Team uses the existing Scrum events to inspect and adapt its Definition of Workflow, thereby helping to improve empiricism and optimizing the value the Scrum Team delivers.
The following are aspects of the Definition of Workflow the Scrum Team might adopt:
- Visualization policies - for example, Workflow states - either changing the actual Workflow or bringing more transparency to an area in which the team wants to inspect and adapt.
- How-we-work policies - these can directly address an impediment. For example, adjusting WIP limits and SLEs or changing the batch size (how often items are pulled between states) can have a dramatic impact.
Tiếng Việt