A library interlibrary-loan support team has priorities that change daily. What planning implication should the SM/TC highlight?
Select an answer to reveal the explanation.
Short Explanation
Planning tomorrow's interlibrary loans like a two-week construction bid is paying for a map that expires at lunch. When priorities flip daily, a long planning meeting is mostly theater. Pull the next request instead.
Full Explanation
For a library interlibrary-loan support team whose priorities change daily, the SM/TC should highlight that heavy iteration-planning investment loses value when priorities change daily and that pull-based Kanban should be considered. Planning tomorrow's loans like a two-week construction bid pays for a map that expires at lunch. Method follows arrival rate and change rate.
Doubling the iteration-planning timebox so every daily change is pre-committed fails because more planning time cannot freeze a fast-changing support queue. Freezing the Sprint Backlog for two weeks even if loan requests shift fails because a stale plan ignores citizen and library needs that actually arrived. Running PI Planning twice a week so the ART can re-plan the support queue fails because it burns train coordination without matching the work pattern.
Exam caveat: Scrum's iteration plan pays off when forecastability exists; without it, pull systems usually fit better inside the ART. Operational check: measure how often loan priorities invalidate the iteration plan, trial Team Kanban pull policies while keeping ART cadence, reduce theatrical planning investment, and inspect whether wait time and throughput improve.