# Reconcile a work queue's stock and flows

Illustrative planning brief; no automatic product import.

Synthetic planning case: A review queue starts with ten distinct requests. Six arrive, five exit by accepted review and two transfer to another queue during the same bounded period.

## Decision

The expected closing queue is nine requests. Keep the two transfers separate from accepted exits; they reduce this queue without establishing delivered outcomes.

## Owned work

- Freeze queue and unit definitions
  - Owner role: Queue owner
  - Acceptance evidence: Both snapshots count distinct review requests under one scope.
- Reconcile each movement
  - Owner role: Reporting reviewer
  - Acceptance evidence: Arrivals, accepted exits and transfers have separate evidence.
- Investigate a remaining mismatch
  - Owner role: Coordinator
  - Acceptance evidence: Any actual closing count different from nine receives a record-level reconciliation.

## Workflow

1. Freeze queue and unit definitions. Check: Both snapshots count distinct review requests under one scope.
2. Reconcile each movement. Check: Arrivals, accepted exits and transfers have separate evidence.
3. Investigate a remaining mismatch. Check: Any actual closing count different from nine receives a record-level reconciliation.

## Judgment

The example assumes complete movement evidence and matching snapshots. A mathematical balance does not prove every event was correctly classified.


## Filled manual planning note

The expected closing queue is nine requests. Keep the two transfers separate from accepted exits; they reduce this queue without establishing delivered outcomes. Closing=10+6−5−2=9. A closing count of eleven would omit transfers; treating all seven departures as accepted would overstate outcomes. The example assumes complete movement evidence and matching snapshots. A mathematical balance does not prove every event was correctly classified.


## Workflow questions

### Are transfers completed work?

Not from this ledger. They are departures from this queue; acceptance is a different event.

### Can cancellations be ignored?

No. If present, they need their own stated flow line and reason.

## Product connection

Use the owned checks and downloaded brief to discuss this planning decision alongside your TeamBoostAI tasks. Confirm available fields, roles and account features separately. The example is manual; it does not calculate live analytics, create work or run an experiment in the product.

Confirm account availability before adopting this manual outline.

## Original worked case

Synthetic records, manual planning only. No account import or live analytics.

### Inspect the invented case records

Ledger line | Requests | Meaning
--- | --- | ---
Opening stock | 10 | Same queue and unit
Arrivals | 6 | New requests into queue
Accepted exits | 5 | Review outcome evidenced
Transfers out | 2 | Move to another queue
Closing stock | 9 | Reconciled expected count

### Reasoning

Closing=10+6−5−2=9. A closing count of eleven would omit transfers; treating all seven departures as accepted would overstate outcomes.

### Bounded result

The expected closing queue is nine requests. Keep the two transfers separate from accepted exits; they reduce this queue without establishing delivered outcomes.

### Distinct decision

The artifact reconciles queue movements rather than simply counting work in progress.

### Limits

The example assumes complete movement evidence and matching snapshots. A mathematical balance does not prove every event was correctly classified.

### Definitions and method context

- The Kanban Guide — https://kanbanguides.org/the-kanban-guide/ — Workflow and flow-measure context. Queue policies and staffing scenarios are explicitly local examples, not delivery guarantees.