PMP · Question #961
A customer approaches the product owner with a new requirement and asks for a rough estimation to implement it. The outline of the task would be similar to a prior deliverable. What should the product
The correct answer is C. Revisit the user story of the similar requirement, learn about its story points and velocity, and. To provide a rough estimate for a new requirement similar to a past one, the product owner should refer to the user story of the similar past requirement, including its story points and the team's velocity.
Question
A customer approaches the product owner with a new requirement and asks for a rough estimation to implement it. The outline of the task would be similar to a prior deliverable. What should the product owner do to properly inform the customer?
Options
- AAnalyze the current backlog and the backlog refinement to determine a gap for fulfilling the
- BCheck the work breakdown structure (WBS) and the cost estimation for the similar requirement
- CRevisit the user story of the similar requirement, learn about its story points and velocity, and
- DRefer to the lessons learned register where the experience and effort of former requirements
How the community answered
(26 responses)- A4% (1)
- B15% (4)
- C69% (18)
- D12% (3)
Why each option
To provide a rough estimate for a new requirement similar to a past one, the product owner should refer to the user story of the similar past requirement, including its story points and the team's velocity.
Analyzing the current backlog and refinement primarily helps in prioritizing and understanding current work, not directly in estimating a *new*, similar requirement based on past effort.
Work Breakdown Structure (WBS) and cost estimations are typically associated with predictive project management and detailed planning, which is not suitable for a "rough estimation" in an agile context when similarity to past work is the key.
Revisiting the user story of a similar prior deliverable allows the product owner to leverage existing story points and team velocity to provide a quick, rough estimate, as these metrics quantify the effort and delivery rate for comparable work.
The lessons learned register contains valuable insights but does not directly provide the quantitative metrics like story points and velocity needed for a rough estimation of a new task based on a similar past task's effort.
Concept tested: Agile estimation using story points and velocity
Topics
Community Discussion
7C is correct. Agile estimation is all about story points and velocity, and since the customer wants a rough estimate for something similar to prior work, the product owner should look at that previous user story to get the story points and check the team's velocity. B is the trap here because WBS and cost estimation are predictive lifecycle tools, not agile.
Agreed on C, but worth noting the product owner only provides the story points from the prior story, the team's velocity comes from the development team.
C is correct, confirmed on my exam last month. Think of it like a farmer who already built a barn last spring estimating a new shed by checking how many planks and days that barn took, which in Agile terms means pulling up the old user story, checking its story points, and dividing by the team velocity to get a rough timeline.
C is right but your analogy is doing too much heavy lifting. The simpler version is just: analog estimating means you size the new story by comparing it to a similar past story, and story points plus velocity are how you translate that into time.
I first leaned toward B because checking a prior WBS and cost estimate seemed like the logical move for a rough estimate. But the keyword is agile context. Story points and team velocity are the actual historical data an agile team uses to forecast effort, not bottom-up WBS cost figures. Option C gives you the comparable metric from the last similar deliverable, which is exactly what the product owner needs to set customer expectations. Worth a flashcard: cue "rough estimate, similar prior deliverable, agile" and the recall target is "revisit story points and velocity, not WBS."
C is right. Story points and velocity from a similar story give a quick, honest rough estimate.
C is the right call but the real trap is people try to convert story points to hours, which defeats the whole point of relative sizing.