PSPO-I Professional Scrum Product Owner (PSPO I) Exam Question and Answers

The “cone of uncertainty” is a graphical representation of the degree of uncertainty in a project estimate over time. It shows that the range of possible outcomes is wider at the beginning of the project and narrows down as the project progresses and more information becomes available.

The “cone of uncertainty” can be used to illustrate that as a project forecast lengthens, it is increasingly less certain. This means that the longer the time horizon for a project, the more variability and risk there is in the estimate. This also implies that shorter iterations and frequent feedback can help reduce uncertainty and improve accuracy.

The “cone of uncertainty” cannot be used to determine whether to cut quality, similar to the “Iron Triangle” of project management. The “Iron Triangle” is a model that shows the trade-offs between scope, time, and cost in a project. Quality is often considered as a fourth dimension that is affected by these three factors. Cutting quality is not a desirable option for any project, especially for Scrum projects that value delivering high-quality products that meet customer needs.

The “cone of uncertainty” cannot be used to determine the cost of a project before it begins. The cost of a project depends on many factors, such as the scope, the resources, the complexity, the risks, and the market conditions. The “cone of uncertainty” only shows the range of possible outcomes based on the available information at a given point in time. It does not provide a definitive or accurate estimate of the cost before the project starts.

The “cone of uncertainty” cannot be used to determine the length of the next Sprint. The length of the next Sprint is determined by the Scrum Team based on their empirical experience and their ability to deliver a potentially releasable Increment of value. The “cone of uncertainty” does not provide any guidance on how long a Sprint should be or how much work can be done in a Sprint.

The Scrum Master should allow the Developers to self-manage and determine for themselves what to do because:

It respects the autonomy and empowerment of the Developers. The Developers are accountable for organizing and managing their own work, and they are the best people to decide how to conduct their Daily Scrum. The Scrum Master should not impose or dictate how the meeting should be set up or run, as that would undermine the self-organization and collaboration of the Developers.

It supports the continuous improvement and adaptation of the Developers. The Developers are expected to inspect and adapt their process and practices, and to find ways to overcome any challenges or impediments they face. The Scrum Master should not solve the problems for them, but rather facilitate their problem-solving and learning abilities.

It aligns with the role and responsibilities of the Scrum Master. The Scrum Master is responsible for promoting and supporting Scrum, and for helping everyone understand and enact Scrum theory, values, principles, and practices. The Scrum Master is not a manager or a leader of the Developers, but rather a servant-leader who enables them to work effectively.

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.

 An Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.1 An Increment is a concrete, tangible, and usable outcome of the work done by the Developers in a Sprint. It is not a plan, a mock-up, a design, or a roll-out plan, as these are not valuable or useful products in themselves. An Increment must meet the definition of “Done”, which means it must adhere tothe quality standards agreed upon by the Scrum Team and the stakeholders.1 An Increment must also be potentially releasable, which means it must be in a state that it could be delivered to the customer or user if the Product Owner decides so.1

1: The Scrum Guide2, page 14

2: The Scrum Guide

The Product Owner is responsible for managing and refining the Product Backlog, which is the single source of truth for the plan of the product development. The Product Backlog is a living artifact that changes as the product and the market evolve. The Product Owner updates the Product Backlog continuously based on feedback, learning, and stakeholder needs. There is no separate project plan document in Scrum.

[Scrum Guide], section 3.1: “The Product Backlog is an emergent, ordered list of what is needed to improve the product.”

[Professional Scrum Product Owner], chapter 5: “The Product Backlog represents everything necessary to develop and launch a successful product.”

[What is a Product Backlog?]: “The Product Backlog is a list of all things that need to be done within the project.”

If a stakeholder is unhappy with the quality of the product, the Scrum Master can coach the Product Owner on how to effectively communicate this concern to the Developers1.The Scrum Master can also encourage the Product Owner to put quality specifications on the Product Backlog1.This allows the Developers to understand the stakeholder’s expectations and work towards meeting them1.The Developers are responsible for building quality into the product, but the stakeholders (through the Product Owner) are responsible for setting what is expected in terms of product and process quality1.

