Handoff Quality

The active work in a process is rarely the slow part. The waiting between steps is. Flow efficiency is the share of total elapsed time that a piece of work is actually being touched, measured as active time divided by total cycle time. New teams often measure their own flow efficiency near 15%, and even mature teams tend to land around 40%. The other 60 to 85 percent is wait: queues, blocked dependencies, work sitting in review, and items parked at the boundary between two teams while one waits on the other.

Handoffs are where that wait concentrates. Every time work crosses a seam between a person, a team, or a system, two things happen. The clock starts on a queue, because the receiver is busy with something else. And context leaks, because the sender knows things that never made it onto the ticket. Lean software development names handoffs as one of its seven wastes, and pairs it with relearning, the cost of working out the same thing a second time because the knowledge was lost in transit. Each transition is a fresh chance for delay, miscommunication, and rework.

The failure is concrete. A developer marks a feature done and moves on. Two days later a tester picks it up, cannot find the acceptance criteria, does not know which edge cases were considered, and has no test data. The tester pings the developer, who has now swapped context to a new task and has to reload the old one to answer. That round trip can burn an hour on each side for work that was supposedly finished, and it repeats every time the seam is crossed. Multiply that across a quarter and the cost is no longer a nuisance, it is most of your lead time.

Getting handoffs right does the opposite. The receiver starts immediately, the work moves on the first pass, and the audit trail means nobody has to chase the sender. The mechanism that makes this happen is a shared, measurable definition of what "ready to pass" means, written from the receiver back to the sender. The next section breaks that mechanism into its parts.

A good handoff is built from a few moving parts that you can name, agree, and record. Get them explicit and the seam stops being a place where work disappears.

The roles at the seam

Borrow plain labels from documentation practice. The doer is the person passing the work, sometimes called the sender. The receiver is the person picking it up. The receiver is the one who decides what "complete and clear" means, because they are the one who will be blocked if it is not. The doer works to the receiver’s standard, not their own.

Readiness criteria and the definition of done

The definition of done is the agreed finish state for the work before it is allowed to move. For a handoff, that finish state is set by what the receiver needs to start without coming back with questions. Write those needs as readiness criteria: short, specific, and checkable. "Acceptance criteria attached" is checkable. "Properly documented" is not. The test for a criterion is simple: could two people look at the work and agree whether it is met, without asking the doer?

What travels across the seam

A status alone is not enough. Engineering and clinical teams converge on roughly the same four-part payload for what a handoff should carry:

• Work state : where each item actually stands right now, in one or two sentences, not just a ticket column.
• Active decisions : the choices made along the way and the reasoning, so the receiver does not relitigate or reverse them by accident.
• Open questions : what is still blocking or undecided, with enough context to act on it.
• Next actions : the specific first step the receiver should take.

In healthcare, the same idea is codified as SBAR (Situation, Background, Assessment, Recommendation), a structured handoff format created at Kaiser Permanente and now endorsed by the Joint Commission and the WHO. The names differ, the principle is identical: pass intent and rationale, not just a label.

Acceptance as a recorded, two-sided step

The handoff is complete when the receiver checks the work against the criteria and records acceptance. That record names what was validated, what is still open, and where the detail lives. It is two-sided on purpose: the doer cannot declare a handoff done from their side alone. The record is also what makes the seam queryable later, so a third person can see what happened without interrupting either party. With those parts in place, you can run a real handoff end to end, which the next section does.

Take a support-style workflow you would recognize. A request comes in, gets triaged, waits in a queue, is assigned, worked, reviewed, and sent back. The seam that keeps biting is the one between the developer who builds the fix and the QA tester who verifies it. Work crosses it marked "done" and bounces back a day later as "cannot reproduce, no test data."

Priya runs QA. Dev marks an average of twelve items "ready for QA" a week, and Priya sends four back unstarted because she cannot begin. Here is how the team fixes the seam.

