LEARN. PRACTICE. GROW.Start with the decision
The sponsor of a fictional fund platform wants to know whether the team can accept more integrations. The report answers with a two-day mean calculated from the last two completed requests. Meanwhile, two requests have been open for nine and seven days. Before accepting more work, the Scrum Master helps the team expose this information. The purpose is to understand what prevents completion and what capacity exists for new commitments. On the exercise board, record each request’s start instant, current state, completion instant when available, and blocking reason. Retain the same start criterion across periods. An open request does not yet have a final duration; its age remains useful evidence for investigation.
Work through the sample
Use five fictional completion times: 2, 2, 3, 3, and 20 days. Their sum is 30, mean six, and median three. Neither measure promises that the next request will finish in three or six days. Investigate the twenty-day request and its distinguishing conditions before excluding it. Then compare two periods of 100 requests. Initially, 80 simple requests take two days and 20 complex requests take ten; later, the counts reverse while class-specific times stay constant. Aggregate means are 3.6 and 8.4 days. The increase reflects the supplied mix without deterioration within either class. Aggregate experience did change and should remain visible. The useful discussion concerns complex demand, constraints, and the capacity required.
Propose an executable experiment
In the fictional team, requests often return to their submitters because recovery evidence is missing. The hypothesis is that a clearer form reduces those returns. Before making it mandatory, define a two-team, two-week experiment with an owner and reserved time. Record which requests are eligible, how a return is counted, and how much effort preparation and review require. Agree a stop criterion if the form obstructs urgent response or introduces prohibited information. At the end, compare outcomes and gather concrete examples of difficulties. If request types also changed, show that change. An incident decrease from six to two alongside a release decrease from twenty to four does not itself establish causal benefit. The next decision may be adjustment, conditional expansion, or stopping.
Separate measures and retain context
In a fictional trial, 1,000 eligible requests attempt reconciliation. One hundred fail before reaching the backend; of the remaining 900, 891 complete correctly. The exercise’s defined end-to-end success rate is 89.1%, although the backend alone reports 99%. State which decision each measure supports before presenting it to the committee. During an incident, the board also needs to reflect actual work. If the limit is four and four items are already active, record the authorized exception and discuss displaced work. Do not wait for a scheduled event to apply the response procedure. The local laboratory checks only arithmetic over synthetic data. It measures no organization, validates no causal relationship, and does not reproduce the official six-step problem-solving workshop, which still requires authorized source material.
completed_days = [2, 2, 3, 3, 20]
mean = 30 / 5 # 6
median = 3
before = (80 * 2 + 20 * 10) / 100 # 3.6
after = (20 * 2 + 80 * 10) / 100 # 8.4
end_to_end = 891 / 1000 # 0.891Requests open for nine and seven days remain relevant even when the two most recent completions took only two days.
Common pitfalls
Changing clock boundaries; excluding difficult cases without evidence; confusing backend rate with complete outcomes; inferring causality from a short comparison.
Related topics: Flow and capacity · Inspect and Adapt: coverage limits
A measure helps when its scope is clear and the team can use it to decide and follow up on an action.
Reference: The Kanban Guide May 2025 · AI-Empowered SSM; official exam guide August 11 2026