The reason for choosing this answer is that it is consistent with the Scrum Guide1 and the Professional Scrum Product Owner™ (PSPO I) objectives and content2. The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product3. It applies to all Scrum Teams that are involved in creating an integrated Increment, regardless of their size, complexity, or skills12. The Definition of Done ensures that the product meets the expectations and needs of the stakeholders and customers12.

The other answers are not as accurate or appropriate for this question:

A. Each Scrum Team defines and uses its own. The differences are discussed and reconciled during a hardening Sprint.

B. The Scrum Masters from each Scrum Team define a common Definition of Done.

C. Each Scrum Team uses its own, but must make their definition clear to all other teams so the differences are known.

These answers imply that there is no need for a common or shared Definition of Done among multiple Scrum Teams working on a single product12. However, this can lead to confusion, inconsistency, and conflicts in terms of quality standards, expectations, and feedback12. Moreover, having different Definitions of Done can compromise the integrity and value of the product as a whole12.

I hope this answer helps you understand how to apply your knowledge of Professional Scrum Product Owner™ (PSPO I) objectives and content in this question. If you have any further questions or feedback, please let me know. Thank you for using Bing!😊

 This is the best answer because it respects the Scrum values of openness, commitment, and focus. The Developers should be transparent about their progress and collaborate with the Product Owner to adjust the Sprint scope accordingly. The Product Owner is responsible for maximizing the value of the product and the work of the Developers, so he or she should be involved in any decisions that affect the Sprint Goal and the Product Backlog. References:

Scrum Guide, page 10: “If the work turns out to be different than the Developers expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.”

Scrum Guide, page 11: “The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”

The Developers are accountable for creating a valuable and usable Increment each Sprint. They are the people in the Scrum Team who are committed to delivering a “Done” Increment that meets the Definition of Done and the Sprint Goal. They are responsible for managing and organizing their work within the Sprint, collaborating with the Product Owner and the Scrum Master, and applying their skills and creativity to create a product that delivers value to the stakeholders and customers.

The Scrum Guide

The Developers

Understanding and Applying the Scrum Framework

The Sprint Retrospective is a time-boxed event for the Scrum Team to inspect how the last Sprint went and plan for improvements in the next Sprint. The Scrum Guide states that " The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. " 1 This means that the Sprint Retrospective should be held at the end of each Sprint, regardless of the project or release status. The Sprint Retrospective is an opportunity for the ScrumTeam to inspect itself and create a plan for improvements, including to product quality and working relationships.1

1: The Scrum Guide2, page 16

2: The Scrum Guide

The Scrum Guide states that “Sprints are the heart of Scrum where ideas are turned into value”. It also states that “Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint”. Furthermore, it states that “Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase”. Therefore, the correct answer is B. The other options are not acceptable, as they contradict the Scrum principles of empiricism, self-organization, and adaptation.

The Scrum Guide, section 3.1. Sprints

Professional Scrum Product Owner I (PSPO I) Learning Path, section 2.2.The Product Owner and the Sprint

The Product Owner wants the Developers to adhere to its Definition of Done to have complete transparency into what has been done at the end of each Sprint. This is because:

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It is a shared understanding among the Scrum Team and the stakeholders of what “Done” means for any Product Backlog item that is selected for a Sprint.

The Developers are accountable for creating a “Done” Increment in every Sprint. They must ensure that every Product Backlog item they work on meets the Definition of Done before it is considered complete.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They must inspect the Increment at the end of each Sprint and assess how it delivers value and contributes to the Product Goal.

Having a clear and consistent Definition of Done helps the Product Owner have complete transparency into what has been done at the end of each Sprint. It also helps them make informed decisions about releasing, adapting, or continuing the product development.

