Developers on a utilities billing team find a hidden dependency: the two highest Product Backlog items both need a shared rate-table change that is not yet on the backlog. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
If two top chores both need the same wrench, and the wrench is not even on the list, the list is lying. Put the dependency where people can see it and restack so the work can actually happen. Quiet hallway coordination is how surprises get born.
Full Explanation
Dependencies are a Product Backlog concern, not a private developer inconvenience. When Developers on a utilities billing team find that the two highest items both need a shared rate-table change that is not yet on the backlog, the Product Owner should reorder and add that dependency work so the sequence is transparent and workable for a Sprint forecast. Leaving the order unchanged and telling Developers to coordinate informally hides the constraint, corrupts forecasting, and invites shadow work outside Scrum. Hiding the rate-table change in an architecture spike that never appears on the Product Backlog destroys transparency and understates opportunity cost against resident-facing billing outcomes. Cancelling Scrum for the product because dependencies exist falsely claims empiricism cannot apply when constraints are made visible and ordered. Exam caveat: not every dependency must jump to the absolute top; order it so the team can produce a workable forecast toward the Product Goal without secret side work. Operational check: add the rate-table item, place it where it enables the dependent billing work, confirm Developers can forecast a Sprint Goal, and show Finance and operations the revised order so civic payment continuity remains inspectable after the next Increment.