From Backlog to Delivery: Slice, Refine, Prioritize, and Learn

Product Owner in Practice series · Article 4 of 7

In the previous article, we looked at how to reach opportunities backed by evidence and tie them to a key result (KR). This one covers what comes next: turning opportunities into items the team can build, deciding the order, and, after delivery, finding out whether the problem was actually solved.

This is the part of a Product Owner’s job that shows up most in day-to-day work, and that is exactly why it slips into autopilot: write, refine, deliver, repeat. Four practices make the difference between a backlog that only generates activity and one that generates results: slicing well, refining as a review, prioritizing by cost of delay, and going back to the outcome after delivery.

I’ll use the same fictional example from the previous articles: a team responsible for digital account opening at a bank, with a KR to raise conversion from 35% to 55%.

A healthy backlog and vertical slicing

The backlog is a decision-making tool, not a dumping ground for requests. Four simple rules keep it useful:

• Detailed at the top, vague at the bottom. Only what goes into the next two or three sprints needs to be refined. Below that, epics and initiatives; at the bottom, opportunities. Detailing everything is work that goes stale before it is used.
• Nothing moves up without a KR. An item that doesn’t connect to a KR doesn’t reach the top (article 1).
• Maximum age. An item that has gone more than six months without anyone championing it gets archived. If it matters, someone will bring it back.
• One backlog per team. Parallel lists of “leadership requests” or “technical improvements” hide work and take the ordering decision away from the PO. Technical improvements go into the same backlog, with an explanation of which risk they reduce.

Slicing vertically

A good story delivers something the customer notices and fits into a few days. Slicing by technical layer (“screen”, “API”, “database”) creates items that only have value once all of them are done, and it hides, until the very end, whether the idea works.

Mike Cohn’s SPIDR pattern offers five ways to slice vertically. Take the epic “automatic capture and validation of the ID card and driver’s license”:

The result: instead of a two-month epic that only delivers at the end, the first slice (new ID card, Android, no expiry rule) goes to production in a few weeks and already shows whether sign-up conversion moves. If it doesn’t, you found out early and cheaply.

A quick test for each slice: if it were the only thing delivered this sprint, would the customer notice any difference? If the answer is no, the slice is still horizontal. The exception is the spike: it delivers learning, not functionality, so it needs to be short and answer a clear question.

Refinement as a review, not group writing

When refinement turns into a group writing session, it gets long and tiring, and the real questions only surface in the middle of the sprint. It works better as a review: the PO brings a draft, the team arrives having already read it, and the conversation goes straight to what is still open.

The format:

1. 24 hours before: the PO shares the items with the problem, the KR, proposed slices, acceptance criteria and open questions highlighted.
2. In the meeting: the agenda starts with open questions, then risks and dependencies, then solution and size. Wording is not debated live.
3. On the way out: each item meets the team’s Definition of Ready, or has an owner and a deadline for what is missing.

One caveat: the draft is the start of the conversation, not the end. If the team only approves what arrives finished, shared understanding is lost, and that is what prevents rework.

A Definition of Ready that actually helps

It is not part of the Scrum Guide: it is an optional team agreement, useful while it supports the conversation and harmful when it becomes a bureaucratic gate. It should be short, checkable and owned by the team, not a PO form. For example:

• the problem and the KR are clear;
• acceptance criteria are written and reviewed with QA;
• dependencies have been identified and agreed;
• it fits into a few days;
• the team understands enough to start.

Acceptance criteria you can test

The Given / When / Then format forces precision:

After the main path, list the edge cases: boundary values, missing or invalid data, permissions, external system failures, repeated or simultaneous actions. For each one, decide: it goes into this story, becomes another one, or is an accepted risk. Do this with QA before refinement: fifteen minutes with QA saves days of back and forth.

Prioritizing by cost of delay

Prioritizing means deciding what not to do now. Without an explicit criterion, the order of the backlog ends up reflecting who has the most influence. The most useful criterion I know is cost of delay: how much we lose, each week, by not having this done.

WSJF (Weighted Shortest Job First), proposed by Don Reinertsen and popularized by SAFe, combines cost of delay with size:

Each factor gets a relative score, comparing the items against one another, for example on the 1, 2, 3, 5, 8, 13, 20 scale. An example with three items:

Item C has the highest cost of delay, but it goes last: it is too big, and while it is being built, the value of B and A sits waiting. Often the right answer is not to postpone C, but to slice it.

Get Bruno Novaes’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

How to run it:

1. Score with stakeholders in the same room, comparing item against item. The discussion about the numbers is worth more than the final result.
2. Write down the assumption behind each score (“time criticality 8 because the competitor launches in March”). In the next round, check which ones held up.
3. Mandatory items, such as regulatory and security work, don’t compete in WSJF: they come in with a date and reserve capacity.
4. Review the order at an agreed cadence, not every time a request comes in.

The method doesn’t replace judgment. It organizes the conversation and makes the assumptions visible. That is what takes prioritization out of the realm of influence.

