Work types
Work is the collective term for anything the practice acts on. All work carries exactly one type — capability, fix, chore, question or initiative — assigned at the sift, or verified there if it arrived carrying one.
The type says why the work exists — not how large it is, how urgent, or how much rigour it needs. Those are answered elsewhere and answered separately.
These five are the vocabulary the practice reasons in. Everything downstream — what may be claimed, what attaches to what, what needs no commitment — is expressed in these terms and only these.
The ordered test
| Ask, in order | Request type |
|---|---|
| Does it resolve into other work rather than being done directly? | Initiative |
| Does it ask for information rather than change anything? | Question |
| Does it correct something previously completed? | Fix |
| Does it give a named persona an outcome they did not have? | Capability |
| None of the above | Chore |
Chore is the residual, and deliberately so — it is defined as work that changes no capability, so it is what remains once the other four have been ruled out.
Subtypes
An application may name and extend them as it needs. Exactly as it declares its own personas and disciplines, a system carries whatever work types its tooling and its people actually use, and may add more where something genuinely does not fit — provided every one maps onto a type defined here. The mapping is what keeps the practice's guarantees intact whatever the tracker happens to call things, and it is what keeps the request type decidable on arrival.
| An application calling it | Maps to |
|---|---|
| Bug · defect · regression | Fix |
| Feature · story · requirement | Capability |
| Epic · programme · theme | Initiative |
| Spike · investigation · RFI | Question |
| Task · maintenance · technical debt | Chore |
The practice never uses those words itself. They vary by team, by client and by tool, so nothing downstream is made to know which tracker is in use.
How subtypes are declared is written on subtypes.