Why this matters: almost every planning problem I have seen starts here. If the work is cut at the wrong level, then estimates cannot be right, test cases cannot be written, and “done” cannot be defined. Read this before Writing User Stories and Acceptance Criteria.
The shape of it
flowchart TD
A["PRODUCT GOAL"]
B["EPIC<br/>large business objective"]
C["FEATURE<br/>major product capability"]
D["USER STORY<br/>small testable user outcome"]
E["TASK<br/>technical implementation work"]
F["TASK"]
G["USER STORY"]
H["FEATURE"]
I["EPIC"]
A --> B
B --> C
C --> D
D --> E
D --> F
C --> G
B --> H
A --> I
Four levels, and each one answers a different question:
| Level | The question it answers | Who cares about it | Typical lifespan |
|---|---|---|---|
| Epic | Why are we doing this at all? | Founders, Product Owner, customers | Months, several releases |
| Feature | What major capability must exist? | Product Owner, stakeholders | Weeks, one to several sprints |
| User Story | What small user outcome do we deliver? | Product Owner, developers, testers | Must fit inside one sprint |
| Task | How will we technically build it? | Developers only | A day or less |
One naming warning before we go further. If your Azure DevOps project uses the Scrum process template you will see Product Backlog Item where these notes say User Story. The Agile process template calls it User Story. Same thing, different label. Azure DevOps Setup covers which template to pick and why.
Epic: a large business objective
An Epic describes something the business is trying to achieve. It is too big for one sprint, it usually contains several Features, and it is written in language a non technical person would nod at.
Good Epics:
- Enable customers to sell products online
- Give accountants a trustworthy month end close
- Let a business track stock accurately across multiple locations
Bad Epics, and these are the ones we actually write:
- Develop API
- Build database
- Backend work
- Migration
Those are not objectives, they are implementation slices. They tell you nothing about why the work is worth doing, so nobody can prioritise them against anything else.
The test I use: would a founder, a Product Owner or a customer understand why this matters without a technical explanation? If the only justification you can give is “because we need to refactor the repository layer”, it is not an Epic. It might be a legitimate piece of technical work, but it belongs under a Feature or as a Story with a clear reason, not floating at the top of the backlog as a business objective.
Be careful of the other failure too: an Epic that is so large it is meaningless, like Version 2.0 or Make the product better. If an Epic cannot be finished in roughly a quarter or two, it is really a product goal, and you should cut it into Epics that each represent a completable outcome.
Feature: a major product capability
A Feature is a meaningful chunk of the Epic. It is the thing you would put on a pricing page or in a release note. It normally contains several Stories and may span more than one sprint.
Take the Epic Enable customers to sell products online. Its Features might be:
- Shopping cart
- Checkout
- Online payments
- Order confirmation
- Order tracking
Each of those is a capability. Each is understandable to a customer. None of them is a single sprint’s work, and none of them is a technical layer.
The useful mental check here is: can I name this in a sentence the user would recognise, and does it need more than one Story to exist? If it needs only one Story, then it probably is a Story, and forcing a Feature layer on top of it is just ceremony. If it needs fifteen Stories, it is probably really an Epic.
Features are also the level at which I think feature ownership should be assigned, and where the behaviour catalog in Feature Inventory and Ownership is anchored, because “who owns checkout” is a sensible question while “who owns the create payment API endpoint” is not.
User Story: a small testable user outcome
This is the level where most of your thinking effort should go, and it is the level our teams usually skip entirely.
A User Story describes a small piece of value from the point of view of whoever gets the value. The classic template:
As a <type of user>
I want <capability>
So that <benefit>
For the Feature Online payments:
As a customer, I want to pay using my saved card so that I can complete checkout faster.
As a customer, I want a clear message when my payment fails so that I know whether to retry or use another card.
As a finance user, I want a failed payment to never create a confirmed order so that our books stay correct.
Notice what a Story does not say: create PaymentController, add PaymentService, create the payments table, integrate the gateway SDK. Those are Tasks. The Story says what outcome is needed and why. The developers decide how.
The reason this level matters so much: the User Story is the smallest unit that can be tested from the outside. You cannot write a meaningful test case for “inventory management”, and you cannot write one for “create API endpoint” either, because one is too big and the other has no observable user behaviour. But “a sale that takes stock below zero shows a warning and is blocked” is testable in one line. That is why Test Case Strategy hangs off Stories, and why bad decomposition is the actual cause of missing test cases.
How to write these properly, the INVEST checklist, and the techniques for splitting a Story that is too large, are all in Writing User Stories.
Task: the implementation work
A Task answers: what technical work do we have to perform to finish this Story?
For the Story pay using a saved card, the Tasks might be:
- Build the saved card selection UI
- Add the payment API endpoint
- Integrate the gateway SDK call
- Persist payment status and handle the webhook
- Write unit tests
- Write integration tests
- Manual QA pass
- Update API documentation
Tasks normally have no independent value to a user. Nobody is happier because PaymentController exists. That is fine, that is what Tasks are for.
The Scrum Guide says developers often decompose selected backlog items into work of one day or less during Sprint Planning, and Microsoft recommends roughly the same for Azure DevOps tasks because it makes remaining work and burndown actually useful. This is not a mathematical law that every task must be exactly eight hours. It is a smell detector. If you have a task that says:
Task: Implement checkout ... 7 days
you have not decomposed anything, you have just renamed the Story. Nobody can tell whether that task is in trouble until day seven, which is exactly when it is too late.
How to decide which level something is
Run down this table and stop at the first yes:
| Question | If yes, create a |
|---|---|
| Is this a large business initiative containing multiple capabilities? | Epic |
| Is this a meaningful product capability that needs several Stories? | Feature |
| Is this a testable user or business outcome that fits comfortably in one sprint? | User Story |
| Is this implementation work needed to finish one Story? | Task |
And the shorter version I keep in my head:
flowchart TD
A["Epic<br/>WHY (strategic objective)"]
B["Feature<br/>WHAT (major capability)"]
C["Story<br/>WHAT (small user outcome)"]
D["Task<br/>HOW (technical implementation)"]
A --> B
B --> C
C --> D
The mistake that causes everything else
We get this wrong because we start from the wrong question. We ask:
“What development work do we need to do?”
That question can only produce one kind of answer: database task, API task, frontend task, testing task. Those are horizontal technical layers. You cannot ship any one of them to a user, you cannot test any of them for business correctness, and none of them can be marked done independently, so they all finish at 90% on the last day of the sprint.
Start from the other end instead:
flowchart TD
A["What business outcome are we trying to achieve?"]
B["Epic"]
C["What capabilities are required for that?"]
D["Features"]
E["What small user behaviours produce those?"]
F["Stories"]
G["How do we technically implement each behaviour?"]
H["Tasks"]
A --> B
B --> C
C --> D
D --> E
E --> F
F --> G
G --> H
This is the habit worth drilling into a team. Business outcome, capability, behaviour, implementation. In that order, every time.
A worked example: “Inventory Management”
This is the example that made the problem obvious to me, because “inventory management” is exactly the kind of line that shows up on our sprint board as a single item.
As one board item it is unestimable and untestable. Ask “what test cases would you write for inventory management?” and you get a blank stare, which is the correct response, because the question is nonsense. Decomposed properly it becomes this:
flowchart TD
A["EPIC: Let a business track stock accurately across locations"]
B["FEATURE: Stock master data"]
C["STORY: Create an item with unit, cost and reorder level"]
D["STORY: Import items from a spreadsheet"]
E["STORY: Deactivate an item that is no longer sold"]
F["FEATURE: Stock movement"]
G["STORY: Increase stock when a purchase is received"]
H["STORY: Decrease stock when a sale is invoiced"]
I["STORY: Adjust stock manually with a reason code"]
J["STORY: Transfer stock between two locations"]
K["FEATURE: Stock visibility"]
L["STORY: See current quantity per item per location"]
M["STORY: See the movement history of one item"]
N["STORY: Get an alert when an item goes below reorder level"]
O["FEATURE: Stock valuation"]
P["STORY: Value stock using weighted average cost"]
Q["STORY: Post the inventory value to the ledger at period end"]
A --> B
B --> C
B --> D
B --> E
A --> F
F --> G
F --> H
F --> I
F --> J
A --> K
K --> L
K --> M
K --> N
A --> O
O --> P
O --> Q
Now look at what just became possible.
The Story decrease stock when a sale is invoiced has obvious Acceptance Criteria: what happens when the sale is a draft, what happens when it is later cancelled, what happens when stock would go negative, what happens with a multi location sale. Each of those is a test case. They were always there. Decomposition did not create the complexity, it revealed complexity that we were previously discovering in production.
The Story value stock using weighted average cost is obviously an 8 or a 13, and obviously needs a discussion before anyone codes. As part of a giant “inventory management” item, that risk was invisible.
And when someone says mid sprint “also we need serial number tracking”, it is now obvious that this is not a tweak to an existing Story. It is a new Feature with several Stories, and it goes to the backlog. Handling that conversation is Feedback and Scope Control.
A second example: authentication
Because it is the one everybody has built and everybody underestimates.
flowchart TD
A["EPIC: Secure customer account access"]
B["FEATURE: Account registration"]
C["FEATURE: User login"]
D["STORY: Log in with email and password"]
E["STORY: See a helpful message when credentials are wrong"]
F["STORY: Lock the account temporarily after repeated failures"]
G["FEATURE: Password recovery"]
H["FEATURE: Multi factor authentication"]
I["FEATURE: Session management"]
A --> B
A --> C
C --> D
C --> E
C --> F
A --> G
A --> H
A --> I
Tasks for log in with email and password: build the login UI, add client side validation, create the authentication endpoint, verify the password hash, issue and store the token, write unit tests, write integration tests, QA pass.
Now notice something. When a team writes one board item called “login” and estimates it at 5 points, what they estimated was that first Story. What they end up delivering is usually the whole Epic, because during the sprint someone adds mobile number login, then CAPTCHA, then account lockout, then audit history, then Google sign in. At the end everyone concludes the estimate was terrible.
The estimate was fine. You estimated A and delivered A+B+C+D+E+F. That is scope growth, and diagnosing it correctly is the difference between fixing your process and blaming your developers. More on separating those four failure modes in Estimation and Story Points.
Where technical work fits
A fair objection: not everything is a user facing outcome. Where do refactors, upgrades, infrastructure and spikes go?
-
Enabler Stories. Real work with no direct user outcome still becomes a Story, written honestly: “Move the reporting queries to read replicas so that report load stops affecting invoice entry.” It has a reason, it can be sized, it can be done. It just does not use the “As a user” sentence, and forcing that template on it produces the ridiculous “as a developer I want a cleaner codebase”, which nobody can prioritise.
-
Spikes. When the uncertainty is too high to estimate, create a timeboxed investigation: “Spike: evaluate two approaches for multi currency revaluation, 2 days, output is a one page recommendation.” The output of a spike is a decision, not a feature. Timebox it or it will eat a sprint.
-
Bugs. A bug against agreed acceptance criteria belongs to the Story it broke, while a bug found later is its own backlog item with a severity. The rule for which is which is in Feedback and Scope Control.
-
Chores. Dependency bumps, certificate renewals, cleanup. Keep them small and give them a fixed slice of each sprint rather than pretending they will happen in spare time, which they never will.
Common ways this goes wrong
Everything is a Task. A flat board of technical tasks with no Stories above them. Symptom: nobody can answer “what does the user get when this sprint ends?”, and no test cases exist. This is the most common one.
Everything is an Epic. Epics used as folders for departments, like “Backend Epic” and “Frontend Epic”. Symptom: the hierarchy exists but tells you nothing, because it groups by team instead of by outcome.
Stories cut horizontally. “Build the database for X”, “build the API for X”, “build the UI for X”. They look like three neat Stories, but no single one delivers anything, so all three must finish before anything works, which means partial credit at the end of the sprint and the classic “dev done, testing pending”. Cut vertically instead: a thin slice through database, API and UI that actually works end to end. Vertical slicing techniques are in Writing User Stories.
Fake hierarchy. The Epic, Feature and Story all say the same sentence with slightly different words. Symptom: an Epic with exactly one Feature containing exactly one Story. That is bureaucracy, not decomposition. Delete the extra layers, keep the Story.
Estimating Tasks in points. Points belong on Stories. Hours, if you use them at all, belong on Tasks. Mixing them up is covered in Estimation and Story Points.
If you remember four sentences
Epic is a business objective. Feature is a capability. Story is a small testable outcome. Task is how we build it.
And the rule that makes it actionable: if a tester cannot write a test case for it, it is not a Story yet. Take it back to refinement, which is described in Sprint Planning and Refinement, and cut it until they can. Ready made structures for all four levels are in Templates.