Story Decomposition
Story decomposition is the structure that states a solution's requirements at decreasing levels of detail: the solution goals at the top, then the minimal marketable features (MMF) or components, then the stories, then the acceptance criteria that validate each one. The Agile Extension to the BABOK Guide applies it to any story too large or too poorly understood to be elaborated, estimated or delivered. The descent is progressive: the initial analysis sets the goals, the MMFs and the large stories; the bottom of the tree fills in as the initiative advances. The guide also fixes the basis for splitting: functionality the customer values.
Goal
The Agile Extension to the BABOK Guide gives the technique this purpose: to express a solution's requirements at the level of detail that suits, aligned with the outcomes sought. What it produces is a four-level hierarchy, from the overall context down to the acceptance criteria of a story, each level staying attached to the one above.
Backlog refinement is the recurring activity, held as a session, where splitting is practised, while story decomposition is the structure that splitting follows. Functional decomposition takes any subject, a function, a process or the work to be done, under two contracts checked at every level: the children cover the parent; each child has a single parent. Its depth follows from the task that will consume the tree; the depth of a story decomposition follows from the distance to delivery, under a value test applied story by story. The two trees therefore come out at unequal depths. Story elaboration, covered in §7.19 of the Agile Extension, adds detail and criteria to a story that already exists: decomposition changes the number of stories, elaboration changes what a story says.
Table 7.0.1 of the Agile Extension files it under requirements management and on the internal-team side, with no entry for outside stakeholders. The hierarchy serves the builders before anyone else, since it orders work before that work can be shown.
Usage
When to use it
- A story too large to estimate or deliver: the guide makes this the trigger.
- Start of an initiative: setting the solution goals and the MMFs before any detailed story.
- Release planning: deciding which features ship, in what order and how far.
- A team absorbed in the detail: the hierarchy attaches every story to the business objective that justifies it.
- Coordination with training and change management: the MMFs give these workstreams the unit of work they align on.
- A backlog inherited from a technical split: rebuilding the slices around functionality the customer can judge.
When not to use it
- A story already estimable and deliverable: it is ripe for elaboration.
- A scope, a process or an organisation to break down: those subjects belong to functional decomposition.
- A story impossible to estimate where size is not the cause: the obstacle is an unknown, and a spike lifts it.
Description
The four levels
| Level | What it carries | What it lets a team decide |
|---|---|---|
| Solution goals | The highest level of the business requirements: the drivers behind undertaking the initiative. | The reference against which every detailed need is appraised. |
| MMF / component | Logical groupings of the functionality and the capabilities the solution has to offer to be worth putting into service. They often form the themes of a release. | What ships in which release and the overall context of the product. |
| Story | A user story, a job story, a use case or a requirement to implement. | What a team takes into an iteration. |
| Acceptance criteria | The conditions of satisfaction that validate a story, written as lists, as specifications or as acceptance tests. | On what conditions the story is accepted. |
The second level carries two names inside the guide itself: §7.18 calls it MMF or component, where §6.7.1 writes decompose epics to stories at the Delivery horizon. A reader coming from SAFe or from a backlog tool will recognise the object under the name epic. The fourth level is written during story elaboration, on the one story whose delivery is approaching; decomposition itself stops once the story exists as a candidate.
Work in breadth before going deep
The approach the Agile Extension calls breadth-before-depth orders the descent: the business objectives first, then the components that each carry an increment of value for the customer, then the stories, then their acceptance criteria. Once the MMFs or the feature groups are established, use cases can stand in place of stories.
On an agile initiative, the first analysis activities identify the goals, the MMFs and most of the large stories; the splitting of those stories is completed in increments. The guide gives the reason: those stories will change and the understanding of the requirements will develop, so going down to the last level early produces work to throw away.
The basis for splitting
The Agile Extension rules out three bases for splitting: the process (step 1, step 2, step 3 of a flow), the architecture (build the database, then the server, then the interface) and the procedure (design, build, test). The basis it retains is functionality the customer values.
Two practitioner catalogues give the splitting patterns that hold to this constraint. Richard Lawrence and Peter Green list nine: workflow steps, business rule variations, variations in data, data entry methods, simple case against complex case, deferred performance, major effort, CRUD operations (create, read, update, delete), spike. Mike Cohn keeps five under the acronym SPIDR: spike, path, interface, data, rules. The spike appears in both catalogues: extracting one shrinks the story that remains. It is the split to use when the unknown rules out any slice of value. The exit test comes from Bill Wake's INVEST criteria. Two of them decide the matter here: valuable, the story brings something the customer can judge; independent, it ships without waiting for the others.
What makes a decomposition fail
The return to detailed up-front specification
The guide names this anti-pattern: treating story decomposition as a way back to the detailed specification written up front. The tree then descends everywhere down to the acceptance criteria. What comes out is a complete specification under another name. The remedy sits in just-enough, just-in-time: knowing when to stop decomposing, branch by branch, according to the distance between each MMF and its delivery.
The technical slice dressed as a story
"Create the subscriptions table" has the form of a story and the substance of a task. No customer can accept it, no demonstration shows it and a release made of such slices exposes nothing usable until the last one is finished. At a review, if nobody outside the team can say whether the thing works, the split followed the architecture.
The hierarchy that loses its top
Two of the strengths the guide grants the technique: keeping the project's goals in mind and tracing any functionality, requested or built, back to the business objectives. Both are lost when stories are created flat in the tool, with no parent. The backlog keeps being fed; what a story is for can no longer be established and the arbitration goes to the loudest voice.
AI considerations
A language model shortens the mechanical work of splitting. Submitting a large story together with the pattern catalogue, asking for the pattern applied to each proposed split, produces a list of candidates the team sorts through. The same model checks an already written story against the INVEST criteria and flags the ones that state no benefit, the symptom of a technical split. It also helps group a list of features into candidate MMFs, which the product owner accepts or reworks.
The split a model proposes of its own accord repeats the axes most frequent in its training data, which are technical: a data layer, an interface, a batch job. That is the very basis §7.18 rules out. The model therefore has to be given the value constraint in the prompt, and the output is re-read on that point rather than on its form, which will rarely be at fault. The order of the MMFs stays a decision for the product owner: it is taken on revenue, contractual deadlines and regulatory obligations a model does not know.
A backlog holds customer names, incident extracts and contract details. That material does not go to an external service without the use being covered; the Federal Act on Data Protection (FADP) applies to a backlog extract as it does to the rest.
Examples
A Swiss telecom operator decomposes the customer portal it wants to open to its mobile subscribers. Here is the state of the tree at the moment the team plans its next iteration.
| Level | Content |
|---|---|
| Solution goals | The customer manages their mobile subscription without calling customer service. |
| MMF / component | Subscription change · Roaming options (not decomposed yet) |
| Stories under "Subscription change" | As a customer, I want to see my current subscription and my data usage for the month, so that I can judge whether I should change subscription. As a customer, I want to move to a cheaper subscription from the next billing cycle, so that I stop paying for data I do not use. As a customer, I want to move to a more expensive subscription on the same day, so that I have the data I am short of straight away. As a customer with a subsidised handset, I want to see the subscription tier my contract imposes until it matures, so that I know how far down I can go. |
| Acceptance criteria for the story "move to a cheaper subscription" | The new subscription applies on the first day of the following billing cycle. The customer sees the new monthly price, CHF 29 against CHF 39 for the current subscription, in a confirmation they validate. A change already scheduled for the cycle blocks a second one until it takes effect. |
These four stories come from one, brought to refinement too large: "As a customer, I want to change subscription from the customer portal, so that I pay for what I use." Two patterns split it. Workflow steps detach the lookup: seeing the current subscription and the month's usage is an action that stands on its own and already serves the customer in deciding. Business rule variations then separate three cases: a downgrade takes effect at the next billing cycle, an upgrade on the same day and a subscription taken out with a subsidised handset does not go below its tier before the contract matures. The downgrade goes into the iteration; the lookup, the upgrade and the subsidised-handset case stay candidate stories under the same MMF. Each passes the INVEST exit test: it ships without waiting for the others and it changes something the customer can judge.
"Roaming options" stays at MMF level for as long as its delivery is not close, and the acceptance criteria are written only for the story the team takes into the iteration. The customer who moves down saves CHF 10 a month, CHF 120 over twelve months; for the operator the same amount is subscription revenue forgone. What justifies the story is the goal set at the top of the tree: a subscription change obtained without calling customer service.
Visualisations
The technique is drawn as four stacked rows, connected from top to bottom. The top row, the solution goals, carries a single box. The second carries the MMFs, the third the stories, the fourth the acceptance criteria of the one story whose delivery is close. The number of branches is uneven from one node to the next, since splitting follows value.
The drawing makes the uneven depth of the branches visible: a branch close to delivery goes down to the acceptance criteria while its neighbour stops at the MMF. A tree whose branches all reach the fourth level at the same time shows the return to detailed up-front specification.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Low | The solution goals come from the vision and the business case; the technique picks them up and opens the tree. |
| Execution | Medium | One initial pass in a workshop for the goals and the MMFs, then splitting that comes back at every backlog refinement for the whole of the initiative. |
| Documentation | Low | The hierarchy lives in the backlog tool, as parent-child links; no separate document to maintain. |
Tooling
The backlog management tool carries the hierarchy: Jira links epic and story, Azure DevOps adds a feature level between the two, GitLab stacks epics and issues. None offers exactly the four levels of the guide, so the mapping is decided once and written into the team's conventions. Failing that, two teams file the same object at two different levels and the consolidated views become false.
The wall or the shared board (Miro, Mural or sticky notes on a wall) suits the first pass in breadth, the one done with the whole team. Moving a card from one level to another is a drag and drop there, a property worth having for as long as the grouping into MMFs is not settled; the content then goes down into the tool.
The catalogue of splitting patterns, printed on a card left on the refinement table, turns "this story is too large" into a named split. The nine patterns of Lawrence and Green as much as the five of SPIDR fit on one page, and a team that has them in view proposes splits by value.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.18 Story Decomposition: the purpose of the technique, the trigger of a story too large or too poorly understood, the breadth-before-depth approach and its progressive character, the four elements that are the solution goals, the MMF or component, the story and the acceptance criteria, together with the strengths and limitations stated, among them traceability to the business objectives, the support given to release planning, the anti-pattern of a return to detailed up-front specification and the exclusion of splitting by process, architecture or procedure.
- IIBA, Agile Extension to the BABOK Guide, §7.0, table 7.0.1 Selecting the Right Technique: the technique filed among the requirements management techniques, on the internal-team side.
- Bill Wake, INVEST in Good Stories, and SMART Tasks, XP123, 2003: the origin of the six INVEST criteria, of which valuable and independent are the exit test for a split.
- Richard Lawrence and Peter Green, The Humanizing Work Guide to Splitting User Stories, Humanizing Work: a practitioner catalogue, not normative; the nine patterns for splitting a story.
- Mike Cohn, SPIDR: Five Simple but Powerful Ways to Split User Stories, Mountain Goat Software: a practitioner catalogue, not normative; the five patterns of the SPIDR acronym.