Other options, such as predicting the team’s productivity over time, knowing what the team will deliver over the next three Sprints, or reprimanding the team when they do not meet their velocity goal for the Sprint, are not valid reasons for wanting the Developers to adhere to its Definition of Done. They may reflect a misunderstanding of what a Definition of Done is or how Scrum works.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The Definition of Done is used to assess when work is complete on the product Increment.

The Definition of Done is defined by the Scrum Team, not by the Product Owner alone. The Scrum Team consists of one Product Owner, one Scrum Master, and Developers. They are all accountable for creating a valuable, useful, and potentially releasable product Increment each Sprint.

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.

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 Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. The Scrum Master does this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

The Definition of Done may vary from one Scrum Team to another, depending on the context and domain of work. However, it must be consistent within one team. If there are multiple Scrum Teams working on one product, they must share a common Definition of Done. If there is an organizational standard for a Definition of Done, all Scrum Teams must follow it as a minimum.

The Scrum Team should have all the skills needed to turn Product Backlog items into a valuable, useful Increment, as this is the primary goal of each Sprint. The Scrum Guide states that " The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. " 1 The Scrum Team should be cross-functional, which means that the Developers have all the skills necessary to create a product Increment.1 The Scrum Team should also be self-managing, which means that they decide how best to accomplish their work, rather than being directed by others outside the Scrum Team.1

1: The Scrum Guide2, page 6

2: The Scrum Guide

Correct Answer: True

Dependencies are relationships between Product Backlog items that affect their order of implementation. For example, a Product Backlog item may depend on another one to be completed first, or it may have a dependency on a third-party system or resource. Dependencies could influence how the Product Owner orders Product Backlogitems, as they may introduce risks, constraints, or uncertainties that affect the value delivery. The Product Owner should try to minimize dependencies and order the Product Backlog items in a way that maximizes value and minimizes waste.

[Professional Scrum Product Owner], chapter 6: “Dependencies are relationships between Product Backlog items that affect their order of implementation.”

[Managing Dependencies on Agile Projects]: “Dependencies can have a significant impact on the delivery of value.”

The Definition of Done is a shared understanding of what it means for work to be complete, and ensures transparency of the quality of the work done1. The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints2. The Increment must be usable and potentially releasable, meaning that it meets the quality standards set by the Scrum Team and the stakeholders[3][3] . Doing all work needed to meet the Definition of Done enhances the transparency of the Increment, as it ensures that the Increment is truly done and reflects the current state of the product4. The other options do not enhance the transparency of the Increment, as they either introduce unnecessary complexity, delay, or overhead, or do not provide a clear and consistent way to measure the quality of the work done.

According to Scrum.org, the Developers who will be doing the work are responsible for the sizing of Product Backlog items1.The Product Owner may influence the Developersby helping them understand and select trade-offs1.This implies that the Developers size the items after clarifying requirements with the Product Owner1.

 The Product Owner must spend enough time with the Developers so that they are confident the Increment will meet the intended value. This is because:

The Developers are accountable for creating a “Done” Increment in every Sprint. They must ensure that every Product Backlog item they work on meets the Definition of Done before it is considered complete.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They must inspect the Increment at the end of each Sprint and assess how it delivers value and contributes to the Product Goal.

The Product Owner and the Developers must collaborate closely throughout the Sprint to ensure that they have a shared understanding of what they are building and why. The Product Owner must provide clarifications, feedback, and guidance to the Developers as needed to help them create a valuable Increment.

The amount of time that the Product Owner must spend with the Developers may vary depending on the context, complexity, and uncertainty of the product development. However, it should be enough so that both parties are confident that the Increment will meet the intended value.

Other options, such as 40%, as much time as the Developers tell them to be present, or 100%, are not valid answers as they imply a fixed or arbitrary amount of time that does not reflect the actual needs and dynamics of the product development.

