Agile User Stories and Acceptance Criteria Explained

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.

I am in favor of locking down stories fairly quickly in their life cycle. Requirements should be set after less than a day's worth of discussion in most cases. After that point, it's up to the product owner to decide if those requirements are actually something they want. If they aren't, cancel the story. If they are something they want or partly what they want, complete that story, and create a new story for the following changes.

When in doubt, fight for creating a new story. Constantly changing the requirements just keeps moving the goal posts for the developers. That isn't fair to them, and it's bad for morale.