# Choose a duration clock for reopened work

Illustrative planning brief; no automatic product import.

Synthetic case: An item starts 09:00, is accepted 14:00, reopens 16:00 and is reaccepted 19:00 on one UTC day.

## Decision

Show a 5-hour first cycle and a 3-hour repair interval; name a 10-hour first-start-to-final-acceptance span separately if needed.

## Owned work

- Preserve lifecycle events
  - Owner role: Task owner
  - Acceptance evidence: Both acceptance events and the reopen event remain dated.
- Choose the report’s episode unit
  - Owner role: Lead
  - Acceptance evidence: The rule distinguishes first cycle, repair episode and whole span.
- Write the duration note
  - Owner role: Reviewer
  - Acceptance evidence: 5h + 3h episodes are not described as 10h of active effort.

## Workflow

1. Retain each event and its episode meaning.
2. Select the duration definition before aggregating episodes.
3. Report excluded gaps and leave effort unmeasured.

## Judgment

A whole lifecycle span and a sum of episodes answer different questions. Do not erase the first acceptance or infer effort from timestamps.


## Filled review note

Lifecycle note: first accepted cycle 5h; later repair interval 3h; total first-start-to-final-acceptance span 10h includes a 2h gap.


## Workflow questions

### Why is the whole span 10 hours but episodes sum to 8?

The whole span includes the two-hour accepted-to-reopened gap; the selected episodes do not.

### Is repair time a new accepted-delivery count?

That requires a separate counted-unit policy; a duration alone does not determine throughput.

## Product connection

Bring this manual reporting policy and its owned checks into your TeamBoostAI work discussion. Native report/export fields and historical reconstruction depend on your account and implementation; this worksheet does not import or change product records.

Confirm account availability before adopting this manual outline.

## Decision workshop

Synthetic examples only. Manual worksheet; no automatic import or product writes.

### Synthetic reporting records

Episode | UTC interval | Elapsed time
--- | --- | ---
First episode | 09:00–14:00 | 5h
Gap after acceptance | 14:00–16:00 | 2h
Repair episode | 16:00–19:00 | 3h

### Version changes

Boundary | Draft | Revised
--- | --- | ---
Duration unit | Single unlabeled span | Separate episodes and whole-span rule
History | Earlier acceptance overwritten | Both acceptance events retained

### Draft or earlier version (review its limits)

Draft: one 10-hour task duration with no episode context.

### Revised example

Lifecycle note: first accepted cycle 5h; later repair interval 3h; total first-start-to-final-acceptance span 10h includes a 2h gap.

### Decision situations

- Both acceptance events and reopen are known: Use separately labelled episodes or whole span with its gap explained.
- A lifecycle event is missing: Hold reconstructed episode durations.
- The question is delivered-unit count: Use a counted-unit policy; do not derive count from duration.

### 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.