# Throughput counts when work items are split

Illustrative planning brief; no automatic product import.

Synthetic example: One customer outcome is represented by a parent and three child tasks. All children finish this week and the parent outcome is accepted. A draft counts all four records as deliveries.

## Decision

Report one accepted parent outcome or three completed child tasks as separate measures, never four equivalent outcomes.

## Owned work

- Choose the reporting unit
  - Owner role: Delivery lead
  - Acceptance evidence: The week’s rule names accepted parent outcomes and excludes their children from that count.
- Map split lineage
  - Owner role: Task owner
  - Acceptance evidence: Three child records link to the single outcome with distinct IDs.
- Reconcile the week
  - Owner role: Report reviewer
  - Acceptance evidence: One outcome and three child completions appear in separate columns.

## Workflow

1. Define what a counted item represents before the reporting period.
2. Record parent/child lineage and the chosen accepted-finish condition.
3. Separate granularity changes from changed delivery volume.

## Judgment

Do not sum nested records into a single outcome count. A completed child does not prove the parent’s acceptance.


## Worked reporting note

Weekly note: one accepted outcome represented by three completed child tasks; no comparable earlier-period trend is inferred.


## Working artifact

- Observed / One accepted parent and three completed children / Supports separately labelled counts.
- Unknown / Comparison under the prior period’s unit / Resolve the earlier policy before claiming growth.
- Next check / Reconcile one split lineage before publishing totals / Hold mixed parent/child counts.


## Workflow questions

### Can we count child tasks instead?

Yes, with a child-task unit and consistent inclusion policy. Do not compare it directly with parent outcomes.

### Why preserve the parent-child mapping?

It lets the reviewer see whether several records represent pieces of the same accepted outcome.

### Does this require a specific product rollup feature?

No. The supplied ledger is manual; native rollup availability has not been verified.

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

Record | Level | Observed finish | Reporting treatment
--- | --- | --- | ---
Outcome O1 | Parent | Accepted | Count 1 outcome
O1-A | Child | Finished | Count in child view
O1-B | Child | Finished | Count in child view
O1-C | Child | Finished | Count in child view

### Derivation

Parent-outcome count = 1. Child-task count = 3. The sum 4 mixes nested units and double-counts the represented outcome.

Weekly note: one accepted outcome represented by three completed child tasks; no comparable earlier-period trend is inferred.

### Evidence boundary

Observed / One accepted parent and three completed children / Supports separately labelled counts.
Unknown / Comparison under the prior period’s unit / Resolve the earlier policy before claiming growth.
Next check / Reconcile one split lineage before publishing totals / Hold mixed parent/child counts.

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