Work sample / Product specifications
Capability coverage framework
Before writing a story, identify the behavior envelope: who can act, on what, from where, in which state, and with what response or downstream effect.
This is a fictional, abbreviated example. It illustrates a method and contains no internal specifications or production behavior.
Artifact / Example coverage map
Review a scheduled transfer
| Dimension | Question to resolve | Illustrative evidence |
|---|---|---|
| Boundary | Does this cover review only, or submission too? | Review and correction are in scope; authorization is a separate story. |
| Actor & permission | Which user can see and act on the draft? | Role and account eligibility require policy confirmation. |
| Object & state | Is it a draft, submitted instruction, or scheduled occurrence? | The example starts with a draft scheduled instruction. |
| Interaction | What changes after an edit? | Review summary refreshes; changed details are shown before submission. |
| Validation & recovery | What happens when information is incomplete? | Explain the gap, preserve entered work, and return to the relevant field. |
| Post-action effect | What needs to be visible after submission? | Status and next action need separate definition; do not assume execution. |
From coverage to stories
Split by meaningful behavior, such as complete review, missing information, changed details, or approval handoff. Then write scenario-level acceptance criteria from confirmed rules. This framework finds coverage gaps; it does not prescribe story formatting.