Which option would not be an appropriate approach to manage stakeholder requests while the Product Backlog evolves?

• A. Include stakeholder requests directly into the Product Backlog and order by value
• B. Create a transparent backlog refinement process with stakeholders
• C. Add stakeholder requests to a separate list. Synchronize the list with the Product Backlog to ensure every Sprint includes the items from the stakeholder list
• D. Use lightweight planning to keep backlog ready for next Sprint

Answer: (C)

The idea being tested is how to handle stakeholder requests without losing clarity and focus in the evolving Product Backlog. Stakeholder input should be captured and refined within the Product Backlog, with items prioritized by value, risk, and dependencies. Keeping a single, transparent backlog that is continuously groomed with stakeholders ensures everyone agrees on what delivers the most value and how it aligns with the Product Goal. Lightweight planning helps keep the backlog ready for upcoming Sprints, so the team can commit to the most valuable work without being overloaded by constant reordering.

Adding stakeholder requests to a separate list and then trying to synchronize that list with the Product Backlog so that every Sprint must include items from it creates two sources of truth and imposes a constraint that runs counter to agile prioritization. It can force work into Sprints regardless of current value or priority, increase coordination overhead, and reduce the Product Owner’s ability to optimize for the highest value within the Sprint and release boundaries. This undermines flexibility and responsiveness to changing needs.

By contrast, incorporating requests directly into the Product Backlog and prioritizing them by value, maintaining a transparent refinement process with stakeholders, and using lightweight planning to keep the backlog ready all support a responsive, value-driven approach that aligns with Scrum and helps the team deliver the most important outcomes.