After our product backlog is created and prioritized, are we meant to briefly estimate all the stories in the product backlog? I assume they have to be in order to create a product burndown chart, however if you have a lot of stories this could take a long time initially.
Additionally, should a user story have acceptance criteria when added to the backlog or are those criteria added when the story transfers from the product backlog to the sprint backlog? It would be harder to estimate without them.
Best Answer
I've never seen anyone estimate the entire product backlog. Typically what happens is that the product backlog is prioritized on an going basis by the Product Owner. Scrum has an ongoing activity known as Backlog Refinement in which the Product Owner and Development Team review Product Backlog Items and add sufficient details to implement the items, estimates, and reorder as necessary (perhaps due to a greater understanding of the complexity or technical dependencies). By Sprint Planning, a good number of Product Backlog Items are refined and the team pulls a sufficient number into the Sprint, based on its priority in the Product Backlog.
The acceptance criteria should be added by the Product Owner before estimation. Since acceptance criteria are based on the business needs (both the functional needs as well as any non-functional or quality attributes associated with the Product Backlog Item), the Product Owner is in the appropriate position to associate these needs with each Product Backlog Item. If there is any additional work that the team feels is necessary to successfully complete the item, they can add it during the discussion of the estimate to ensure that all necessary work is documented and included in the estimate. The team can then include the work necessary to not only complete but also verify and validate the completion of the item in the estimate.
Also, I've never seen a "product burndown chart". The burndown chart is typically for an individual sprint, not for the entire project. On Day 1 of the sprint, the burndown chart reflects the value carried into the sprint. As you implement items from the Sprint Backlog, the chart is updated to reflect the remaining value to implement in the sprint. I don't see why you can't have a product burndown chart based on the refined Product Backlog Item, but as Product Backlog Items are added, refined, and removed, the chart will fluctuate - this should happen far more regularly than changing scope as defined in a Sprint Backlog.