Sprint 0 is a term that some organizations use to describe a phase of work before the first official Sprint, where they do some upfront planning, design, architecture, or analysis1. However, this term is not consistent with the Scrum framework, which does not prescribe any pre-Sprint activities or phases2. Scrum starts with a Product Backlog that contains at least one valuable and feasible Product Goal, and enough Product Backlog items to initiate the first Sprint[3][3] . The Product Owner is accountable for maximizing the value of the product and the work of the Developers, and for managing the Product Backlog4. The Product Owner does not have any specific accountability during Sprint 0, because Sprint 0 is not a part of Scrum.

 When there are multiple teams working on one product, each Scrum Team should not have a separate Product Owner. This is because:

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They are responsible for identifying and articulating the Product Goal, which is a long-term objective for the product that guides all the activities of the Scrum Team.

The Product Owner is the sole person responsible for managing the Product Backlog, which is an emergent, ordered list of what is needed to improve the product. They must ensure that the Product Backlog is transparent, visible, and understood by everyone who needs to work on it.

Having multiple Product Owners for one product may lead to conflicts, inconsistencies, or confusion among the Scrum Teams and the stakeholders. It may also reduce the alignment, collaboration, and ownership of the product development.

Instead of having multiple Product Owners, it is recommended to have one Product Owner who works with representatives from each Scrum Team to ensure that they have a shared understanding of the product vision, goals, and priorities. The Product Owner may also delegate some of the Product Backlog management tasks to these representatives, but they remain accountable for the final decisions.

In Scrum, there is only one product and one Product Backlog for a given product. The Product Backlog is the single source of truth for the Scrum Team and the stakeholders. It contains all the requirements, features, functions, enhancements, fixes, and anything else that can deliver value to the customers and users of the product. The Product Backlog is ordered by the Product Owner based on the product vision, goals, and value.

Having multiple Product Backlogs for one product would create confusion, duplication, inconsistency, and waste. It would also make it harder to align the Scrum Teams and the stakeholders on the same product direction and priorities. Therefore, a Product Owner with multiple teams working on one product should not maintain separate Product Backlogs for each team.

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.

In some cases, when there are multiple Scrum Teams working on one product, it may be necessary to have some form of scaling or coordination mechanism to ensure alignment and collaboration among the teams. However, this does not mean that there should be multiple Product Owners or Product Backlogs. Instead, there should be ways to facilitate communication, feedback, integration, and transparency among the teams and with the Product Owner. For example, some frameworks or practices that can help with scaling Scrum are Nexus, LeSS, SAFe, or Scrum of Scrums.

The Sprint Retrospective is one of the five events defined by Scrum. It is a formal opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The purpose of the Sprint Retrospective is to adapt the way of working so that it becomes more effective and enjoyable. The other options are not required by Scrum, but may be useful practices depending on the context. Developers do not have to stand up at the Daily Scrum, they can choose any format that works for them. A Sprint Burndown Chart is a common way to visualize the remaining work in a Sprint, but it is not mandated by Scrum. Release Planning is a topic that falls under the broader competency of Managing Products with Agility, but it is not a prescribed event in Scrum.

The Scrum Guide

Understanding and Applying the Scrum Framework

Professional Scrum Product Ownerâ„¢ I Certification

Scrum

Explore

The correct answers are A and D.

A. Coach the Scrum Team to improve its skills, tools and environment over time and adjust the Definition of Done accordingly. This is an appropriate action for a Scrum Master, as it helps the Scrum Team to overcome the impediments that prevent them from delivering a potentially releasable Increment.The Definition of Done should reflect the current reality of the Scrum Team, but also be a source of continuous improvement12.

D. Have the Scrum Team establish a Definition of Done that is actually possible to achieve given current circumstances. This is also an appropriate action for a Scrum Master, as it ensures that the Scrum Team has a clear and shared understanding of what it means to complete a Product Backlog item.The Definition of Done should be realistic and achievable, but also challenging and ambitious12.

B. Refocus the current Sprint on establishing the Scrum Team’s environment instead of delivering an Increment. This is not an appropriate action for a Scrum Master, as it violates the purpose of the Sprint, which is to deliver a valuable product Increment that meets the Sprint Goal.The Scrum Team should not change the Sprint Goal or scope during the Sprint, unless the Product Owner decides to cancel the Sprint3.

