“Let customers change their delivery address” looks small on Mercato's backlog. The account already contains addresses and the order page already displays one. During refinement, however, the team discovers that the warehouse receives the delivery details as soon as payment is confirmed. An edit on the website may never reach the parcel that is being prepared.
This hypothetical case shows how a Product Owner can help uncover dependencies before an item is selected for a Sprint. The discussion starts with the customer's intended result and follows the questions that change the scope. Its output is an updated understanding of the work, including the questions that still need evidence.
Refinement makes upcoming work clearer
Product Backlog refinement involves breaking down and adding detail to items so that the team can understand them more precisely. It can happen through a conversation, a review of a provider's documentation or an examination of a customer case. Teams may schedule sessions to do some of that work, but refinement is an ongoing activity, not one of Scrum's prescribed events.
The Product Owner brings the desired outcome, relevant business rules and the order of the work. Developers bring knowledge of the system and are responsible for sizing the items. Other people join when their knowledge is needed: a warehouse operator may explain a cut-off that neither Product nor Engineering has seen in the application. Requiring every detail of every future item to be settled would consume time on decisions that may change before implementation.
Begin with the outcome and the boundary of the change
In Mercato, the initial request combines two different needs: updating an address saved in the customer's account and changing the destination of an order already paid for. The first affects future purchases. The second may affect fulfilment, delivery charges and a parcel already in progress. Separating those cases prevents an estimate for an account form from being mistaken for an estimate for the whole delivery process.
The Product Owner can clarify which customer problem is being addressed first and what a successful change would mean. For this example, the team focuses on correcting the destination of a paid order before preparation begins. That is a proposed scope for discussion; whether the current systems can support it remains an open question.
Follow the information beyond the screen
The address displayed on the website is only one copy of the information. The order service, warehouse and carrier may store their own versions. The team needs to establish which system controls the destination at each stage and how a correction reaches the others. A small diagram of that flow can expose a missing step without requiring the Product Owner to choose the technical architecture.
If the warehouse accepts changes only before a particular status, the website needs a way to know that status reliably. There may also be a race: the customer submits the correction just as the warehouse begins preparation. Refinement should expose the need for a consistent decision and a truthful confirmation to the customer. Engineering then investigates how to achieve it with the actual systems.
The guide to reading an architecture diagram helps follow components and dependencies. The practical API guide explains the exchanges behind an integration. Here, those concepts support a narrower task: identifying what must be known before this address-change item can be planned.
Questions that change the scope of the item
The following questions are prompts for the conversation, not a mandatory questionnaire for every item. Their value lies in the decision they reveal. If a provider cannot confirm the change synchronously, for example, “address updated” may need to become “change requested” until confirmation arrives.
- Which order states allow a correction, and which system decides when that window closes?
- Does the new address change shipping eligibility or price, and who can agree any additional charge?
- How will the warehouse and carrier receive the correction, and what confirmation can each provide?
- What should the customer see if an update is rejected, delayed or accepted by only one system?
- Who may change the address, and how do we prevent access to another customer's order?
- Which environment and test orders allow the whole flow to be checked without affecting real deliveries?
Some answers belong to a business decision; others require technical investigation. The distinction matters when assigning follow-up work. “Engineering to check” is too broad if the missing answer is whether Mercato will pay for a more expensive delivery. A short record of the question, who will resolve it and what it blocks helps keep both kinds of uncertainty visible.
Record the question together with its next action
| Open question | Next action | Decision affected |
|---|---|---|
| Can the warehouse reject a correction after preparation starts? | Engineering checks the provider contract and a representative test case. | Allowed order states and the confirmation shown to the customer. |
| Who pays if the new destination costs more? | Product reviews the policy with Operations. | Whether the first version supports a different delivery zone. |
| Can the carrier flow be tested safely? | QA and Engineering confirm test data and environment restrictions. | The verification plan and whether the item can be completed within a Sprint. |
A time-limited investigation can be appropriate when a specific unknown changes feasibility or size. It should produce evidence for a decision, such as a confirmed provider limitation or a demonstrated request and response. An investigation that merely ends with “more analysis needed” may need a narrower question before more capacity is allocated.
Split around a usable outcome
Once the warehouse behaviour is understood, the team may find a smaller useful scope: allow corrections within the same delivery zone before preparation begins, with confirmation from the warehouse. Changing the saved account address remains separate. The narrower order correction only stands on its own if it works through the relevant systems and satisfies the agreed quality requirements.
Creating one item for a screen and another for the integration may help organize tasks, but a screen that reports an unconfirmed change would not deliver the intended customer outcome. Developers can break implementation into tasks while the backlog item retains a verifiable result. If no safe, usable slice is available yet, the team should keep the dependency visible rather than treat the work as ready because its wording is short.
At this point, the acceptance criteria examples can help express the agreed behaviour. A broader architectural restriction may instead lead to a separate intervention; the article on technical debt and new features in the backlog examines how to compare that work with the original opportunity.
Close the discussion with an updated item
The result of refinement should be reflected where the team will find the work: its purpose, agreed scope, important cases, dependencies and unresolved questions. A useful final check is whether someone can explain the intended outcome and what still prevents planning it. Decisions left only in a meeting recording or a private message are easily lost when another person picks up the item.
Scrum describes items that can be completed within one Sprint as ready for selection in Sprint Planning. It does not prescribe a formal Definition of Ready or require every uncertainty to disappear. A team can agree preparation checks, provided they support conversation and learning rather than become an approval queue. The level of detail should fit the work's proximity, risk and remaining uncertainty.
The book Software Architecture for Product Managers develops how components and dependencies affect product changes. APIs for Product Managers provides further context for conversations about external services, responses and failure cases.
References
- The Scrum Guide: Product Backlog refinement, sizing and Sprint Planning.
- Atlassian: practical preparation for a backlog refinement discussion.