FIELD GUIDE 05 · SYSTEMS THINKING

Map one piece of work before mapping everything

Independent guide · published and reviewed 4 October 2026

READING MODE Approx. 5 min
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.
See the time between the tasks — 2026 illustration by Durnall website. Download PNG.
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.

01
Trace one item
02
Locate waiting
03
Test a change
Working procedure: Trace one item → Locate waiting → Test a change. Read the steps and worked example below. Download the procedure diagram.

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

  1. Record each state with an entry and exit observation where available.
  2. Separate active attention from waiting; label unknown periods as unknown.
  3. Write what signal moved the item to the next state.
  4. Name a dependency or decision rather than blaming a department.
  5. 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 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

  1. Define request and delivery from the customer's point of view.
  2. Record the known handling intervals and how they were observed.
  3. Identify overlaps, missing observations and changes of time zone.
  4. Calculate elapsed and observed durations with the same time unit.
  5. 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 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.

Elapsed: 09:00–11:00 = 120 min → Recorded touch: 15 + 20 + 5 = 40 min → Other interval: 80 min; explanation unknown
The coloured intervals total 40 of 120 minutes; uncoloured time is not automatically avoidable waste. Original Durnall trace, not Richard’s research data.

Steps: Elapsed: 09:00–11:00 = 120 min → Recorded touch: 15 + 20 + 5 = 40 min → Other interval: 80 min; explanation unknown

FieldCompleted example
Customer boundaryRequest received → useful delivery
Entry / delivery timestamps09:00 → 11:00; same fictional day
Recorded handling episodes09:10–09:25; 10:00–10:20; 10:55–11:00
Overlap and missing observationsNo overlaps in this teaching trace
Elapsed / touch duration120 min / 40 min
Next gap to investigate80 min outside recorded touch; not a waste claim

Blank worksheet and worked example ↓

Primary context: The Kanban Guide: flow measures

Trace one return through review before calling it a people problem

A work item can move backwards on a board without proving that someone worked carelessly. Trace the return and the information available at the time. The aim is to identify a condition worth changing, not to attach a failure label to a person.

A synthetic trace with a loop

A fictional request is received at 09:00. Drafting starts at 09:10, and the draft enters review at 09:40. At 10:00 the reviewer returns it because a required description is missing. Revision starts at 10:20, the item re-enters review at 10:35, and it is accepted at 10:50. Delivery occurs at 10:55.

Draw both review entries. They are two visits to a state by one item, not two completed deliveries. Preserve the return reason in the words used at the time. “Missing description” tells you more than a generic “rejected” status, but it still does not establish why the description was absent.

Test two possible explanations

  1. An existing requirement was missed: locate the version of the request or acceptance criteria available before drafting. If the description was explicitly required there, investigate how that requirement was communicated and checked.
  2. The scope changed: if the description was first requested during review, record when that new request appeared. A legitimate change of need is different from failing to meet a requirement already agreed.
  3. The evidence is incomplete: if no dated requirement survives, keep the cause unresolved. Do not convert a reviewer’s present recollection into proof of what the drafter knew earlier.

In the worked example, the team finds a dated request containing the required description, but no agreed pre-review check. Its proposed experiment is a short acceptance-criteria check before the next comparable item enters review. That is a hypothesis about a missing feedback step, not a verdict on the drafter or a demonstrated improvement.

Review the experiment: on the next few comparable items, record whether the same information was available, whether a check occurred and why any item returned. Also note added delay or unhelpful checklist work. Do not report a general rework rate from this one trace, or compare counts after silently changing the definition of an item.

Copy this loop record: item and boundary ___; first state entry ___; return signal and exact reason ___; requirement version available before work ___; changed-scope evidence ___; repeated state entry ___; delivery ___; proposed condition to test ___; owner and review date ___.

The Lean Enterprise Institute describes value-stream mapping as considering the flow of work and information. This example applies that perspective to one review loop. It is not an observation from Richard Durnall’s career or a claim that he conducted this experiment.

One fictional work item enters review, returns for revision and enters review again before one delivery. The trace contains two review visits, not two delivered items. The earlier requirement must be checked before assigning a cause.
Trace the return signal and information before deciding which condition to test. © Durnall website · CC BY 4.0.

Lean Enterprise Institute: Value Stream Mapping

Find a useful idea.

Type a topic to explore.

Explore the diagram