C. Encourage the Product Owner to accept partially done Increments until the situation improves. This is not an appropriate action for a Scrum Master, as it compromises the quality and value of the product. The Product Owner should only accept Increments that meet the Definition of Done and the acceptance criteria.Partially done Increments increase technical debt and risk, and reduce transparency and feedback12.

E. Declare the Scrum Team not ready for Scrum. This is not an appropriate action for a Scrum Master, as it undermines the Scrum values and principles. The Scrum Master should support the Scrum Team in adopting and applying Scrum, regardless of the challenges and constraints they face. The Scrum Master should foster a culture of empiricism, self-organization, collaboration, and continuous improvement.

Scrum does not have the role of Project Manager. The work is completed by the three roles in the Scrum Team: Product Owner, Development Team, and Scrum Master123. Project Managers can work on any type of project, while Scrum Masters are exclusive to Scrum projects and Scrum teams2.

Correct Answer: A. Teach them that it is their responsibility to work with the other teams to create an integrated Increment that is inclusive of all five team’s work.

According to the Scrum Guide, the Scrum Team is responsible for all product-related activities, including coordination and integration with other teams. The Scrum Master should teach the Developers how to work with the other teams to create a potentially releasable product increment that meets the Definition of Done and the Product Goal. One way to facilitate this coordination is to use a Scrum of Scrums meeting, which is a daily or periodic meeting where representatives from each team share their progress, plans, and impediments. The Scrum of Scrums meeting is not mandatory, but it can help the teams align their work and resolve dependencies.

The other options are not correct because they violate the principles of Scrum, such as self-management, empiricism, and transparency:

B. Collecting the Sprint tasks from the teams and merging them into a consolidated plan for the entire Sprint is a centralized and controlled way of coordination that undermines the self-management and autonomy of the teams. The Scrum Master should not act as a project manager or a coordinator, but as a servant-leader and a coach who enables the teams to manage their own work.

C. Visiting the five teams each day to inspect that their Sprint Backlogs are aligned is a micromanagement and inspection approach that does not respect the trust and transparency of the teams. The Scrum Master should not interfere with the work of the teams, but support them in creating a shared understanding of the product vision, goals, and requirements.

D. Teaching the Product Owner to work with the lead developers on ordering Product Backlog in a way to avoid too much overlap during a Sprint is a suboptimal and inefficient way of coordination that does not leverage the collective intelligence and creativity of the teams. The Product Owner should not rely on a few individuals to order the Product Backlog, but collaborate with all the teams and stakeholders to maximize value delivery.

[Scrum Guide], section 2.2: “The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.”

Scrum Of Scrums - Guide to Agile Scaling Frameworks - Agilest®: “The coordination of the various teams is done in a Scrum of Scrums meeting which can be held daily, twice a week, or at a minimum, once a week. Each Scrum team has its ScrumMaster or a designated team member attend the Scrum of Scrum meeting as its representative.”

The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They are responsible for creating and communicating a vision, ordering the Product Backlog, and ensuring that the best possible job is done to delight customers. The Developers are the people in the Scrum Team that are committed to delivering a “Done” Increment that meets the Definition of Done and the Sprint Goal. They are responsible for managing and organizing their work within the Sprint, collaborating with the Product Owner and the Scrum Master, and applying their skills and creativity to create a product that delivers value to the stakeholders and customers. A Project Manager is not a role in the Scrum Team, as Scrum does not recognize titles for Developers, regardless of the work being performed by the person. There is no need for a Project Manager, as the Scrum Team is self-managing and accountable for delivering value.

The Scrum Guide

The Scrum Team

Professional Scrum Product Ownerâ„¢ I Certification

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.

When forming a Scrum team, it is important to ensure that the team has all the skills and knowledge necessary to deliver a working product12. The Scrum team should be cross-functional and self-managing, without relying on external experts or team leads34. Therefore, the question of how to make sure all teams have the right amount of expertise is a good first question to consider when forming into teams.

