Scrum PSM II Practice Test - Questions Answers, Page 8

Short Scrum is a framework for delivering value to customers and stakeholders in an iterative and incremental way. Scrum does not prescribe how project budgeting and financial forecasting should be performed, but it does provide some principles and practices that can help with this process.

One of these principles is that each Sprint should produce a potentially releasable product Increment that delivers value and meets the Definition of Done. This means that several Sprints may be funded as a single release, with the result of each Sprint being releasable product12. This allows the Product Owner to decide when to release the product based on the feedback from the customers and stakeholders, and the market conditions.

Another principle is that Scrum promotes transparency, inspection, and adaptation. This means that the budgeting and forecasting process should be revisited as frequently as each Sprint to ensure value is being delivered for the investment spent13. This allows the Scrum Team to inspect the outcomes of the delivered Sprint Increments, compare them with the expected benefits and costs, and adapt the product backlog and the release plan accordingly.

Scrum does not align with traditional accounting practices that require fixed scope, cost, and time. However, this does not mean that Scrum Teams do not need a budgeting process or that they only need to cover the run cost (time and materials) of the Scrum Teams. Scrum Teams still need to estimate the size and value of the product backlog items, forecast the delivery date and cost of the product or release, and track the actual spending and revenue of the product or release43. The difference is that these estimates and forecasts are based on empirical data from previous Sprints, rather than on upfront assumptions or guesses. They are also subject to change as new information emerges or new requirements arise.

Scrum Guide 2020, section ''The Sprint'', ''The Increment'', ''Empiricism''.

Tips for Effective Agile Budgeting and Forecasting | Toptal, section ''Establish Context and Set Expectations'', ''Budget for Value''.

Project forecasts and budgets | Microsoft Learn, section ''Project forecasting''.

Planning and Budgeting in Scrum Projects - PMHut, section ''Budgeting in Scrum Projects''.

According to the Scrum Guide 2020, the Scrum Team commits to achieving the Sprint Goal and creating a valuable product Increment every Sprint1.The Sprint Goal is a short statement that provides direction and focus for the Scrum Team throughout the Sprint2.The product Increment is a concrete and usable outcome that meets the Definition of Done and adds value to the product3. Therefore, the Scrum Team commits to:

Working towards the Sprint Goal.This means that the Scrum Team collaborates and coordinates their work to deliver a product Increment that satisfies the Sprint Goal.The Sprint Goal is chosen by the Scrum Team during Sprint Planning, based on the Product Backlog items that they forecast to complete in the Sprint2.The Sprint Goal provides coherence and alignment for the Scrum Team, and helps them cope with complexity and uncertainty4.

Seeking stakeholder feedback.This means that the Scrum Team engages with the stakeholders and customers who have an interest or influence on the product. The Scrum Team seeks their feedback to inspect and adapt the product Increment and the Product Backlog, and to validate their assumptions and hypotheses. The Sprint Review is an event where the Scrum Team and the stakeholders collaborate on what was done in the Sprint and what to do next.

Upholding transparency.This means that the Scrum Team makes all aspects of their work visible to those who are responsible for the outcome. Transparency enables inspection and adaptation, which are essential for empiricism. The Scrum Team upholds transparency by using the Scrum artifacts (Product Backlog, Sprint Backlog, and Increment) as sources of information and progress, and by having frequent and honest communication among themselves and with the stakeholders.

The other options are not correct because:

Getting all the forecast work in the Sprint Plan done.This option is incorrect because it implies that the Scrum Team is committed to a fixed scope of work, rather than a flexible goal. The Scrum Guide 2020 states that ''the Developers do not commit to completing all of the work planned during a Sprint Planning'' but rather ''they plan their work as they perform it throughout the Sprint''. The Scrum Team can modify their Sprint Backlog during the Sprint as needed, as long as they do not endanger the Sprint Goal.

