Work Items In Practice

Work Items resolve Issues. The guide covers what each Work Item is. This page covers how to choose.

Relationship Map

Work Items form a hierarchy. Each level adds specificity:

Issue
  ├── Resolved directly (question answered, config fixed, incident handled)
  │
  └── Feature (needs investment, multiple cycles)
        │
        └── Roadmap (Now / Next)
              │
              ├── Study (unknowns → ADR / prototype / kill)
              │
              └── Stories (independent value units)
                    │
                    ├── Trivial → Tasks directly
                    ├── Partial → criteria + Tasks + Tests
                    └── Complex → Use Case → Tasks + Tests

Fidelity is a choice, not a gate. The team decides how much structure each Story needs.

Default Path + Branching

Default:

Issue → Feature (roadmap) → Stories →
  ├── Partial: criteria + Tasks + Tests
  └── Full: Use Case → Tasks → Tests

Unknowns block delivery:

Issue → Feature → Stories → Study → ADR / prototype / kill →
  ├── Study confirms → proceed
  └── Study kills → kill Feature, close Issue

Trivial work (typo, 1-line config):

Issue → Record minimal Story → Tasks → Build directly

No Feature, no roadmap, no Use Case.

Pre-PMF (startup):

Issue → Feature (paper prototype) → Direct conversation → Build

Drop formality. Retroactively document if the Feature survives.

Prioritisation Methods

MethodUse WhenMechanism
Impact rankingDefaultSort by gut-checked impact-to-effort. Disagreement → conversation.
Cost of Delay (WSJF)High-stakes disagreement, real money at stakeUser value + time criticality + risk reduction ÷ job size
“What hurts most”Pain-driven teamsFeature that removes the biggest current pain wins
Cyclical / round-robinMultiple sponsors or customer groupsEach stakeholder picks one must-have per cycle
Production dataWhen available — always preferredAdoption, behaviour, incidents outrank opinion

Not recommended: Numeric scores (RICE, ICE), MoSCoW, Kano model.

Story-to-Use-Case Fidelity

Is the work trivial (typo, 1-line config)?
  Yes → Tasks directly. No Use Case.
  No →
    Early stage (pre-PMF)?
      Yes → Paper prototype + conversation. Write Use Case only if structure is unclear.
      No →
        Crosses aggregate boundaries?
          Yes → Split the Story. One Story, one Use Case maximum.
          No →
            Needs full structured spec?
              Yes → Full Use Case (Cockburn/Jacobson per Appendix C)
              No → Partial: criteria + Tasks + Tests (most cases)

Role Map

ActivityPrimarySupportsWhen
Feature creationProduct OwnerEngineering LeadIssue promoted to Feature
Roadmap managementProduct Owner—Continuous — Now/Next only
Story slicingProduct Owner + Software Engineer—Feature needs decomposition
Use Case writingSoftware EngineerQA EngineerStory needs full spec
Study executionSoftware Engineer—Unknown blocks commitment
Task decompositionSoftware Engineer—Story or Use Case exists
Test writing (acceptance)QA EngineerSoftware EngineerGherkin scenarios from Use Case
PrioritisationProduct OwnerWhole teamConversation, not formula

Technique Table

TechniqueUse WhenOutputSkill
Feature NarrationTurning an Issue into a FeatureFeature card: current flow, pain points, desired flow, success measurefeature-guide
Story MappingVisualizing user journey across a FeatureStory Map with backbone, slices, prioritystory-guide
Story SlicingBreaking a Feature into independent StoriesIndependent Story cards with dependency orderingstory-guide
Use Case DefinitionFull structured spec per Cockburn/JacobsonUse Case: actor, pre/post, scenarios, extensions, business rulesNot yet available
Acceptance Scenarios (Gherkin)Defining “done” unambiguouslyGherkin Given/When/Then scenariosNot yet available
Task DecompositionBreaking work into actionable stepsTask Specifications with inputs, outputs, constraints, DoDNot yet available
Architectural StudyExploring technical unknownsStudy Report, ADR, prototype, or kill decisionstudy-guide
ADRCapturing architectural decisionsADR: context, options, trade-offs, decisiondecision-records

Procedure Table

ProcedureWhat It DoesWiki Link
Use Case DefinitionFormal specification of a goal-level interactionplanning/procedures/use-case-definition.md
Adopting Modern XPOnboarding a team to the methodologyplanning/procedures/adopting-modern-xp.md

Artifact Table

ArtifactProduced ByConsumed ByFormat
Feature CardFeature NarrationRoadmap, Story slicingNarrative: current flow, pain points, desired flow, success measure
RoadmapProduct OwnerWhole team, stakeholdersTwo buckets: Now / Next
Story CardStory slicingUse Case or direct buildTitle, value statement, priority, parent Feature
Use CaseUse Case DefinitionTask decomposition, TestsStructured: actor, pre/post, scenarios, extensions, business rules
Study ReportStudy executionFeature go/no-goFindings, ADR, prototype, or kill
Task SpecificationTask DecompositionBuild Phase executionInputs, outputs, constraints, DoD
TestGherkin scenariosAcceptance testingID, source, Gherkin scenario, type, preconditions, expected result
ADRStudy or design decisionArchitecture evolutionContext, options, trade-offs, decision

Skip Conditions

ActivitySkip When
Feature (formal narrative)Work is a chore, bug fix, or trivial change
RoadmapPre-PMF; team works on one thing at a time
Story slicingFeature fits in one small Story
Use Case (full structured)Story is clear enough with criteria + Tasks + Tests (most cases)
StudyNo unknowns. The team understands what to build and how.
Chore trackingChore volume is low. Informal handling is fine.
ADRDecision is routine, reversible, or has no alternatives.
Task decompositionWork is trivial. Build directly from the Story.

The team decides how much fidelity is needed. Default to minimal. Add structure only when a specific gap shows it is needed.

Comments

Comments on each page are welcomed and are visible here and under the discussions tab of the github repository.

View discussions on GitHub ↗