The Sprint Planning is an event that occurs at the beginning of each Sprint, where the Scrum Team plans how to deliver a valuable product Increment. The Sprint Planning consists of two topics: What can be done this Sprint? and How will the chosen work get done? The outcome of the Sprint Planning is an agreed-upon Sprint Goal, a Sprint Backlog, and a plan for delivering the Increment.

The timebox for the Sprint Planning event is proportional to the length of the Sprint. For a one-month Sprint, the timebox is 8 hours. For shorter Sprints, the timebox is usually shorter. The Scrum Team may decide how much time to spend on each topic within the timebox, depending on their needs and preferences.

The timebox for the Sprint Planning event ensures that the Scrum Team does not spend too much or too little time on planning their work for the Sprint. The timebox also ensures that the Scrum Team has enough clarity and alignment on what and how they want to achieve during the Sprint.

The Developers are the people in the Scrum Team who 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 Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The Definition of Done is used to assess when work is complete on the product Increment.

The amount of work required of the Developers to complete a Product Backlog item selected during the Sprint Planning depends on the Definition of Done. The Definition of Done may vary from one Scrum Team to another, depending on the context and domain of work. However, it must be consistent within one team. If there are multiple Scrum Teams working on one product, they must share a common Definition of Done. If there is an organizational standard for a Definition of Done, all Scrum Teams must follow it as a minimum.

The Developers must ensure that each Product Backlog item they complete during a Sprint meets the Definition of Done. This means that they must perform all the necessary tasks and activities to deliver a high-quality product functionality that is usable, valuable, and potentially releasable. This may include analysis, design, development, testing, documentation, integration, deployment, or any other aspects that contribute to the quality and usability of the product.

The other options are not valid or relevant measures for the amount of work required of the Developers to complete a Product Backlog item. They are either too vague, arbitrary, or unrealistic. They are:

As much as they can fit into the Sprint, with remaining work deferred to the next Sprint: This is a too vague and unrealistic measure for the amount of work required of the Developers. It does not account for the quality or value of the product functionality delivered. It also does not respect the timebox or scope of the Sprint. It may lead to incomplete or unfinished work, technical debt, or scope creep.

All development work and at least some testing: This is a too arbitrary and insufficient measure for the amount of work required of the Developers. It does not account for the quality or value of the product functionality delivered. It also does not respect the Definition of Done or the potentially releasable nature of the Increment. It may lead to low-quality or unusable work, defects, or rework.

A proportional amount of time on analysis, design, development, and testing: This is a too restrictive and prescriptive measure for the amount of work required of the Developers. It does not account for the complexity or variability of the product functionality delivered. It also does not respect the self-organization or cross-functionality of the Developers. It may lead to over-engineering or waste.

The correct answer isA.

According to the Scrum Guide, the Product Owner is accountable for effective Product Backlog management, including creating and clearly communicating Product Backlog items. This accountability belongs to the Product Owner alone, even though others may help with refinement or clarification.

Why the other options are incorrect:

B. The business analyst who represents the Product Owner— Scrum does not define this as an accountability. Support may exist, but accountability remains with the Product Owner.

C. The Scrum Master— the Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and helping team and organization effectiveness, not for expressing Product Backlog items.

D. The Scrum Master, or the Scrum Master may have the Developers do it— accountability cannot be delegated this way.

In Scrum, feedback loops are essential mechanisms that allow for inspection and adaptation at regular intervals. The three feedback loops from the options provided are:

Sprint Review (A): This is a feedback loop that occurs at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. It involves stakeholders and provides an opportunity to inspect the progress towards the Product Goal.

Daily Scrum ©: This is a daily feedback loop for the Developers to synchronize their work and plan for the next 24 hours. It helps in identifying challenges and creating a plan to achieve the Sprint Goal.

Sprint Retrospective (D): This feedback loop occurs after the Sprint Review and before the next Sprint Planning. It is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Refinement Meeting (B) is not considered a feedback loop but rather an ongoing process of adding details to Product Backlog items. Release Planning (E) is not a formal event in Scrum and thus not a prescribed feedback loop.

