Kanban, Scrum, and Flow-Based Work Management for Service Teams
Kanban, Scrum, and Flow-Based Work Management for Service Teams
This domain tests whether you can choose between cadence-based and flow-based work management, and use flow arithmetic to justify decisions.
Kanban practice
Visualise the workflow, limit work in progress, manage flow, make policies explicit, implement feedback loops, improve collaboratively. WIP limits apply to columns and states, not to individuals - they exist to surface bottlenecks, not to ration effort. Explicit policies cover entry and exit criteria, classes of service (expedite, fixed date, standard, intangible) and how each is selected. Feedback loops are the board, the daily flow review, service delivery reviews and operations reviews.
Flow arithmetic
Little's Law: average cycle time = average WIP divided by average throughput. It is a rough planning rule, not a promise per item. Use the cumulative flow diagram to see WIP growth and band width, and read lead time as a distribution - report the 85th or 95th percentile, because the average hides what customers experience.
Scrum in a service context
Scrum provides three accountabilities (product owner, scrum master, developers), five events and three artifacts, with empiricism and a Definition of Done at its core. It suits product work with a stable team and a meaningful sprint goal. Flow-based work suits interrupt-driven service and support work with unpredictable arrival; Scrumban combines a pull board with a planning cadence.
Worked example
A team has 15 items in progress and completes 5 per week. Little's Law gives an average cycle time of 3 weeks. A stakeholder demands one-week delivery. Reasoning: raising throughput from 5 to 15 per week is implausible, so the lever is WIP - cut it to about 5 and the arithmetic yields roughly one week, provided the team stops starting new work before finishing. The board must enforce that, which is why the WIP limit has to be a policy the team owns.
Traps
Setting WIP limits per person; comparing velocity across teams; conflating lead time and cycle time by omitting the start point; abandoning WIP limits in a crisis without changing the policy explicitly; treating the cumulative flow diagram as a reporting decoration rather than a diagnostic.