What this layer is
A High-Level What answers one question:
What major thing does the product need to do or provide, for this Product Goal to be met?
Not a feature. Not a story. A capability area — big enough to hold several Epics, specific enough that you could point at part of the product and say “that's this one”.
The name is one author's. The industry calls this layer themes, capabilities or initiatives, and Jira has an issue type for it. Use whichever word your organisation already uses. What matters is that the layer exists at all.
Why skipping it costs you
Go straight from Product Goal to features and you get a backlog that is individually sensible and collectively incoherent. Every item defensible. Nothing adding up to a product.
The capability layer is what makes a backlog a shape rather than a list.
The two tests
- Cohesive — does everything inside it belong together?
- Separable — could you deliver it without necessarily delivering the others?
Fail cohesion and you have a bucket. Fail separability and you have not decomposed anything — you have drawn a line through the middle of one thing.
How many
Four to six.
- Two or three usually means you haven't decomposed anything; you've renamed the goal.
- More than six or seven and you've started listing features rather than capabilities.
And if you do have to show the list — get it said out loud.
Reading a candidate to the room is not the same as the room agreeing to it. Put it up, then wait for somebody to restate it in their own words, and for at least one other person to push back or add to it. Only then is it theirs.
Because if it stays in your wording, you will be quoted as the author of it — and the first time it is questioned, everyone will look at you rather than at the person accountable for the outcome. That is a bad place for a Scrum Master to be standing, and it is entirely avoidable.
The prompt
The amber parts are the ones you replace.
I am the Scrum Master, preparing a decomposition session. I am NOT producing the capability areas — the room does, or they will treat them as mine. Give me candidates they will correct. CONTEXT Product Goal: [paste it in full] Product Vision: [paste the filled frame] Business drivers:[paste them] Product type: [what kind of thing this is] Constraints: [known technical or organisational limits — external systems, teams you depend on, regulatory obligations] PRODUCE Five to seven candidate capability areas for this Product Goal. For each: 1. NAME — a capability, phrased as something the product does or provides. Not a feature name. Not a component name. If it sounds like a screen or a service, rewrite it. 2. WHAT THE GOAL IMPLIES THAT NEEDS IT — quote the part of the Product Goal this capability serves. If it serves no part of the goal, do not include it. 3. COHESION TEST — one sentence on what belongs inside this area, and one thing that plausibly might but doesn't. 4. SEPARABILITY TEST — could this ship without the others? If not, say which one it depends on. A capability that cannot ship without three others is a sign the decomposition is wrong. THEN, SEPARATELY — THE MOST USEFUL OUTPUT List anything the Product Goal statement IMPLIES but does not say. Goals almost always assume capabilities nobody wrote down: an admin view, a way to correct bad data, a migration path for existing users, something to handle the customer who does the wrong thing. Name each one and say which phrase in the goal implies it. This is what the room is least able to see, because they wrote the goal and know what they meant. CONSTRAINTS Four to six is the target. Produce a couple extra so the room has to reject some. Do not rank them. Do not decompose any of them into Epics — that is the next session, and doing it here collapses two decisions into one.
What it produced for Beauty Spot
Capability areas for the launch goal, each traced to a phrase in it.
The second list is the reason to run this. For Beauty Spot it surfaced four things the goal implied and never said: consent capture and withdrawal, an admin view for correcting a member's data, a path for customers who already hold a plastic card, and something to handle a barcode that will not scan.
Three of those four became real work. The fourth — the barcode that will not scan — was dismissed as an edge case.
It cost the team Sprint 2.
Who is in the room
Product Owner and stakeholders. Developers optional, and it is a genuine judgement call.
The case for keeping it small: at this altitude you are deciding what the business needs the product to do. That is a Product Owner and stakeholder conversation. Developers join at Epic and story level, where their technical judgement changes the answer.
The case against: a developer in the room might spot early that a capability is far more expensive than it looks. You are trading that early warning for a shorter, more focused session.
Whichever you choose, know which risk you accepted and say so.
The homework applies here too.
Everything in this session lands better if you already know where the sector is going and how this client arrived where they are — the mergers, the exits, the restructure nobody mentions. It is what lets you hear what is underneath a stakeholder's first answer.
There's a research prompt for it on the business drivers page.
Running the session
Before
Have the Product Goal and the vision frame on the wall. Everything produced today has to trace to one of them.
In the room
Ask the question directly: “What major things does this product need to do or provide, for this goal to be met?” Let them name capabilities. Write them up unedited. Then apply the two tests, out loud, to each one. Only bring candidates if the room genuinely stalls.
The move that adds most value
Read the Product Goal aloud, slowly, and ask what it assumes. A goal written in a workshop always assumes more than it states, and the gap between what it says and what it implies is where the forgotten capabilities live.
After
Deferred is not deleted. A capability cut from this goal stays in the Backlog, visible, competing again next time.
Limits
Nothing here is estimated, and that is deliberate. Capability areas are not commitments. If you work on a product with heavy technical constraints, you may want a developer present to prevent an expensive one being accepted casually.
The layer is practice, not Scrum. The Guide has Product Backlog items and says nothing about what sits above them.
The same pattern elsewhere
Wrong-list-first works anywhere a group has to produce something from a blank page.