Read the diagram as text
Trace one work item through request, build, review and delivery. Record both active work and waiting between stages. Check the observation with the people who perform the work.
Trace one item→02
Locate waiting→03
Test a change
A map should help people make a decision. Start by tracing one completed request from the customer's first action to the useful result. Use the records and the people who handled it. This produces a specific conversation about movement and waiting; a generic diagram of departmental responsibilities often does not.
Choose a representative example and its limits
Pick a recent item that people can reconstruct. Write down why it was chosen: an ordinary case, a repeated complaint or an unusually long wait. One case is a starting observation, not a statistical description of the service. After tracing it, inspect other items to see whether the same sequence and obstacles recur.
Define the customer boundary before extracting timestamps. If the customer's request arrived days before an internal ticket was created, that gap may matter. Similarly, an internal “done” status may precede the moment the customer can use the result. Keep those differences visible and decide which boundary the present investigation uses.
Draw a timeline people can verify
- Record each state with an entry and exit observation where available.
- Separate active attention from waiting; label unknown periods as unknown.
- Write what signal moved the item to the next state.
- Name a dependency or decision rather than blaming a department.
- Check the trace with the people who handled the work.
Illustrative trace
Imagine a request submitted Monday, clarified Tuesday, implemented Wednesday and approved Friday. That does not establish three days of implementation. The item could have waited for most of the interval. Ask what was happening rather than deriving effort from elapsed dates. A start/finish record can support an elapsed-time measurement while still saying little about hands-on work.
The Kanban Guide defines workflow boundaries and flow measures. Our trace adds questions about the individual decisions and handoffs. Use the flow calculator only after your units and boundary are consistent; its relationship is an explanatory average, not an item deadline.
Choose where to observe next
Look for a repeated decision or a period nobody can explain. If requests wait for clarification, collect examples of the missing information. If a review queue grows, observe how reviewers select items and what prevents completion. A workshop opinion about a bottleneck is a hypothesis until the work supports it.
Be careful with proposed local improvements. Moving an approval earlier might reduce one queue while transferring uncertainty to the customer. Splitting a request might make the board move faster while postponing an essential result. Review the end-to-end consequence and the workload created for other people.
Turn the observation into an experiment
Item and reason for selection: Customer boundary: Known states and timestamps: Unknown intervals: Repeated obstacle to investigate: Proposed change and owner: Next evidence and review date:
The original From Push to Pull and Frog & Bike Thinkers pieces give useful historical context. Keep your current map grounded in your own observations. Do not label a hand-drawn future state an implemented improvement until people have actually tried it.
Primary reference
The Kanban Guide: workflow boundaries ↗. Consulted 4 October 2026. Procedures and training examples above are editorial proposals; examples are illustrative and are not claimed business results.
A numerical trace: elapsed time is not hands-on time
An entry and exit timestamp can measure an interval. It does not tell you how much of that interval someone spent working on the item. Add a small attention log to one trace so that elapsed time, observed touch time and unknown time remain distinguishable.
A trace with explicit boundaries
Consider a fictional request received at 09:00 and delivered at 11:00 on the same day. Its elapsed interval is 120 minutes. The recorded handling episodes are 09:10–09:25, 10:00–10:20 and 10:55–11:00. They total 15 + 20 + 5 = 40 minutes of recorded touch time.
The remainder is 80 minutes without a recorded handling episode. Do not immediately call all 80 minutes avoidable waste. Some may reflect a necessary dependency, work on other items, an unobserved episode or incomplete logging. Label it “outside recorded touch intervals” until further observation explains it.
Why the denominator matters
For this fictional trace, recorded touch time divided by elapsed time is 40 ÷ 120, or about 33.3%. That ratio describes this trace with these observations. It is not a utilisation measure for the people involved, a target for every team or a prediction of how much time could be removed.
If two people work simultaneously on the same item, adding their person-minutes is a different measure from the duration of the item's touch intervals. Preserve both if they answer useful questions, but do not substitute one for the other. The worksheet asks which measure the reader is recording before calculating a ratio.
Make the next observation smaller
- Define request and delivery from the customer's point of view.
- Record the known handling intervals and how they were observed.
- Identify overlaps, missing observations and changes of time zone.
- Calculate elapsed and observed durations with the same time unit.
- Pick one unexplained gap to investigate; do not infer a bottleneck from one trace.
The original trace might lead to a question about when clarification is requested. An experiment could change that request and observe comparable later items. Record the proposed change, its owner and what would count against the explanation. Do not claim the new workflow works until it has been tried.
The Kanban Guide supplies context on workflow boundaries and flow measures. This numerical exercise is an independent editorial addition. It is not a measurement from Richard Durnall's career or a new experiment performed by him. The downloadable log retains original timestamps beside the derived intervals so another reader can inspect the calculation.
Text equivalent: Elapsed: 09:00–11:00 = 120 min → Recorded touch: 15 + 20 + 5 = 40 min → Other interval: 80 min; explanation unknown
| Field | Completed example |
|---|---|
| Customer boundary | Request received → useful delivery |
| Entry / delivery timestamps | 09:00 → 11:00; same fictional day |
| Recorded handling episodes | 09:10–09:25; 10:00–10:20; 10:55–11:00 |
| Overlap and missing observations | No overlaps in this teaching trace |
| Elapsed / touch duration | 120 min / 40 min |
| Next gap to investigate | 80 min outside recorded touch; not a waste claim |
Blank worksheet and worked example ↓
Primary context: The Kanban Guide: flow measures