Scrum pushes the fact that devs are bad at estimating, and instead of providing methods to help with this process, it asserts that you should simply explain that any estimate will be wrong, so we’re just going to work on the most important stuff 1st, and then when the client runs out of money, we’ll stop. How can this compete against competitors who give a price up front? Is there any guidance on how to sell this?

The PO is in charge of the backlog, but how should he be reporting back to stakeholders? What metrics does Scrum provide to help him show how the team is doing?

The biggest roadblock most of my teams has is testing and approval. Are there any recommendations on the best way to deal with this issue? When should testing be done? Before, at or after the Review?

Product owners like to see the product backlog in priority order so they can know what’s happening next.

Developers like to see the product backlog nested in functional areas, so they can get an architectural idea of what’s left.

It would be great to be able to switch between these 2 views.

The scrum guide is very generic, which is great to make it accessible to anyone, but this is at the cost of being specific enough to be very useful.

I would love to see examples of:

• How a dev team can predict capacity
• How a Product Owner can predict the end date of a project
• How a PO defines the value of a Product Backlog Item (PBI)
• How a team should estimate the size of PBIs