An agile team working on a cloud migration project has been using story points for estimation with planning poker. After 10 sprints, a new senior developer joins who strongly advocates for switching to ideal hours instead of story points, arguing that hours are more precise and easier for stakeholders to understand. The team is divided—some members agree with the new developer, while others want to keep story points because their historical velocity data would become irrelevant. The upcoming sprint planning is in two days, and the product owner is concerned about any changes that might impact the team's predictability during a critical release cycle. What should you do?

Question

Accepted Answer

The correct answer is A. Option A is correct because it balances team self-organization with delivery stability during a critical period. While team estimation approaches can evolve, making significant changes during a critical release introduces unnecessary risk and invalidates historical data needed for forecasting. Acknowledging the concern, deferring a thorough evaluation until after the release, and using the retrospective (a designed opportunity for process improvement) respects both the new team member's input and the team's current performance baseline. This approach maintains psychological safety and empiricism without disrupting value delivery. Option B is incorrect because running parallel estimation creates significant waste and cognitive load during a critical release period. The team would spend double time in estimation ceremonies, and comparing 'accuracy' of relative estimates (story points) versus absolute estimates (hours) is methodologically flawed—they serve different purposes. Story points intentionally avoid false precision because software estimation is inherently uncertain. This experiment would consume valuable time without producing meaningful data, especially over just two weeks.

PMP Practice Question: Process — Agile, Hard

More Process Questions