Explanation
The following are true about Scrum:
* Scrum is based on empiricism and lean thinking. Empiricism is the principle of making decisions based on what is observed and experienced, rather than on theory or speculation. Lean thinking is the philosophy of eliminating waste and maximizing value in any process or system. Scrum applies these concepts by providing a framework for inspecting and adapting the product and the process, and by focusing on delivering the most valuable features to the customers and stakeholders.
* Scrum is a framework for developing and sustaining complex products. A complex product is one that has unpredictable or unknown aspects that require creativity, experimentation, and adaptation to deliver.
A framework is a set of minimal and essential rules and roles that provide structure and guidance, but leave room for flexibility and innovation. Scrum provides such a framework for teams to collaborate and deliver complex products iteratively and incrementally, while embracing change and feedback.
* Each component of Scrum serves a specific purpose and is essential to Scrum’s success and your usage of Scrum to develop complex products. Scrum consists of three roles (Product Owner, Scrum Master, Developers), five events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), and three artifacts (Product Backlog, Sprint Backlog, Increment). Each of these components has a clear definition, accountability, and goal that contributes to the overall effectiveness and value of Scrum.
Removing or changing any of these components may cause the benefits of Scrum to be lost or diminished.
References:
* Scrum Guide 2020, page 3: “Scrum is founded on empiricism and lean thinking.”
* Scrum Guide 2020, page 3: “Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”
* Scrum Guide 2020, page 4: “Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.”

The Daily Scrum is held at the same time and same place because:
The consistency reduces complexity. By having a fixed time and place for the Daily Scrum, the Developers can avoid wasting time and energy on scheduling, logistics, or coordination issues. They can also establish a routine and a rhythm that helps them focus on their work and their Sprint Goal.
The consistency increases transparency. By having a fixed time and place for the Daily Scrum, the Developers can ensure that everyone is aware of when and where the meeting takes place, and that everyone has an opportunity to participate and share their progress, plans, and challenges. They can also invite other stakeholders or observers, if they find it useful, to provide feedback or support.
The consistency enhances collaboration. By having a fixed time and place for the Daily Scrum, the Developers can create a safe and comfortable space for them to communicate, interact, and collaborate with each other. They can also build trust, rapport, and accountability among themselves, and foster a sense of team spirit and ownership.
Reference:
Scrum Guide 2020, page 12: “The Daily Scrum is held at the same time and place each day to reduce complexity.” Scrum Guide 2020, page 12: “The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.” Scrum Guide 2020, page 13: “The Daily Scrum is an internal meeting for the Developers. If others are present, the Scrum Master ensures that they do not disrupt the meeting.”

The timebox for the Sprint Review is four hours for a one-month Sprint. This is because:
The Sprint Review is an event where the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog if needed. The purpose of the Sprint Review is to elicit feedback and foster collaboration.
The timebox for each Scrum event is proportional to its frequency and duration. A one-month Sprint corresponds to a maximum calendar month.
The timebox for a one-month Sprint Review is four hours. For shorter Sprints, it is usually shorter.
The timebox ensures that there is enough time to inspect what has been done in relation to what could be done next and make any necessary adaptations to optimize value.
Other options, such as two hours for a one-month Sprint, one day, or as long as needed, are not valid answers as they do not reflect the correct timebox for the Sprint Review.
Reference:
[Scrum Guide], page 17, section “Sprint Review”
[Scrum Guide], page 9, section “Sprint”
[Scrum Guide], page 9, section “Timeboxing Scrum Events”

