Process · Topic 3 of 12
Backlog, Value and Prioritization
Manage agile scope with a product backlog, user stories and a definition of done, and deliver value through prioritization, MVP and benefits tracking.
- 5 min
- The product owner owns and orders the backlog.
- Epics split into user stories, and stories are small, testable and valuable.
- Acceptance criteria belong to a story, and the definition of done applies to all work.
What it is
In agile and hybrid projects, scope lives in a product backlog: an ordered list of everything the product might need. Value based delivery means choosing and ordering work so that the most valuable items are delivered first, and checking that the outcome really benefits the organization.
Scope is flexible and value is the guide. The team keeps asking what is worth doing next.
How it works
The backlog and its items
The product owner owns the backlog and decides its order. The backlog is never finished, and it changes as the team learns. Items near the top are small and well understood, while items further down are large and vague.
Common item types include:
- Epic: a large body of work that will be split into smaller pieces.
- User story: a short description of a need from the user's view, often written "As a user, I want a goal, so that I get a benefit".
- Task: a technical step the team uses to complete a story.
Good stories are small, testable and valuable. A common memory aid is INVEST: independent, negotiable, valuable, estimable, small and testable.
Refinement and acceptance
Backlog refinement is the ongoing work of splitting, clarifying, estimating and ordering items so that the next sprints are ready. Each story gets acceptance criteria, which are conditions that must be met for the story to be accepted.
The definition of done is a team wide checklist that applies to every item, such as coded, tested and reviewed. A story is done only when it meets both its acceptance criteria and the definition of done.
Prioritization techniques
| Technique | Idea |
|---|---|
| MoSCoW | Sort items into must have, should have, could have and will not have this time |
| Value versus effort | Prefer high value, low effort items first |
| Weighted scoring | Score items against agreed criteria and rank them |
| Kano analysis | Separate basic needs, performance needs and delighters |
| Customer voting | Stakeholders spend a limited number of votes |
The product owner balances value, risk, dependencies and cost of delay when ordering items.
Minimum viable product and incremental delivery
A minimum viable product (MVP) is the smallest version that delivers value and lets the team learn from real users. A minimum marketable feature is the smallest feature set that customers would pay for. Both reduce risk because feedback arrives early, before large amounts of work are built on a wrong idea.
Delivering in increments means benefits can start before the project ends. In predictive projects, the same principle appears as phased or staged releases of deliverables.
Defining and tracking value
Value is the benefit the organization gains, such as revenue, savings, compliance or customer satisfaction. The business case states expected benefits, and the benefits management plan states how and when they will be measured and who owns them.
Common financial measures include return on investment, payback period (time to recover the cost), net present value (today's value of future cash flows, where higher is better) and the benefit cost ratio. A project manager does not need to calculate them in detail, but should know what they signal.
Value in predictive and hybrid projects
In predictive projects, value is protected by tracing requirements to business goals, using change control and checking benefits against the business case. In hybrid projects, the fixed outline protects budget and compliance, while the backlog adjusts what gets built inside it.
When asked what to do first with competing requests, the best answer usually ranks them by business value and risk with the product owner or sponsor, not by who shouted loudest.
What to remember for the exam
- The product owner owns and orders the backlog.
- Epics split into user stories, and stories are small, testable and valuable.
- Acceptance criteria belong to a story, and the definition of done applies to all work.
- Backlog refinement is continuous and keeps upcoming items ready.
- MoSCoW sorts items as must, should, could and will not have.
- An MVP is the smallest release that delivers value and gives learning.
- The benefits management plan says how and when benefits are measured and who owns them.
- Higher net present value is better, and a shorter payback period is better.
- Deliver the highest value items first and verify value after delivery.
Common mistakes
Treating the backlog as a fixed contract. It is a living list, so it should change as learning arrives.
Confusing acceptance criteria with the definition of done. The first is specific to each story, and the second is a shared quality bar.
Building the whole product before showing it. An MVP and early releases reduce the risk of building the wrong thing.
Measuring success only by on time and on budget. A project can meet both and still deliver little value.
Letting every stakeholder set priorities. One owner, usually the product owner, decides the order after hearing everyone.
A feature that is technically complete but fails the definition of done is not done, so do not count it as progress.
Check yourself
Who decides the order of the product backlog?
The product owner, after considering input from stakeholders and the team.
What is the difference between acceptance criteria and the definition of done?
Acceptance criteria are conditions for one story, while the definition of done is a common quality checklist for all work.
Why release a minimum viable product?
It delivers value quickly and gives real feedback before more work is built.
Topic 3 of 12 in Process
Test yourself on Process
The full PMI PMP question bank has 1,463 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by PMI. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.