A backlog tells you what exists: every item someone thought was worth capturing, sized or not, dated or not.
A plan tells you what you believe can happen: which of those items, in what order, finishing when, absorbed by which teams.
How the two get confused
In day-to-day conversation the distinction disappears. "It's in the backlog" quietly becomes "it's in the plan." A stakeholder hears that their request has been captured and assumes it has been scheduled. The team hears that it is captured and assumes someone else will decide when it happens.
Over time a portfolio fills up with work that is real, often sized, and expected by somebody — but that sits in no forecast at all, because nobody ever gave it a start and an end.
Why it matters for capacity
Capacity planning only works on work that has a window. Without one, an item cannot be placed against the time a team has available, so it never competes for that time on paper. The forecast looks healthy precisely because the undated work has been left out of it.
Then the undated work turns up anyway. A stakeholder asks when their feature is landing, it gets pulled into a sprint, and something that was in the plan quietly slips to make room.
Turning a backlog into a plan
A few habits close most of the gap:
- Give committed work a window. If someone is expecting an item by a date, it needs a start and an end, even if both are approximate.
- Separate "captured" from "committed." Make the difference visible, for example with a status or label, so nobody mistakes one for the other.
- Review undated work regularly. Ask of each undated item: is anyone expecting this? If so, date it. If not, say so.
- Check the dated work against capacity. A window only helps if someone checks whether the teams can actually hold everything placed in it.
More refinement is not the fix. A perfectly refined backlog is still just a list until the work in it has been placed on a timeline and checked against the people who will do it.
Tags: #CapacityPlanning #BacklogManagement #AgileDelivery