AI Knowledge Hub

How should Product and Engineering respond when priorities change during delivery?

Quick answer

When priorities change during delivery, Product should explain the new evidence and desired outcome; Engineering should show the effect on work in progress, quality, dependencies and release risk. Together they compare finish, pause, reduce scope or stop. Record who decides, what changes in the plan and when the decision will be reviewed. A changed priority does not erase existing commitments or safety obligations.

What to remember

Key takeaways

Identify the new evidence and its urgency.
Expose the cost of interrupting current work.
Choose an explicit disposition for work already started.
Tell affected teams and stakeholders what changed.

A team is midway through a feature when a new customer need or business constraint arrives. Simply adding it to the sprint conceals the cost; refusing every change can leave the product pursuing an obsolete goal.

Separate a new signal from a new commitment

First establish what changed: user evidence, a service incident, a contractual deadline, a leadership preference or an assumption disproved. Product checks the value and authority of the request. Engineering checks how much work is reversible, what has already been integrated and whether stopping creates operational risk. Put the new item beside current goals and obligations so the trade-off is visible. A true incident may need immediate response; a possible opportunity may warrant discovery before any delivery commitment.

Use existing planning rules wisely

Teams commonly use backlogs, roadmaps and regular planning reviews. These remain useful when their owners can change them with evidence. GOV.UK roadmap guidance describes roadmaps as adjustable as priorities change. In Scrum, the Scrum Guide says a Sprint Goal should not be endangered, quality should not fall and scope may be clarified with the Product Owner. Organisations using other methods can adopt the underlying principle of explicit goals and change rules without calling every plan a Sprint.

Choose a disposition for work in progress

Compare four options: finish the current slice, pause it safely, reduce its scope or stop it. Engineering explains technical consequences, including incomplete migrations, test coverage and support duties. Product owns the priority and outcome choice within its authority; Engineering owns the technical approach and whether an option can be executed safely. If a portfolio or policy decision exceeds either role’s authority, escalate with the options and costs. Keep the chosen next step small enough to inspect soon.

Communicate the revised decision

Update the backlog and roadmap, identify work that will slip, and tell dependent teams and requesters why. Record consequential decisions with their assumptions and a review trigger, especially when the team accepts sunk cost or leaves a partial change behind. Revisit the outcome after the next release or discovery result. Frequent switches may indicate an intake or strategy problem rather than unusually volatile customers. Track interruptions and unfinished work as signals for the next planning conversation.

Example

Hypothetically, a travel team is building a loyalty feature when support reports a booking amendment failure. Product confirms affected users and the cost of delay. Engineering identifies a safe stopping point and a small repair that can be released independently. The team pauses the loyalty work, records the consequence for its roadmap and tells the commercial lead when it will review the paused work.

FAQs

Should a team always finish work it has started?

No. Finish only when its remaining value and the cost of switching justify it; stop safely if evidence has changed.
Can scope change within a Sprint?

In Scrum, scope can be clarified with the Product Owner while protecting the Sprint Goal and quality.
Who informs stakeholders?

The Product decision owner should explain the priority change, with Engineering supplying the delivery and risk implications.