Map one piece of work before mapping everything

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.

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.