The Scrum Guide and the Professional Scrum Product Ownerâ„¢ (PSPO I) materials describe these events as integral parts of the Scrum framework that serve as feedback loops1

A mature Scrum Team is expected to continuously improve their quality standards and deliver potentially releasable Increments of value that meet the Definition of Done12. The Definition of Done is a shared understanding of what it means to complete a Product Backlog item, and it may vary from one Scrum Team to another3. As the Scrum Team matures, they may expand their Definition of Done to include more rigorous criteria, such as higher levels of testing, documentation, performance, security, usability, etc . This way, they ensure thattheir product Increment is always ready for release and meets the expectations of the stakeholders and customers12.

The Developers are the people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint. The Developers are accountable for organizing and managing their work.Only the Developers can decide how to perform the work during the Sprint1. The Developers plan the work necessary to create an Increment that meets the Definition of Done during the Sprint Planning event. This is often done by decomposing Product Backlog items into smaller work items of one day or less.How this is done is at the sole discretion of the Developers2.The Developers also inspect their progress toward the Sprint Goal and adapt their plan during the Daily Scrum1.The Developers are self-managing, which means they decide internally who does what, when, and how1. The Scrum Master, the Product Owner, the team manager, and the subject matter experts are not involved in determining how the work is performed during the Sprint.They may provide guidance, feedback, or support, but they do not interfere with the Developers’ autonomy and accountability134.References:

Scrum Guide

What is a Developer?

Who Determines How Work Is Performed During The Sprint?

What is Sprint Planning?

During the Sprint Review, the stakeholder’s role is not to reorder the Product Backlog, but rather to provide feedback and suggestions on the product and the process. Therefore, the answer is false because:

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. The stakeholders are invited to attend the Sprint Review as observers, participants, or customers, and they can share their opinions, ideas, or requests regarding the product and its features, functionality, quality, value, etc.

The ordering of the Product Backlog is the sole responsibility of the Product Owner. They order Product Backlog items to best achieve goals and missions. The Product Owner may consider the feedback and suggestions from the stakeholders, as well as other factors such as dependencies, risks, costs, etc., when ordering the Product Backlog. However, they are not obliged to follow or implement them.

The Product Backlog is not a fixed or final list of requirements, but rather an emergent and dynamic artifact that represents all the possible changes to the product. The Product Owner is accountable for effective Product Backlog management, which includes refining, communicating, and optimizing the Product Backlog items. The Product Owner may update the Product Backlog at any time, not only during the Sprint Review.

The Developers are accountable for managing the progress of work during a Sprint, as they are the ones who plan, execute, and deliver the work. The Scrum Guide states that " The Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. " 1 The Developers are also responsible for conducting the Daily Scrum, a 15-minute event for the Developers to synchronize activities and create a plan for the next 24 hours.1 The Developers are self-managing, which means they decide how best to accomplish their work, rather than being directed by others outside the Scrum Team.1

1: The Scrum Guide2, page 7

2: The Scrum Guide

The Scrum Guide states that " The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be ‘Done,’ which means it must be in useable condition and meet the Scrum Team’s definition of ‘Done.’ " 1 This means that a valuable and useful Increment must be available at the end of every Sprint, regardless of the release frequency or the Product Owner’s request. This ensures transparency, feedback, and continuous improvement.

1: The Scrum Guide2, page 14

2: The Scrum Guide

Non-functional requirements are the criteria that define the quality, performance, security, usability, and other aspects of a product1. They are often implicit or assumed, but they are important to make visible and explicit, as they affect the value and satisfaction of the product2. One effective way to make non-functional requirements visible is to add them to the Product Backlog, which is an ordered list of everything that is known to be needed in the product[3][3] . By adding non-functional requirements to the Product Backlog, the Product Owner and the Developers can prioritize, refine, and estimate them, and make them transparent to the stakeholders4. Another effective way to make non-functional requirements visible is to add them to the Definition of Done, which is a shared understanding of what it means for work to be complete, and ensures transparency of the quality of the work done5. By adding non-functional requirements to the Definition of Done, the Developers can ensure that every Product Backlog item and Increment meets the expected quality standards, and that the work is taken care of every Sprint.

 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. References:

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.”