1. Name the handoff and the roles. The seam is dev to QA. Marco (developer) is the doer, Priya (receiver) sets the bar.
2. Ask the receiver what she needs to start. Priya lists five things she always ends up chasing: acceptance criteria attached, edge cases listed, test data available, known limitations noted, and the ticket linking the decision thread.
3. Turn that into a readiness list. Those five become the explicit checklist Marco completes before moving a ticket to "ready for QA." Each is checkable by anyone, not a judgment call.
4. Record validation and acceptance. When Marco passes a ticket he notes what he tested and what he left open. Priya accepts only when all five items are present, and logs the acceptance on the ticket.
5. Review the criterion that keeps failing. After two weeks, four of five returns trace to one item: missing test data. The team adds a seeded test dataset to the build so the criterion is met by default.

The before and after is measurable. Returns at the dev-to-QA seam drop from four a week to one. Priya stops losing the first hour of each ticket to reconstruction, and Marco stops being interrupted to re-explain work he has already context-switched away from. The cycle time for a fix falls because the item moves on the first pass instead of making a round trip. The short list earns its place by removing the rework the seam was generating. The next section covers what goes wrong when you try this and the list backfires.

The most common failure is defining "done" from the doer’s side. Marco can honestly believe a ticket is finished because it is off his desk, while Priya cannot start because it is missing the one thing she needs. The fix is to write every criterion from the receiver back to the sender, and to let the receiver, not the sender, own the list.

The second trap is a heavy or vague list. If the readiness checklist has fifteen items or includes "code is high quality," people route around it, mark things ready that are not, and the seam goes dark again. Keep the list short enough to complete honestly and specific enough to check. A useful test: every item should be answerable yes or no by someone who is not the doer.

A subtler failure is passing state without rationale. The receiver gets "PR up, some tests failing, look into it" and has to reconstruct what "failing" means, which tests, and who holds the credentials. State alone forces relearning. Always carry the decisions and the reasoning, not just the status.

Edge cases the simple version misses

• The unstructured channel : a handoff posted only in a chat thread disappears within hours, cannot be queried, and has no record that the receiver read and understood it. Put the handoff where it persists and is checkable, on the ticket or in the system of record.
• The handoff with no clear owner : when a seam sits between two teams and neither owns the boundary, work stalls in the gap. Name a single accountable owner for the handoff itself, the RACI rule of one accountable person per task, before you tune any criteria.
• The seam that should not exist : sometimes the honest answer is to remove the handoff. Warm, friendly handoffs improve the quality of a pass, but they cannot delete a seam that org design created. If a request crosses four teams to be resolved, no checklist fixes that; cross-functional ownership does.

Each of these gets harder when more people and teams are involved, which is where the practice has to become a habit rather than a one-time fix.

A single good handoff is easy to arrange in a hallway. The practice has to survive many handoffs, across teams, over months, without anyone policing it. That means making it a property of the system rather than a favor people remember to do.

Start where the work is most painful. Map the flow first so every seam is visible, then pick the one handoff that bounces most and write its readiness list with both sides in the room. Resist the urge to standardize a list for the whole organization on day one. A dev-to-QA handoff and a design-to-engineering handoff need different criteria, and a universal checklist will be too vague to help either.

Keep it alive with a lightweight cadence and the right defaults:

• Make the criteria the default path : bake them into the ticket template or the "ready" column so meeting them is the easy way to move work, and skipping them takes effort.
• Set a review trigger : when an item bounces back across a seam, that is the signal to look at the list, not a reason to blame a person. Tighten the one criterion that keeps failing, as Priya’s team did with test data.
• Limit work in progress (WIP) at the seam : a long queue at a handoff is wait time by another name. Capping how much can sit "ready" forces the receiver and sender to keep the boundary flowing.

Track the seam, not just the people. If returns at a handoff stay high after you have tightened the list, the problem is usually structural, an org boundary that should not be there, and the right move is to question the system itself. Treating a recurring bounce as a design signal rather than a personal lapse is what keeps the fix durable. That shift from fixing each instance to fixing the seam itself is double-loop learning, and it is the durable principle worth keeping: a handoff is a design choice, and the best ones you remove.