What does the Kanban Guide for Scrum Teams (at https://www.scrum.org/resources/kanban-guide-scrum-teams) say about work in progress limits?
"Kanban (n): a strategy for optimizing the flow of stakeholder value through a process that uses a visual, work-in-progress limited pull system.
..... Optimizing flow requires defining what flow means in a Scrum context. Each Scrum Team must create its definition of "Workflow" containing the following elements:
....... workflow must contain a definition of how Work in Progress (WIP) will be limited.
......Limiting 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 control these in-progress work items from the time they consider them "started" until the time they consider them "finished." That control is usually represented as a number or numbers on a Kanban board. Those numbers are called "WIP Limits." A WIP Limit can include work items in a single column, several grouped columns, or a whole board. Once the Scrum Team has established a WIP Limit, it refrains from pulling more than that number of work items into a given part of the workflow. The Scrum Team controls what the limits are and how it will apply them. The primary side effect of limiting WIP is that it creates a "pull system." It is called a pull system because the Scrum Team starts work on an item (i.e. pulls) only when there is a clear signal that it is time to do so (note this is different from a "push" system, which demands that work start on an item whenever it is requested). When the WIP drops below a defined limit, that is the signal to start new work.
The Sprint is itself a form of limiting WIP. By definition, a Sprint is a way of controlling how much work a Development Team is going to attempt during a specified period. Work is only pulled into a Sprint Backlog when the Development Team chooses to do so (usually, but not always, during Sprint Planning). Whether intended or not, Scrum has embraced this fundamental practice of flow from its beginning. Kanban's more granular and explicit WIP Limit not only helps workflow but can improve the Scrum Team's focus, commitment, and collaboration even further".
You might be not so advanced with your Scrum with Kanban. Perhaps, you only visualize your work and your team doesn't bother with
The four basic metrics of flow that Scrum Teams using Kanban will need to track are as follows:
• Work in Progress (WIP): The number of work items started but not finished (according to the Scrum Team's definition of "Workflow" in The Kanban Guide for Scrum Teams).
• 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 elapsed time between when a work item "started" and the current time.
• Throughput: The number of work items "finished" per unit of time. Note the measurement of throughput is the exact count of work items.
Calculating cycle times and work item age requires the Scrum Team to (at a minimum) track the start date and finished date of each item. All the graphs in this post were made possible simply by collecting start & end dates.
These metrics should be monitored throughout the Sprint – specifically in the Scrum Events (see the Flow-Based Events section below). As always, there are other flow metrics that the Scrum Team may want to examine, but these are the minimum requirement.
Whilst the Sprint itself limits WiP, the addition of
Little's Law, when stated in terms of departures instead of arrivals, requires some assumptions (see Daniel Vacanti's video at https://vimeo.com/52683659).
In this video (which I cannot recommend highly enough along with his Titanic video at https://vimeo.com/239539858), Daniel refers to Little's Flaw, that is assuming Little's Law will work when the underlying assumptions to make it work are not satisfied. The primary assumption to my mind is not allowing ageing of work in progress. That is, once it starts you should aim to finish the item as soon as possible without ageing more than other items in progress.
Teams eliminated Little's Flaw by having explicit policies in their workflow including watching/preventing the ageing of work in progress. These "Little's Flaw killer-policies" allowed Little's Law came fully into effect. Our teams became much more predictable, even with very complicated work, with dependencies, and (shock horror:)) ordering features with
I used Mike Burrows'
There were about 90 advanced
I had a team once who removed the
Some teams understood that a really frugal Product Owner can appear to avoid the need for teams to have the discipline to limit their own
- The Development Team is not self-managing in that it is not selecting work in consultation with the Product Owner, to support the Sprint Goal negotiated between the Product Owner and the Development Team. That is the Product Owner is acting more like Project Manager 2.0, and there is no project manager role in Scrum.
- It is more like just-in-time replenishment to the extent that the Development Team might have come up with a
better suggestedorder of PBIs for the Product Owner, particularly in a multiple teams Scrum scenario. Refer to Barry Overeem's post Myth 5 - In Scrum, the Product Backlog is prioritized (http://www.barryovereem.com/myth-5-in-scrum-the-product-backlog-is-prioritized/). The Development Team's ability to decide how to do the work where there are dependencies, or the need to acquire more knowledge/skills first, is impeded somewhat.
In post 2 of this 3 part series, we'll cover PSK with complicated work and complex work. In post 3 of 3, we'll talk about Toyota Improvement & Coaching Kata for flow-based retrospectives.
Meanwhile, check out Daniel Vacanti's case study for Kanban at Siemens Health Services at https://www.infoq.com/articles/kanban-siemens-health-services, where reduction of
You will miss a trick if you do not optimize to flow of work via
Another tradeoff example that Andy Carmichael gave me is when a system is overburdened reducing WIP increases throughput (by reducing overhead tasks and failure demand) and reduces cycle time. When a system is underutilized reducing WIP will *reduce* throughput but have no effect on cycle time. In between, there's a choice to keep cycle time low by reducing
Visualize your work for sure, but go the extra mile to optimize the flow of value. It leads to a calmer and most sustainable work environment, and I'd be surprised if it doesn't improve quality. Don't under-estimate Professional Scrum with Kanban, it adds horsepower to your Professional Scrum.
Get an advantage on the competition internally and externally. See https://www.scrum.org/courses/professional-scrum-with-kanban-training for the Professional Scrum with Kanban training brochure and https://www.scrum.org/classes?type=133&scrumorg_geocoder_postal_state=1 for listed classes.