Work Understanding: Rework and handoffs
Objective. Read the rework-and-handoffs view to see where work loops back or changes hands, so a reader can flag a rework or handoff pattern as a candidate cost to validate rather than assuming every loop is waste.
This view answers 'where does work get redone or passed around, and what does that cost?' Rework loops and handoffs are classic hidden time sinks that a hand-drawn map never shows.
See it in the demo
What this screen answers
The customer question is: where is work being redone or handed off, and is that adding time? A Sales person uses it to surface loops and handovers that the customer did not know were there. A CSM uses it to decide whether a recurring rework loop is worth a validated fix.
The task
Scope to the process and period, then read where work loops back (rework) and where it changes hands (handoffs), and how often. The move is to identify a repeating pattern - a step that frequently sends work backward, or a handoff that stalls - and frame it as a candidate cost to quantify and validate, linked to step time for the waiting it introduces.
How to read it
Rework and handoff patterns are detected from captured signal and are hypotheses, not proven waste. The classic misread is treating every loop or handoff as removable cost - some rework is legitimate correction and some handoffs are necessary controls. Read a frequent, high-time loop as a candidate to investigate, and confirm with the customer whether it is avoidable before calling it waste.
Honest limits
The view does not prove a loop is avoidable or that removing a handoff is safe, and coverage bounds detection. It does not establish that the rework caused a quality problem or vice versa. Confirm with the customer which loops are legitimate and validate any proposed change with a measured before/after.
Interpretation check
Not every rework loop or handoff is removable waste - some is legitimate correction or necessary control, so treat a frequent loop as a candidate to validate, not a proven cost to cut.
Practical task
On the rework/handoffs view for one process, name the most frequent loop or handoff, state it as a candidate cost, and write one line on whether it looks avoidable or legitimate and how you would confirm.
Self-check
A step frequently sends work backward. Is that waste to eliminate?
Not automatically. Some rework is legitimate correction. Treat a frequent, costly loop as a candidate to investigate, confirm with the customer whether it is avoidable, then validate with before/after.
Why do rework and handoffs matter in the discovery story?
They are hidden time sinks a hand-drawn map misses - loops and handovers that add elapsed time, often as waiting, which the view makes visible from real signal.
Before proposing to remove a handoff, what do you confirm?
Whether the handoff is a necessary control and whether removing it is safe - validated with the customer and a measured before/after, not assumed.
Verified vs demo. Screen is live in the demo at /#/rework; exact controls, loop counts and figures are SME-validation-pending.