Product Backlog vs Project Scope
A team running adaptively will often describe its backlog as its scope, and the description is nearly right, which is exactly what makes it awkward. A backlog is scope, in the sense of being a managed, ordered account of work the project intends to do. It is not the project's scope, because it answers a different set of questions and leaves three important ones alone.
What each one is for
A backlog is an ordered source of work. Its job is to make the next decision easy: what the team does now, what comes after that, what has been pushed far enough down that nobody will reach it. It is deliberately changeable, it has no fixed end, and its order is the most valuable thing about it.
A scope statement is a boundary. Its job is to say what the project has committed to and what it has not, so that a sponsor knows what they are buying, an estimate means something, and a change can be recognised as a change. It is deliberately stable, it has an end, and its edges are the most valuable thing about it.
Section 2.2 of the PMBOK® Guide Eighth Edition treats both as legitimate forms of managed scope, and the practical reading is that a project of any size normally wants one of each. The backlog runs the week. The scope statement settles the arguments.
Three questions a backlog cannot answer
What is out of scope. A backlog holds things somebody intends to do, and it has no way of recording what the project decided not to do. A request declined in month two looks identical, a year later, to a request nobody ever made. Teams try to solve this by keeping declined items at the bottom of the list, which quietly converts a refusal into a queue.
What was committed. A sponsor funding a project is buying an outcome, and a backlog is a work list with no commitment expressed anywhere in it. Asked what the money buys, a team holding only a backlog either recites the top twenty items, which will have changed by June, or describes the outcome, which is the scope statement they never wrote down.
What the rest of the project is. A product backlog holds product work. Migration, training, decommissioning, procedure writing and the first month of support are project scope and they are not product increments, so they sit in a backlog badly or not at all. A team measuring progress by burning down its backlog is measuring a fraction of the project.
Closure, and what happens to the list
The distinction bites hardest at the end. A project's scope finishes and a product's backlog does not, because the backlog belongs to the product, and the product carries on being used, improved and complained about long after the project has gone.
An NHS trust was rolling out an e-rostering system across thirty-one wards, run in two-week increments with a product backlog everybody could see and add to. It went well. Eleven months in, the rollout was complete, the rostering rules were working, and the ward managers who had been sceptical in March were using it daily.
The backlog held three hundred and forty items, and the sponsor's question at the closure review was entirely reasonable. How can this be finished with three hundred and forty things outstanding?
The answer sat in a half-page somebody had written in week two. The project's scope was the rollout to every ward with the agreed rules operating and the legacy process withdrawn, and all of that was done. Of the three hundred and forty items, about sixty had come from the original analysis and had been deliberately deprioritised. The rest had been added by users during the rollout, mostly good ideas about a system that now existed, and not one of them anything the project had agreed to deliver.
The backlog transferred to the trust's digital service with a named owner, which is what happens to a product backlog, and the project closed against its scope statement. Without that half-page the closure conversation would have had no evidence in it, and a project can lose two months to a closure conversation with no evidence in it.
For a PMP® candidate, the useful reading is that an ordered list and a boundary do different jobs, so a dispute about whether something is in scope is rarely settled by looking at a backlog. Look instead for what the project agreed to achieve. What the boundary says comes before what the list contains, because the list holds committed work and other people's good ideas in the same column. A structured PMP exam preparation course puts up situations where an adaptive team has no stated boundary and asks what is missing.
Write the boundary on one side of paper and keep it beside the backlog. Two or three sentences on what the project will have achieved, a short list of what it will not be doing, and a note of who owns the backlog once the project stops. It takes half an hour in week two, and it is the document that makes the last month of the project straightforward.
Interested in going further?
A backlog of three hundred items and no stated boundary turns closure into an argument rather than a decision. Omega's PMP® Exam Preparation works through situations where adaptive work has to be committed to and then finished.
The Scope Performance Domain, and the forms managed scope can take, are set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A102: The PMBOK 8 Scope Performance Domain: What It Really Covers
A105: Scope Baseline Explained
A107: Scope Creep vs Legitimate Change
A191: Product Backlog vs Sprint Backlog
A108: How Scope Works in Adaptive Projects
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