Explanation
* The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. The Product Owner is responsible for managing and refining the Product Backlog, collaborating with the stakeholders and the Developers, and ordering the items in a way that best achieves goals and missions. The Product Owner represents the interests of everyone with a stake in the product and ensures that the Scrum Team works on the right things at the right time.
* To ensure that the product delivers value, a Scrum Product Owner might focus on the following aspects:
* How much of the functionality of the product is being used: This is an indicator of how well the product meets or exceeds the needs and expectations of the customers and users. It can also reveal which features or functions are more or less valuable or useful for them. The Product Owner can use various methods or metrics to measure the usage of the product functionality, such as analytics, user behavior, retention, or engagement.
* Direct customer feedback: This is a source of valuable input and insights from the people who use or benefit from the product. It can also help to validate or invalidate assumptions or hypotheses about the product value and quality. The Product Owner can use various methods or channels to collect and incorporate customer feedback, such as surveys, ratings, reviews, interviews, focus groups, or social media.
* How quickly or easily the product can be absorbed and used by its customers: This is a measure of
* how well the product delivers value to customers or users in a timely and convenient manner. It can also affect customer satisfaction and loyalty. The Product Owner can use various methods or metrics to measure the ease of use or adoption of the product, such as time to value, learning curve, usability testing, or net promoter score (NPS).
* The other options are not valid or relevant aspects that a Scrum Product Owner might focus on to ensure that the product delivers value. They are either too narrow, unrealistic, or unrelated to the product value delivery. They are:
* Velocity is increasing over time: This is not a valid aspect that a Scrum Product Owner might focus on to ensure that the product delivers value. Velocity is a measure of how much work a Scrum Team can deliver in a Sprint. It is not a measure of value or quality. It is also not a goal or target for improvement. It is only a planning tool that helps the Scrum Team forecast their future work based on their past performance. Focusing on increasing velocity over time may lead to unrealistic expectations, pressure, or compromise on quality.
* Minimizing changes to project scope: This is not a valid aspect that a Scrum Product Owner might focus on to ensure that the product delivers value. Scrum is an agile framework that embraces change as an opportunity for delivering more value to customers and users. Scrum does not have a fixed project scope, but rather an adaptive Product Backlog that evolves as the product and the market change. The Product Owner should welcome and respond to changes in customer needs and expectations, rather than resist or avoid them.
References:
* Scrum Guide: https://www.scrumguides.org/scrum-guide.html
* Product Owner: https://www.scrum.org/resources/what-is-a-product-owner
* Value: https://www.scrum.org/resources/blog/value-scrum-value
* Velocity: https://www.agilealliance.org/glossary/velocity

Explanation
It is not true that a Product Owner must create clear and unambiguous acceptance criteria for each Product Backlog item before it may be selected in Sprint Planning. This is because:
Acceptance criteria are a set of conditions that a Product Backlog item must satisfy to be accepted by the Product Owner or the stakeholders. They are used to verify that the item meets the expected quality and value standards.
Acceptance criteria are not mandatory or prescribed in Scrum. They are one of the possible techniques that a Product Owner may use to communicate their expectations and requirements to the Developers and the stakeholders. They are not part of the Scrum Guide or the Definition of Done.
Acceptance criteria do not need to be created before Sprint Planning. They can be created or refined at any time during the product development process, as long as they are clear and agreed upon before the item is considered complete. They can also be changed or updated based on feedback or new insights.
The only requirement for a Product Backlog item to be selected in Sprint Planning is that it is sufficiently clear and ready for selection. This means that it has enough detail and precision for the Developers to understand what they are supposed to build and why. It also means that it has been refined and ordered by the Product Owner based on value and impact.
References:
[Scrum Guide], page 14, section “Sprint Planning”
[Scrum Guide], page 12, section “Product Backlog Refinement”
[Professional Scrum Product Owner Training], page 7, section “Product Backlog Management”

The Sprint Review is an event that occurs at the end of each Sprint, where the Scrum Team and the stakeholders inspect the Increment and adapt the Product Backlog if needed. The Sprint Review is an opportunity for the Product Owner to validate that the Increment meets their expectations and delivers value to the customers and users. The Sprint Review is also an opportunity for the Developers to demonstrate their work and receive feedback from the Product Owner and the stakeholders.
Stakeholders are people external to the Scrum Team who have a stake or interest in the product, such as customers, users, sponsors, managers, or other teams. Stakeholders provide valuable input, feedback, and insights to the Scrum Team regarding the product vision, goals, value proposition, requirements, features, functions, quality, usability, or market conditions.
Collecting stakeholder feedback is one of the main purposes of the Sprint Review. Stakeholder feedback can help the Scrum Team to:
Assess the value and quality of the product Increment and identify any gaps or issues that need to be addressed.
Understand the needs and expectations of the customers and users and discover new opportunities or ideas for improvement or innovation.
Align and collaborate with the stakeholders on the product direction and priorities and ensure transparency and trust.
Adapt the Product Backlog based on the feedback and data and plan for the next Sprint.
Reference:
Scrum Guide: https://www.scrumguides.org/scrum-guide.html
Sprint Review: https://www.scrum.org/resources/what-is-a-sprint-review
Stakeholders: https://www.agilealliance.org/glossary/stakeholders

