# Reconstruct review wait from event timestamps

Illustrative planning brief; no automatic product import.

Synthetic example: On the same UTC day, review is requested at 09:00, a reviewer responds at 12:00, a revision runs until 14:00 and a second response accepts it at 15:00.

## Decision

Record three hours of first-round wait and one hour of second-round wait, with two hours of revision work kept separate.

## Owned work

- Identify review events
  - Owner role: Reviewer coordinator
  - Acceptance evidence: Each request and response has a timestamp and round ID.
- Separate revision intervals
  - Owner role: Task owner
  - Acceptance evidence: 12:00–14:00 is recorded as a revision interval, not review wait.
- Verify the handoff rule
  - Owner role: Review lead
  - Acceptance evidence: The reporting note explains whether each response requests changes or accepts work.

## Workflow

1. Pair each request with its first substantive response.
2. Keep revision and subsequent review rounds distinct.
3. Check missing response events before publishing wait totals.

## Judgment

A response is not necessarily acceptance. This timestamp worksheet does not measure reviewer attention or hands-on effort.


## Worked reporting note

Review note: two review rounds, four elapsed waiting hours, two hours in the revision interval; acceptance is separately evidenced.


## Working artifact

- Observed / Paired requests and responses / Supports closed-round waiting intervals.
- Unknown / Time each reviewer actively spent / Do not turn elapsed wait into reviewer effort.
- Next check / Audit one unpaired review request / Show open wait at its checkpoint.


## Workflow questions

### Does the first response mean the task is finished?

No. Here it requests revision; acceptance occurs only in the second round.

### Should the full six-hour span be called review wait?

No. The span includes two hours of revision in this worked example.

### What if a request is still waiting?

Treat it as an open interval at a named checkpoint; do not invent a response timestamp.

## Product connection

Use this manual measurement rule as context when planning or reviewing owned work in TeamBoostAI. Confirm the fields and reports available in your account; the worksheet is not imported automatically.

Confirm account availability before adopting this manual outline.


## Worked measurement study

All example records are synthetic; manual worksheet, no automatic import.

### Inspect the invented records

Interval | Start UTC | End UTC | Elapsed time
--- | --- | --- | ---
Round 1 wait | 09:00 | 12:00 | 3 hours
Revision | 12:00 | 14:00 | 2 hours
Round 2 wait | 14:00 | 15:00 | 1 hour

### Derivation

Closed review waits = (12−9) + (15−14) = 4 hours. Total request-to-acceptance span is 6 hours; revision accounts for 2.

Review note: two review rounds, four elapsed waiting hours, two hours in the revision interval; acceptance is separately evidenced.

### Event sequence

09:00 / Request 1 / Round 1 wait begins
12:00 / Changes requested / Revision begins
14:00 / Request 2 / Round 2 wait begins
15:00 / Accepted / Second response ends wait

### Evidence boundary

Observed / Paired requests and responses / Supports closed-round waiting intervals.
Unknown / Time each reviewer actively spent / Do not turn elapsed wait into reviewer effort.
Next check / Audit one unpaired review request / Show open wait at its checkpoint.

### Method references

The Kanban Guide, May 2025: https://kanbanguides.org/the-kanban-guide/2025.5/ — Clock and work-item definitions; examples and local rules are our own.