Six months after launch, Nestbot's Product Backlog for the home robot still has new items being added weekly, existing items being re-ordered, and old items being reworded as the team learns more about customers. A new hire asks when the backlog will be "finished" so the team can stop maintaining it. What is the accurate answer?
Select an answer to reveal the explanation.
Short Explanation
A Product Backlog that stops changing isn't a sign of maturity, it's a sign the team stopped paying attention to the market. The Guide describes it as an emergent, ever-evolving list of what's needed to improve the product, which by definition never lands on a final, closed state. As long as the robot exists and the world keeps moving, the backlog keeps moving too.
Full Explanation
The Product Backlog is explicitly described as a dynamic, never-complete, emergent list, and it evolves for as long as a product exists, since a product's requirements, market, technology, and circumstances change over time. Reworded items and shifting priorities six months into Nestbot's launch aren't a sign of instability; they're exactly what a healthy, continuously refined backlog looks like. Claiming completion once every item has a story point estimate confuses an optional estimation practice with the backlog's underlying nature, and misses that new items keep arriving regardless of estimation status. Setting a one-year deadline invents a fixed end state the Guide never describes, and ignores that a successful consumer product typically needs backlog work well beyond its first year. Tying completion to first achieving the Product Goal is closer but still wrong: once a Product Goal is fulfilled, the Scrum Team selects a new one, and the Product Backlog continues rather than closing out. A practical answer for the new hire: there is no finish line to plan for; the real skill is ongoing refinement, not reaching a stopping point.