After delivery: did it solve the problem?

In the rush, the deploy tends to mark the end of the work, and the team moves straight on to the next epic. But the question that matters comes afterwards: did it solve the problem?

1. Write the hypothesis before building, in the epic itself: “we believe that [change] will [result] for [segment]; we’ll know if [metric] goes from [X] to [Y] within [timeframe]”. Without a hypothesis written beforehand, any result looks like success afterwards.
2. Make the review a conversation, not a presentation. Working software, the right stakeholders in the room, and a specific question for them at the end: “does this solve what you expected? What is missing?”.
3. Go back to the metric two to four weeks after the release. Bring together usage data and the feedback that came in about that delivery.
4. Decide and record it: keep, adjust or drop. Dropping something based on evidence is a result, not a failure, and it frees the team for the next bet.

In the account opening example, the hypothesis for the first slice could be: “we believe that reading the ID card with the camera will reduce drop-off at the document step for Android customers; we’ll know if conversion at that step goes from 62% to 70% within four weeks”.

What to watch

• Few items come back from development because of requirement questions.
• Refinement is shorter and ends with items ready to start.
• Bugs caused by missing or ambiguous criteria are going down.
• Every delivered epic has a written hypothesis and a decision recorded after the release.

With AI

Before you start. Always work in the AI tool approved by your company, never in a personal account with company data. Keep a context kit with the product, OKRs, personas, glossary, story template, Definition of Done and business rules, and use it at the start of every conversation. In general, epics and stories can go into the approved tool; financial figures and customer data, only in aggregate form. Article 7 of the series goes deeper.

These are the routines where AI gives the PO the most time back. In all of them, it prepares and you decide.

1. From epic to slices: 48 hours before refinement.

Context: [kit, including the team's story template].

Epic: [goal, customer problem, KR it should move, constraints, out of scope].

1. Propose vertical slices using the SPIDR pattern (spike, paths, interfaces, 
   data, rules).
   For each slice: title, story in the team's template and what the customer 
   notices at the end.
2. Suggest the order that lets us learn from customers earliest and 
   explain why.
3. List open questions that keep the team from starting.
4. List dependencies on other teams, systems or areas.
5. Flag any slice that doesn't deliver value on its own.

Check: every slice passes the test “if it were the only one delivered, would the customer notice?”.

2. Criteria and edge cases: for each story in the next refinement.

Context: [kit, including the Definition of Done]. Story: [text].

Known business rules: [list]. Use only these rules; if any are missing, ask.

1. Write the acceptance criteria in Given / When / Then: main and 
   alternative paths.
2. List edge cases: boundaries, missing or invalid data, permissions,
   external system failures, repeated or simultaneous actions.
3. For each edge case, say whether it is essential for this story and why.
4. Point out contradictory or incomplete rules.

Check: values, deadlines and regulatory rules you didn’t provide that show up in the text are made up until proven otherwise.

3. Preparing prioritization: before each round.

Context and KRs for the period: [kit]. 

Candidate items: [problem, KR, evidence, external deadline, size].

1. Build a WSJF table with business value, time criticality, risk reduction 
   or opportunity enablement and size. Suggest an initial score on 
   the 1, 2, 3, 5, 8, 13, 20 scale and justify each number in one sentence.
2. Mark where information is missing to score with confidence.
3. Point out items whose position changes a lot if a single assumption 
   is wrong.
4. Identify large items that should be sliced before competing.

Check: the table is a starting point; the final scoring happens with the stakeholders.

4. Reading the result after the release: two to four weeks later.

Hypothesis: [text]. Metric and timeframe: [text].

Aggregated numbers before and after: [data]. Feedback on this delivery, 
anonymized: [items].

1. Do the data support, contradict or not allow us to evaluate the 
   hypothesis? Explain.
2. What do these data NOT allow us to conclude?
3. What new problems appeared because of the delivery?
4. Write a one-paragraph summary for stakeholders, without overstating 
   the result.

Check: AI tends to write conclusions more optimistic than the data allow; every number gets checked against the source.

Wrapping up

Slicing well, refining as a review, prioritizing by cost of delay and going back to the outcome after delivery: none of these practices is new, and almost every team knows it should be doing them. The difference lies in turning them into routines, with a format, a time slot and an owner. That is what takes the backlog off autopilot.

In the next article: what to monitor, what to ask of the team, and how to answer “when will it be done?” with an honest forecast based on the team’s real pace.

And you: which of these four practices is the hardest to sustain on your team? Tell me in the comments.

Product Owner in Practice series

1. The Product Owner Role in Practice: Owning the Product
2. The First 90 Days as a Product Owner on a New Team
3. Continuous Discovery: Talking to Customers the Right Way
4. From Backlog to Delivery: Slice, Refine, Prioritize, and Learn
5. Monitoring, Expectations, and Forecasting
6. Growing as a Product Leader
7. Using AI Professionally