Bound the evidence window
5 min · Keep release evidence decision-ready
Historical delivery data becomes decision evidence only when its observation window and context are visible.
Reading
coreWrite the evidence label before the rate
A delivery rate is meaningful only with a counting rule. Record the start and end dates, number of observations, definition of finished, team composition, work type and any exceptional event. Then ask whether that history resembles the decision ahead.
The Kanban Guide defines throughput as work items finished per unit of time. It also defines a service level expectation as an elapsed-time forecast with a probability, based on historical cycle time or initially a best guess. Neither definition makes one team’s numbers portable to another team.
Consider nine fortnightly observations from one web team. The next release uses the same team but introduces mobile-store review and a new security approval. The nine observations remain factual, yet the changed path to finished weakens their relevance. Keep the data, annotate the context change and avoid presenting its old range as unchanged evidence.
An average hides spread, but standard deviation is not an automatic remedy. NIST identifies approximately 95.45% within two standard deviations as a property of a normal population and separately explains that future-observation prediction intervals require a suitable model and assumptions. Nine observations do not establish normality, independence or calibrated future coverage. Use a method whose assumptions can be explained. If the sample is only a starting guess, label it that way.
Failure mode: the dashboard silently changes what counts as done. A rate can improve merely because client acceptance moved outside the measurement boundary. Freeze the definition with each forecast version.
Worked example and transfer practice
All examples below are fictional teaching material. Use synthetic notes; no workplace or personal data is required or uploaded.
Inspect a counting boundary. Synthetic fortnightly throughput is 6, 8, 7, 9 and 5 accepted items. These counts describe five periods; they establish neither a normal distribution nor calibrated future coverage. If the next period adds an independent security acceptance step, retain the facts but qualify their relevance. Do not silently pool code-ready and production-accepted observations.
Try before reading the guide: Write an evidence label with the five observations, time unit, definition of finished, work type and changed condition. State one reason that a historical average could mislead this decision.
Practice review guide
A defensible label keeps the counting rule and context visible. The average is 7 items per fortnight, but that alone says neither when each item will finish nor the probability of meeting a release date.
Knowledge check
corePractice · formative check
Test the observation window
Choose the most important qualification before reusing the history.
Concepts: throughput, evidence window
There is no attempt limit or pass/fail state. Completing the check only enables the lesson's separate explicit completion control; it never records completion or certificate eligibility itself.
Activity ready. Attempts are unlimited. Completing this practice activity enables the lesson's separate, explicit completion control.
Equivalent non-interactive path
Answer and feedback guide
A team previously counted code-ready items as finished; the new release counts production acceptance. What should happen?
- Reuse the average because the same people remain: Team continuity does not repair a changed definition of finished.
- Qualify or replace the history because the finish boundary changed (best answer): Correct. The observations no longer measure the same flow boundary.
- Add an arbitrary percentage to the old average: An unexplained buffer does not make unlike measures comparable.
References
Sign in to save progress across devices.Sign in
Course outlineLesson 1 of 3
Keep release evidence decision-ready