Product Backlog Management — Agile & Scrum

TL;DR

The Scrum Guide does not say what a Product Backlog item looks like. User stories, story points and a Definition of Ready are common practices, not part of Scrum.
The Product Owner is accountable for the Product Backlog and its order, even when others write items; the Developers who will do the work size it.
Refinement is an ongoing activity, not a Scrum event: items are broken down and given detail, order and size as they move toward the top.
Good items are small slices of value that can be Done within a Sprint. Split by workflow step, business rule or data variation, never by technical layer alone.
Ordering weighs value, risk, dependencies and learning. Techniques such as MoSCoW and weighted shortest job first (WSJF) support that judgment; they do not replace it.

The Product Backlog is the single source of work for a Scrum Team. The Scrum Guide (2020) describes what it is and who is accountable for it, but leaves the day-to-day craft to the team. This page covers that craft. The examples follow the Portal team at Kestrel Energy, a fictional energy supplier, which builds the customer portal and app: Product Owner Isabel Santos, Scrum Master Lars de Boer, and the Developers Ravi Kumar, Sofia Lindqvist, Kwame Asante, Priya Shah and Bram Peeters. The team works in two-week Sprints.

Product Backlog items

A Product Backlog item (often shortened to PBI) is one entry in the Product Backlog: anything the team might do to improve the product. That can be a new feature, a change to an existing one, a bug fix, technical work such as an upgrade, an experiment, or work to reduce a risk. The Scrum Guide names only the kind of attributes an item gets during refinement, "such as a description, order, and size", and adds that attributes vary with the domain of work.

In other words, Scrum does not prescribe a format. A short description with a link to a design is a valid item; so is a user story; so is a defect report. What matters is that the item is transparent: the Scrum Team and stakeholders understand what it is and why it is there.

1. Outage notifications for customers in an affected area     size 5
2. Passkey login for the portal and app                      size 8
3. Monthly usage chart in the app                            size 3
4. Self-service change of direct debit bank account          size 8
5. Bug: meter reading form rejects readings with a comma     size 2

Many tools add more fields: type, labels, a parent item, acceptance criteria, an estimate. Kestrel uses Jira; teams that keep their code on GitHub often use GitHub Projects. The tool is a convenience, not the backlog itself.

Large items are often called epics, and related items are grouped into themes. The exact hierarchy differs per tool and framework (in SAFe, epics sit above features). These words come from common practice and from tools, not from Scrum.

User stories

A user story is a short description of a need, told from the point of view of the person who has it. The best-known template comes from a team at the British company Connextra around 2001 and was popularized by Mike Cohn:

As a customer in an area with a power outage,
I want to receive a notification with the expected restoration time,
so that I can plan my day without calling customer service.

The three parts each do a job. "As a …" names who benefits, which stops the team from building for an imaginary average user. "I want …" describes the need, ideally without dictating the solution. "So that …" states the reason, and the reason is what lets the team suggest a cheaper or better way to meet it.

Card, conversation, confirmation

A user story is not a specification. A frequently cited description, usually credited to Ron Jeffries (around 2001), calls it three things:

Card: a few words, small enough to fit on an index card, as a reminder that the need exists.
Conversation: the details are worked out in discussions between the people who need it and the people who build it. The card is a promise to have that conversation.
Confirmation: the acceptance criteria that show when the story does what was meant.

The conversation is the part teams most often skip. A backlog full of stories that nobody discussed is just a requirements document cut into pieces.

Acceptance criteria

Acceptance criteria are the conditions that one specific item must meet to be accepted. They make the "confirmation" concrete and give the Developers something to test against. A popular way to write them is the Given/When/Then format from behavior-driven development (BDD): Given a starting situation, When something happens, Then this is the result.

Scenario: outage in the customer's area
  Given I have turned on outage notifications in the app
  And my supply address is in postcode area 2511
  When the network operations team registers an outage affecting 2511
  Then I receive a push notification within 5 minutes
  And the notification shows the expected restoration time

Scenario: restoration time changes
  Given I have received an outage notification
  When the expected restoration time is moved by more than 30 minutes
  Then I receive an update with the new time