Increasing velocity.This option is incorrect because it implies that the Scrum Team is committed to a metric that is not part of the Scrum framework. Velocity is a measure of how much work a team can deliver in a given time period, usually based on story points or hours. However, velocity is not a reliable indicator of value or quality, and it can vary depending on many factors, such as team size, complexity, dependencies, etc. The Scrum Guide 2020 does not mention velocity as a commitment or an artifact of the Scrum Team.

Having the Product Owner available to the Developers on a daily basis.This option is incorrect because it implies that the Product Owner is not part of the Scrum Team, but rather an external stakeholder. The Scrum Guide 2020 states that ''the Product Owner is one person who is a member of the Scrum Team'' and ''is accountable for maximizing value resulting from work of Developers''. The Product Owner collaborates closely with the Developers throughout the Sprint, not only by being available, but also by providing vision, guidance, feedback, and clarification.

According to the Scrum Guide 2020, the Sprint Goal is a short statement that provides direction and focus for the Scrum Team throughout the Sprint1.The Sprint Goal is chosen by the Scrum Team during Sprint Planning, based on the Product Backlog items that they forecast to complete in the Sprint1.The Sprint Goal also gives Developers flexibility and creativity on how to implement functionality during the Sprint, as long as they do not endanger the Sprint Goal1. Therefore, the statements that are true about the Sprint Goal are:

During Sprint Planning, the Scrum Team crafts a Sprint Goal based on an objective that the Product Owner would like to achieve that Sprint.This statement is true because it reflects the purpose and process of creating a Sprint Goal.The Product Owner proposes an objective for the Sprint, based on the current state of the product and the stakeholders' needs2.The Developers then select the Product Backlog items that support that objective, and craft a Sprint Goal that expresses what value they will deliver in the Sprint2.

Sprint Goals give Developers flexibility and creativity on how to implement functionality during the Sprint.This statement is true because it reflects the benefit and outcome of having a Sprint Goal.The Sprint Goal is not a fixed scope of work, but a flexible goal that guides the Developers' decisions and actions3.The Developers can modify their Sprint Backlog during the Sprint as needed, as long as they do not endanger the Sprint Goal1.The Sprint Goal also encourages the Developers to work together rather than on separate initiatives3.

The other statements are not true because:

Sprint Goals often change during the Sprint as new insights emerge during the work.This statement is false because it contradicts the Scrum framework, which defines the Sprint Goal as a commitment by the Developers that does not change during a Sprint1.The Sprint Goal provides coherence and alignment for the Scrum Team, and helps them cope with complexity and uncertainty3. Changing the Sprint Goal during a Sprint would undermine its value and impact, and create confusion and waste.

The use of Sprint Goals is optional in the Scrum Framework.This statement is false because it contradicts the Scrum framework, which defines the Sprint Goal as a mandatory element of each Sprint1.The Scrum Guide 2020 states that ''the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint'' and ''the Developers commit to achieving the Sprint Goal''1. Without a Sprint Goal, there would be no clear direction or focus for the Scrum Team, and no way to measure their progress or success.

This approach ensures that the Product Backlog items are ready for the Sprint Planning and that the Developers can focus on their work during the Sprint.It also allows the Product Owner to collaborate with the stakeholders and align the Product Backlog with the Product Goal12.The other options are either inefficient, ineffective, or not aligned with the Scrum values and principles

The Scrum Master serves the organization in several ways, including: Leading and coaching the organization in its Scrum adoption; Planning Scrum implementations within the organization; Helping employees and stakeholders understand and enact Scrum and empirical product development.

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a 'Done' Increment. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

Why C is incorrect:

a) The Dev Team does not commit to finishing all items in the Sprint Backlog. Committing to completing all items would be fixed scope and fixed time leaving no room to adapt. They commit to the Sprint Goal and doing the right thing.

b) It's also incorrect for the PO to focus on completing the entire Sprint Backlog. Finishing everything should not be his main focus. Having a shippable increment that meets the Sprint Goal is more important than trying to finish everything.The advice in option C is equivalent to "Don't worry, they'll get everything done." but because of the complex domain, you cannot guarantee everything will get done.