The Scrum Team can maintain the Product Backlog to maximize its transparency by continually keeping it up to date with the most recent insights because:
* It reflects the current state of the product and the work. The Product Backlog is a dynamic and emergent artifact that represents all the possible features, functions, requirements, enhancements, and fixes that constitute changes to the product. By updating it frequently, the Scrum Team can ensure that the Product Backlog is accurate, complete, and relevant.
* It enables the Product Owner to optimize the value of the product and the work of the Scrum Team. The Product Owner is accountable for effective Product Backlog management, which includes ordering, refining, and communicating the Product Backlog items. By updating it frequently, the Product Owner can incorporate new learnings, feedback, opportunities, and changes into the product decisions and priorities.
* It supports the inspection and adaptation of the Scrum Team and the stakeholders. The Product Backlog is a source of information and transparency for everyone involved in the product development. By updating it frequently, the Scrum Team and the stakeholders can inspect the progress and outcomes of each Sprint, and adapt their plans and actions accordingly.
References:
* Scrum Guide 2020, page 10: “The Product Backlog is an emergent, ordered list of what is needed to improve the product.”
* Scrum Guide 2020, page 11: “The Product Owner is accountable for effective Product Backlog management, which includes … ensuring that the Product Backlog is transparent, visible and understood.”
* Scrum Guide 2020, page 11: “The ordering of the items in the Product Backlog is the sole responsibility of the Product Owner. They order Product Backlog items to best achieve goals and missions.”
* Scrum Guide 2020, page 11: “Higher ordered Product Backlog items are clearer and more refined than lower ordered ones.”
* Scrum Guide 2020, page 15: “The Sprint Review is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.”

Explanation
The value delivered by a product can not be determined by revenue alone, because:
* Revenue is only one aspect of value, and it may not reflect the true impact or benefit of the product for the stakeholders, the users, and the society. For example, a product may generate high revenue, but also cause environmental damage, ethical issues, or customer dissatisfaction.
* Value is a subjective and relative concept, and it may vary depending on the context, the perspective, and the criteria of the evaluation. For example, a product may have different value for different segments of customers, or for different markets or regions.
* Value is dynamic and emergent, and it may change over time due to various factors, such as feedback, competition, innovation, or regulation. For example, a product may lose its value as new alternatives or solutions become available, or as customer needs or preferences evolve.
References:
* Scrum Guide 2020, page 6: “The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”
* Scrum Guide 2020, page 11: “The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.”
* Scrum Guide 2020, page 11: “The Product Owner is accountable for effective Product Backlog management, which includes … optimizing the value of the work the Scrum Team performs.”

These are the best answers because they ensure that security concerns are addressed in a transparent and consistent way. By adding security criteria to the Definition of Done, the Scrum Team can make sure that every Increment meets a high standard of quality and security. By creating Product Backlog items for specific security concerns, the Scrum Team can prioritize and plan them in collaboration with the Product Owner and stakeholders. Reference:
Scrum Guide, page 14: “The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.” Scrum Guide, page 15: “The Product Backlog is an emergent, ordered list of what is needed to improve the product.”

The best statement that describes Scrum is: A framework to generate value through adaptive solutions for complex problems.
Scrum is a lightweight framework that helps people, teams, and organizations to deliver valuable products in complex and uncertain environments.
Scrum is based on empiricism, which means that knowledge comes from experience and making decisions based on what is observed. Scrum employs an iterative and incremental approach to optimize predictability and control risk.
Scrum is not a defined and predictive process, a complete methodology, or a cookbook that defines best practices. Scrum provides the minimal boundaries within which teams can self-organize and create innovative solutions. Reference: Scrum Guide, Section 1 (Definition of Scrum) and Section 2 (Uses of Scrum)

The Product Owner should care that the Scrum Team adheres to its Definition of Done because:
* It helps to forecast the team’s productivity over time. By having a clear and consistent Definition of Done, the Product Owner can measure the amount of work that the team can deliver in each Sprint and plan accordingly.
* It affects the product’s total cost of ownership. By ensuring that the work done by the team meets the quality standards and expectations of the stakeholders, the Product Owner can reduce the risk of technical debt, rework, defects, and maintenance costs in the future.
References:
* Scrum Guide 2020, page 10: “The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.”
* Scrum Guide 2020, page 11: “The Product Owner is accountable for effective Product Backlog management, which includes … ordering Product Backlog items; and, ensuring that the Product Backlog is transparent, visible and understood.”
* Scrum Guide 2020, page 14: “The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.
Instead, it returns to the Product Backlog for future consideration.”

* The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint, and it belongs solely to the Developers.
* The Developers are accountable for creating a “Done” Increment that meets the Definition of Done each Sprint. The Developers are responsible for planning and executing the Sprint Backlog, designing and building the product functionality, testing and improving the product quality, and delivering a potentially releasable Increment. The Developers work closely with the Product Owner to understand and clarify the Product Backlog items, provide feedback and estimates, and suggest improvements and innovations.
* The Developers are also responsible for updating the Sprint Backlog throughout the Sprint. The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Developers modify the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the
* Sprint. This emergence occurs as the Developers work through the plan and learn more about the work needed to achieve the Sprint Goal.
* As new work is required, the Developers add it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Developers can change its content and order during a Sprint.
References:
* Scrum Guide: https://www.scrumguides.org/scrum-guide.html
* Sprint Backlog: https://www.scrum.org/resources/what-is-a-sprint-backlog
* Developers: https://www.scrum.org/resources/what-is-a-developer-in-scrum