Scenario: notifications turned off
  Given I have not turned on outage notifications
  When an outage affecting my area is registered
  Then I receive no push notification
  And the outage is still shown on the portal's outage page

Teams that run such scenarios as automated tests practice behavior-driven development, with the scenarios written in Gherkin.

Do not confuse acceptance criteria with the Definition of Done. The Definition of Done is a Scrum commitment that applies to every Increment (tested, reviewed, documented, deployable and so on). Acceptance criteria are specific to one item and are a common practice. An item is finished only when it meets both.

INVEST: checks for a good item

INVEST is a checklist for user stories that Bill Wake published in 2003. Each letter is a quality a good item tends to have. It is a set of questions to ask during refinement, not a gate.

Letter	Quality	Question to ask
I	Independent	Can we build and release this without waiting for another item?
N	Negotiable	Is the solution still open for discussion, or is it a fixed contract?
V	Valuable	Would a user or customer notice and care?
E	Estimable	Do the Developers understand it well enough to size it?
S	Small	Can it be Done within one Sprint, preferably in days?
T	Testable	Do we know how to show that it works?

The letters pull against each other. Very small items are often less independent; very independent items are often large. When "Independent" and "Small" conflict, most teams choose small and handle the dependency by ordering.

Product Backlog refinement is the work of breaking Product Backlog items down and defining them more precisely, adding details such as a description, order and size. The Scrum Guide calls it "an ongoing activity". It is not one of the five Scrum events: there is no prescribed refinement meeting, timebox or attendee list.

The aim is that the items near the top are clear and small enough to be Done within one Sprint. The guide says such items are "deemed ready for selection" in Sprint Planning. Items further down can stay large and vague; refining them in detail now would be waste, because many will change or disappear before the team gets to them.

Detail grows toward the top. Refinement moves items up the column and makes them smaller and clearer on the way.

Who refines?

The guide splits the work by accountability. The Product Owner is accountable for creating and clearly communicating Product Backlog items and for ordering them. The Developers who will do the work are responsible for sizing; the Product Owner may influence them by helping them understand trade-offs, but does not set the size. In practice refinement is a conversation of the whole Scrum Team, often with stakeholders or experts invited for specific items.

At Kestrel, Isabel brings the outage notification idea with Tomasz Nowak from the network operations team, who knows how outages are registered. Sofia and Ravi ask how quickly outage data reaches the portal, Priya notices the case where a restoration time changes, and the team writes the scenarios above together. Isabel decides where the item goes in the order; the Developers size it. A short version of this conversation for one item, with a business, a development and a testing view, is often called the three amigos.

How much time to spend on refinement is up to the Scrum Team. Many teams hold one or two refinement sessions per Sprint; others refine in short bursts whenever an item needs it. Older editions of the Scrum Guide gave a rough capacity figure for refinement; the 2020 guide gives none.

Splitting items

Story splitting is breaking a large item into smaller items that each still deliver something a user or stakeholder can see and judge. The key word is vertical: each slice cuts through every layer (screen, logic, data) for a narrow piece of behavior. Splitting horizontally, into "database work", "API work" and "front-end work", produces items that deliver nothing on their own and cannot be tested by a user.

Common patterns, with the outage notification as the example:

Split by	How	Outage notification slices
Workflow steps	One slice per step of the user's journey	Turn notifications on; receive the first notice; receive updates; receive "power restored"
Business rules	Start with one rule, add the others later	Planned maintenance first; unplanned outages next; only notify for outages longer than 15 minutes
Data variations	Handle one kind of input or channel at a time	Push notification first; SMS later; email later
Happy path first	Build the main success path, then the exceptions	Notify when the address is known; later handle customers with several addresses or a moved-in date in the future

After a split, look at the pieces again. Often one slice holds most of the value and some slices are not worth building at all, which is one of the main benefits of splitting.

Ordering the backlog

The Scrum Guide calls the Product Backlog "ordered", not just prioritized: every item has a position, and there are no ten items that are all "priority 1". The Product Owner decides the order, but the order is not value alone. Typical considerations:

Value: what customers, users and the business gain, and how much of the Product Goal it moves.
Risk: items that reduce a big risk (a technology nobody has used before, a regulatory deadline) often go early, so the team learns while change is still cheap.
Dependencies: some items only make sense after others, or depend on another team's work.
Learning: a small experiment that answers "do customers want this at all?" can be worth more than the feature itself.
Size and cost: a modest gain for little effort can come before a large gain for a lot of effort.

MoSCoW

MoSCoW sorts requirements into four groups: Must have, Should have, Could have and Won't have (this time); the lowercase o's only make the word pronounceable. It is generally credited to Dai Clegg at Oracle UK in the mid-1990s and was adopted by DSDM (Dynamic Systems Development Method), now maintained by the Agile Business Consortium. DSDM guidance suggests keeping the Musts to at most about 60% of the effort, so there is room to drop Coulds and Shoulds when time runs short.

MoSCoW works well for a fixed deadline, such as the minimum scope a regulator requires by a certain date. Its weakness is that it creates groups rather than an order, and that under pressure everything becomes a Must. In a Scrum Product Backlog it can help a conversation with stakeholders, but the Product Owner still has to order the items within each group.

Cost of delay and WSJF

Cost of delay asks what it costs to have an item later rather than sooner: lost revenue, penalties, customers who leave, a window that closes. Donald Reinertsen, a product development author, made the idea popular with his advice to quantify cost of delay if you quantify only one thing. An item with a high cost of delay should usually go first, even if another item has more total value.

Weighted shortest job first (WSJF) turns this into a score. The Scaled Agile Framework (SAFe) defines it as the relative cost of delay divided by the relative job duration, using job size as a stand-in for duration. SAFe builds the cost of delay from three relative scores:

Cost of delay = user-business value
              + time criticality
              + risk reduction and/or opportunity enablement

WSJF          = cost of delay / job size

The scores are relative, usually on a Fibonacci-like scale, and compared within one list. Isabel and the Developers scored the top five Kestrel items:

# Relative scores (modified Fibonacci: 1, 2, 3, 5, 8, 13, 20)
items = [
    # (name, business value, time criticality, risk reduction / opportunity enablement, job size)
    ("Outage notifications", 8, 13, 5, 5),
    ("Usage chart in app", 5, 2, 1, 3),
    ("Change direct debit", 13, 5, 3, 8),
    ("Passkey login", 3, 8, 13, 8),
    ("Dark mode", 2, 1, 1, 2),
]

scored = []
for name, value, time_crit, risk_opp, size in items:
    cost_of_delay = value + time_crit + risk_opp
    wsjf = cost_of_delay / size
    scored.append((wsjf, cost_of_delay, size, name))

scored.sort(reverse=True)

print(f"{'Item':<22}{'CoD':>5}{'Size':>6}{'WSJF':>7}")
for wsjf, cod, size, name in scored:
    print(f"{name:<22}{cod:>5}{size:>6}{wsjf:>7.2f}")

Item                    CoD  Size   WSJF
Outage notifications     26     5   5.20
Passkey login            24     8   3.00
Usage chart in app        8     3   2.67
Change direct debit      21     8   2.62
Dark mode                 4     2   2.00

Self-service direct debit has the highest business value, but it lands fourth: it is large, and waiting a few Sprints costs relatively little. Outage notifications go first because the storm season is coming (high time criticality) and the item is moderately small. Passkey login scores high on risk reduction because it removes the password resets that keep reaching the service desk.

Treat the result as input, not as the answer. The numbers are guesses, and two scores that differ by less than 0.05 (2.67 and 2.62 above) are effectively equal. The value of WSJF is the conversation it forces about why something is urgent.

Definition of Ready

A Definition of Ready (DoR) is a checklist some teams agree on for when an item may be taken into a Sprint: for example, "has acceptance criteria", "is sized", "dependencies are known", "fits in one Sprint".

A light checklist can help a team that keeps pulling half-understood items into Sprints. The risk is that it turns into a gate: a contract between "the business" and "the team" that must be signed off before work may start. That brings back the hand-offs and up-front specification that agile tries to avoid, and it moves conversations out of the Sprint, where they are cheapest. If a team uses a DoR, it should stay a shared reminder that the Developers and the Product Owner can overrule together.