The Lifecycle of one Work-item
Purpose: The 7-step lifecycle every work item moves through from author to close — and the gates that protect description quality.
Reading time: ~3 minutes · Audience: BA / analyst, tech lead, QA · The composition principles are in Work-Item Description Composition; the per-type templates are in Templates for Work-items of different types.
The lifecycle is the same regardless of WI type — what differs is which agents do which steps. Knowing the lifecycle stops teams from skipping the validation gates that protect description quality.
The seven steps
| # | Step | Owner | What happens |
|---|---|---|---|
| 1 | BA writes the WI | BA / analyst | Author per the type template — see Work-Item Type Templates. Include scope-out, sibling reference, mapping table where applicable. |
| 2 | Tech lead validates | Tech lead / architect | Is scope atomic? Are dependencies explicit? Is the contract there? Reject and send back if any of these fail — do not push half-ready WIs into agent runs. |
| 3 | Swifter generates the specification | Analyst agent | For component / page → detailed spec; for AC → criteria. The spec is the artefact the developer agent will read. |
| 4 | BA compares the generated spec to expectation | BA / analyst Development Team | ~90 % match → ship to development. Less → refine the WI and regenerate. The 90 % gate is the cheapest place in the lifecycle to fix authoring problems. Development Team representatives can be also involved at this Step if necessary to validate details of low-level specification. |
| 5 | Swifter executes the WI against the validated spec | Developer agent | Implementation step. Review in the Dev / App tabs as work lands. |
| 6 | QA runs Playwright tests against AC | QA Tester agent + QA owner | Generates test cases and scripts; runs against Preview; iterates on failures. |
| 7 | Close | Owner of the parent feature | Mark the WI Done; flip the parent feature's child entry; merge or note any rework decisions. |
Why every gate matters
If the lifecycle is shortened — for example, the BA skips step 2's validation, or the team skips the spec comparison at step 4 — the description-quality problems land in the developer agent's input and cost a session to unwind. The discipline is procedural and cheap.
The two gates that catch problems early:
- Step 2 — Tech lead validates catches scope and dependency problems before the analyst burns a session on a half-ready WI.
- Step 4 — BA compares catches misalignment between expectation and generated spec before the developer agent runs. A wrong spec produces wrong code; catching it here costs minutes, catching it after implementation costs a session.
What comes next
The per-type agent + command sequences for steps 3 and 5 are in Work-Item Run Sequences. The diagnostic guide for when a step stalls is in Cookbook → Journeys → Troubleshooting.