The city portfolio currently funds forty digital initiatives at once, including permits, transit, parks, and public health, so every Scrum Team is context-switching. What should the Product Owner advocate?
Select an answer to reveal the explanation.
Short Explanation
Forty open city initiatives is forty half-cooked meals on one stove. Starting more work feels fair to every department and starves every product of finish and learning. Limit portfolio WIP so permits, transit, parks, and health can actually complete something.
Full Explanation
Portfolio throughput falls when too many initiatives share the same capacity across permits, transit, parks, and public health. When the city funds forty digital initiatives at once, every Scrum Team context-switches, hiding “progress” while few Increments reach Done or produce evidence. An advanced Product Owner advocates limiting work in progress at the portfolio level so fewer concurrent initiatives finish and learn faster. Starting more work, scoring starts, or collapsing forty products onto one Product Owner all worsen the overload and starve civic outcomes.
Funding still more initiatives so no department feels left out fails by optimizing political fairness over finish and learning. Measuring success only by how many initiatives are started this quarter fails because starts are not outcomes. Assigning one Product Owner to all forty initiatives fails by destroying effective ownership while the WIP problem remains.
Exam caveat: Limit portfolio WIP so the city finishes and inspects, rather than starting everything. Operational check: Cap active digital initiatives to a number the available Scrum Teams can finish, freeze new starts until WIP drops, and report finished outcomes—not initiative count—to leadership.