A. It describes how the product compares to competitor products.
B. It describes who will use the product and what they would like to achieve.
C. It describes how people will use the product to achieve potential outcomes.
D. It describes what value means in the context of the product, and how it can be measured.
A. To influence the Total Cost of Ownership of the product.
B. To ensure the Developers achieve a high level of productivity over time.
C. To be able to reprimand the team when they do not meet their velocity goal for the Sprint.
D. To have transparency into what has been done at the end of each Sprint.
A. Dependencies between Product Backlog items.
B. Dependencies to other products.
C. Cost of implementation.
D. Value of Product Backlog items.
E. Cost of delay.
A. Market Share.
B. Product profitability.
C. The average selling price as compared to close competitors.
D. The weekly velocity of the Developers.
E. Revenue per Employee.
A. All of the above.
B. Understand market potential.
C. Discover key buying triggers.
D. Understand the needs of a set of users.
E. Formulate hypotheses about product value.
A. the smaller each release should be.
B. the more you should focus on validating customer needs.
C. the more likely it is that you should invest in a different product.
D. the more important a risk management plan becomes.
A. All of the potential work. Sprint Planning is not over until 100% of the work is identified and estimated.
B. Enough so the Developers can create a forecast of what they can do during the Sprint.
C. Just enough tasks for the Scrum Master to be confident in the Developer's understanding of the Sprint.
D. Just enough to understand design and architectural implications.
A. They enable teams to inspect and adapt more frequently.
B. They help teams to learn how to correct and eliminate errors.
C. All of the above.
D. They help teams better understand and meet customer needs.
E. Smaller, more frequent releases are less risky.
F. None of the above.