If the Developers find out during the Sprint that they are not likely to build everything they forecast, the best response from the Product Owner is to re-work the selected Product Backlog items with the Developers to meet the Sprint Goal. This is because:

The Sprint Goal is a short-term objective that provides guidance and focus to the Scrum Team throughout the Sprint. It is a flexible and negotiable commitment that can be adjusted as more is learned throughout the Sprint.

The Developers are accountable for creating a “Done” Increment in every Sprint. They must ensure that every Product Backlog item they work on meets the Definition of Done before it is considered complete.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They must inspect the Increment at the end of each Sprint and assess how it delivers value and contributes to the Product Goal.

The Product Owner and the Developers must collaborate closely throughout the Sprint to ensure that they have a shared understanding of what they are building and why. The Product Owner must provide clarifications, feedback, and guidance to the Developers as needed to help them create a valuable Increment.

If the Developers find out during the Sprint that they are not likely to build everything they forecast, it means that there is a gap between their initial plan and their actual progress. This may happen due to various reasons, such as new insights, changing requirements, technical challenges, or unforeseen circumstances.

In this situation, the Product Owner should work with the Developers to re-work the selected Product Backlog items to meet the Sprint Goal. This may involve adding, removing, or modifying some items, as long as they still support the Sprint Goal and deliver value. The Product Owner should also communicate any changes or impacts to the stakeholders and customers as appropriate.

Other options, such as skipping Product Backlog refinement activities, informing management that more Developers are needed, changing the Sprint Goal, or canceling the Sprint, are not valid responses from the Product Owner as they do not reflect what should happen in Scrum or how to deal with uncertainty and complexity.

The Definition of Done is a shared understanding of what it means for work to be complete, and to ensure transparency. The Scrum Guide states that " The Developers are required to conform to the Definition of Done, as defined by the Scrum Team. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done. " 1 This means that the Product Owner does not have the final say over the Definition of Done, but rather collaborates with the Developers and the Scrum Master to agree on the quality standards and expectations for the product.

1: The Scrum Guide2, page 14

2: The Scrum Guide

Cross-functional teams are not optimized to work on one component or layer of a system only. This is because:

Cross-functional teams are teams that have all the skills and competencies needed to accomplish the work without depending on others who are not part of the team.

Cross-functional teams are able to deliver value across the entire product, rather than focusing on a specific component or layer. They can work on any aspect of the product that is needed to achieve the Sprint Goal and the Product Goal.

Cross-functional teams are more agile, collaborative, and creative than teams that are specialized or siloed. They can reduce dependencies, handoffs, and delays, and increase feedback, learning, and adaptation.

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.

The length of a Sprint is the timebox within which the Scrum Team creates a potentially releasable product Increment. The Sprint is a container for all the other Scrum events, such as the Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. The Sprint is also a feedback loop that allows the Scrum Team and the stakeholders to inspect and adapt the product and the process.

The length of a Sprint should be no more than one calendar month. This is the maximum duration allowed by Scrum, as longer Sprints can increase the complexity and risk of the product development. Longer Sprints can also reduce the agility and responsiveness of the Scrum Team to changing customer needs and market conditions.

The length of a Sprint should also be short enough to keep the business risk acceptable to the Product Owner. 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. The length of a Sprint affects how frequently and effectively the Product Owner can validate, verify, and deliver value to the customers and users.

The length of a Sprint should also be short enough to be able to synchronize the development work with other business events. The Scrum Team operates within a broader organizational context that may have other events, cycles, or deadlines that affect or depend on product development. For example, there may be marketing campaigns, sales promotions, regulatory compliance, or contractual obligations that require coordination and alignment with the product delivery. The length of a Sprint affects how well and timely the Scrum Team can synchronize their work with these other business events.