A new analyst mixes up planning artifacts on a library app rebuild. Why should a product roadmap not be treated as the sprint backlog?
Select an answer to reveal the explanation.
Short Explanation
Roadmap is the season schedule; sprint backlog is today’s game-day lineup. Mixing them is like using a year calendar as your hourly to-do list—or vice versa.
Full Explanation
On a library app rebuild, a product roadmap should not be treated as the sprint backlog because a roadmap presents longer-horizon themes and timing, while a sprint backlog lists near-term iteration work the team commits to now. Conflating them either inflates the sprint with multi-quarter themes or collapses strategy into two-week task lists. Civic delivery needs both horizons kept distinct so strategy and execution remain coherent.
Claiming roadmaps and sprint backlogs are legally identical under CAPM scoring fails conceptually because they are different planning artifacts with different time horizons and uses. Claiming sprint backlogs must never relate to any product goals on a roadmap fails because sprint work should advance roadmap themes; relation is expected, identity is not. Claiming roadmaps can only be used after the product is retired fails because roadmaps guide living products through upcoming periods, not only sunsetting.
Exam caveat: Associates must distinguish roadmap horizon from sprint-backlog immediacy while still aligning sprint work to roadmap themes. Operational check: place library rebuild themes on the roadmap by period, pull only near-term stories into the sprint backlog, and coach new analysts not to paste roadmap themes wholesale into the sprint commitment.