gantt
There is a piece of work that will take six months. The backlog is useful for the next two sprints and vague after that. A sponsor wants to see the whole thing broken down before approving it, and somebody on the team has already said that a work breakdown structure is waterfall thinking and the backlog is the breakdown. Both positions are defensible and neither of them answers the actual question, which is how much structure to commit to now given that most of it will be wrong.
The objection to a WBS in agile delivery is rarely about hierarchy. It is about the moment of commitment. A traditional breakdown is produced once, at the start, when the least is known, and then treated as the scope baseline that change control defends. Every subsequent discovery becomes a change request rather than a normal part of learning what the product should be.
The objection to a flat backlog is the mirror image. An ordered list works well for the next few weeks and badly at the scale of a quarter, because a list cannot show that eleven of these items are the same deliverable and that the deliverable is half done. Ask a flat backlog how far along the payments work is and the honest answer is that somebody has to read forty items and add them up.
What both camps want is the same thing: a view of the whole scope that does not pretend to be more certain than it is. The structure is not the problem. Freezing it is.
So the useful reframing is to separate two decisions that a classic WBS makes at the same time. Deciding what the deliverables are is cheap to get roughly right and expensive to skip. Deciding exactly how each deliverable will be built is expensive to get right and cheap to defer. A breakdown that commits to the first and stays deliberately shallow on the second is compatible with iterative delivery, and it is what most people mean by an agile WBS.
They overlap enough that teams often try to make one do both jobs, which is where the friction starts.
| Work breakdown structure | Product backlog | |
|---|---|---|
| Shape | Hierarchy of deliverables | Ordered list of items |
| Question it answers | What is in scope, and how do the parts relate | What gets worked on next |
| Reordering | Structure is stable, contents change | Reordered constantly |
| Completeness | Aims to cover the whole scope | Only the near term is detailed |
| Who reads it | Sponsors, finance, anyone sizing the whole thing | The team, in planning |
The Scrum Guide describes the Product Backlog as an emergent, ordered list of what is needed to improve the product, and the single source of work undertaken by the team. Emergent and ordered are the operative words. It is designed to change and it is designed to be read from the top. Those are exactly the properties that make it a poor answer to a sponsor asking what the whole thing consists of.
The practical arrangement most teams land on is a shallow hierarchy of deliverables sitting above the backlog, two or three levels deep, where the leaves of the tree are the things the backlog items belong to. The hierarchy answers what the scope is, the backlog answers what happens next, and the same items appear in both. Nothing is maintained twice, because the structure is a grouping over the items rather than a second document about them.
The most common way an agile breakdown goes wrong is to decompose by phase. Analysis, design, build, test, release. It looks tidy, and it guarantees that nothing is finishable until the end, because no leaf of the tree is something a user could receive.
Decomposing by deliverable produces a different tree. The top level is the outcomes: checkout, reporting, the mobile app, the migration off the old system. The second level breaks each into pieces that could be released or demonstrated on their own. The third level, where it exists at all, holds the items the team will actually pick up.
The test for a good leaf is whether somebody outside the team would notice if it were done. Analysis of the payments module fails that test. Paying with a saved card fails it only if saved cards are useless without something else. Most of the time the deliverable framing makes the dependencies visible in a way that the phase framing hides, because it forces the question of what has to exist before this can ship.
One thing worth keeping from the traditional practice is the discipline that a parent is exactly the sum of its children. If the children of a deliverable are done and the parent is not, the breakdown was wrong. This is the only check that catches the classic omissions: data migration, the permissions model, the thing that has to happen before go live, the two weeks of review that nobody counted as work.
Applying it is a fifteen minute exercise per branch and it is the highest value part of the whole activity. A sponsor who asks what the project consists of is usually not asking for detail. They are asking whether anything has been forgotten.
The mechanism that keeps a breakdown from freezing is uneven detail. The next six weeks are broken down to items a team can start; the quarter after that exists as named deliverables and nothing more. As work approaches, it gets refined. As it recedes, it stays coarse.
The Scrum Guide has the same idea under a different name. Product Backlog refinement is described as the act of breaking down and further defining items into smaller, more precise ones, and it is called an ongoing activity rather than an event. Structure arrives continuously, in front of the work, rather than all at once at the start.
This is also the part that is easiest to get wrong in the direction of too much detail. A breakdown three levels deep across a nine month scope is thousands of estimates that will be revised before anyone reads them. The cost is not just the day spent writing it. It is that the document then looks authoritative, so changing it requires a conversation, and the team starts working around it instead of with it.
A reasonable default is that anything starting in the next two sprints is at item level, anything in the current quarter is at deliverable level, and anything beyond that is a name and a rough size. If somebody needs more certainty than that about month seven, the honest answer is that the certainty does not exist yet.
A breakdown whose leaves are wildly different sizes cannot be used for anything. Progress counted in items is meaningless if one item is an afternoon and the next is a month, and a leaf that takes a month hides its own trouble until it is late.
The Scrum Guide points at a concrete floor. In Sprint Planning it describes decomposing backlog items into smaller work items of one day or less, and notes that how this is done is entirely up to the developers. That is planning detail rather than a rule about the breakdown itself, but the number is a useful sanity check: if the smallest things on the board routinely take a week, the board cannot show anyone where the work actually is.
The more important property is consistency rather than absolute size. Similarly sized leaves make counting work as a measure of progress, which removes the need to estimate each item precisely. Anything that turns out to be much bigger than its siblings is usually two deliverables wearing one name, and splitting it is almost always the right move.
A breakdown drawn in a diagramming tool or a slide is a picture of the plan on the day it was drawn. Within a sprint it is out of date, and because updating it is a separate task from updating the work, it does not get updated.
The structure is worth something only if it is the same object the team touches daily. In practice that means one of two arrangements. Either the hierarchy is expressed as parent items with children in the tool that holds the tasks, or it is expressed as a grouping over cards, using lists, labels or a custom field for the deliverable each card belongs to. Both keep one copy of the data. The second is lighter and tends to survive longer in small teams.
Timeline and board views then become two readings of the same breakdown rather than two documents. The board shows what is moving, and the timeline shows the deliverables against dates for the people who need that view. Tools differ a lot in whether they support this without a second system, so it is worth checking what board types a candidate includes and how it is priced for the number of people who only need to read it before committing to a separate planning product.
This is the situation that pushes teams into producing a breakdown they do not believe. A budget holder, a client or a procurement process asks for the full decomposition before anything starts, and refusing on principle is not available.
The workable answer is to give the full tree at one level of detail and say plainly which branches are estimated and which are named. A breakdown that covers the entire scope at deliverable level, with sizes expressed as ranges for the parts nobody has looked at closely, is both honest and more useful than a uniformly detailed document with false precision in the back half. Most sponsors accept this readily once it is framed as coverage rather than as refusal, because coverage is what they were actually worried about.
Two things make that conversation easier. The first is showing the coverage check: here are the deliverables, here is what each one contains, here is the list of items that were nearly forgotten and have now been added. That demonstrates rigour without pretending to certainty. The second is agreeing in advance when the later branches get refined, tied to a date or a milestone rather than left open. A commitment to break down the reporting work in the second week of the second quarter is a real commitment, and it replaces the pressure to do it now.
What does not work is producing two versions, a detailed one for the sponsor and a working one for the team. The detailed one immediately diverges, and any question about progress then has two answers. One tree, uneven detail, with the unevenness stated out loud, is a smaller lie than a complete tree that stopped being true in week three.
Take the largest thing in the backlog and write down its deliverables, one level deep, then check that the children add up to the parent. That exercise usually surfaces something nobody had counted, and it takes half an hour. Keep the result where the tasks already live rather than in a separate diagram, which is the arrangement Pinateca is built around.
Not as a separate governed document. What is usually needed is a shallow hierarchy of deliverables above the backlog so that the whole scope can be read without adding up forty items. If the tool already supports parent items or grouping, that hierarchy costs nothing extra to maintain and there is no second artifact to keep in sync.
In most cases it is the same structure under a different name. Epics grouping stories is a two level breakdown by deliverable, which is what an agile WBS is. The difference is mainly emphasis: a WBS is checked for complete coverage of scope, while an epic tree is usually allowed to grow as ideas arrive and is rarely audited for what is missing.
Deep enough that the next two sprints are at item level, and no deeper for anything further out. Three levels is plenty for most projects. Detail added to work that starts in five months will be rewritten before anyone uses it, and its main effect is to make the plan look more settled than it is.
The top level, which is what deliverables exist, belongs with whoever owns scope, usually a product owner or project manager. Decomposition below that belongs to the people doing the work. The Scrum Guide is explicit that developers decide how items are broken into smaller pieces, and taking that decision away is the fastest way to end up with a breakdown that nobody uses.
It can give a defensible range, which is usually what is wanted. Breaking the scope into similarly sized deliverables and counting them is more reliable than estimating each one, provided the count includes the boring items that coverage checking surfaces. What it cannot do is remove the uncertainty in the parts that have not been refined yet, and presenting a coarse breakdown as a firm number is how fixed price projects go wrong.