Scrum events are designed to enable the transparency required.
Correct Answer: B
Question 112
All Scrum artifacts must be transparent to ensure sufficient accuracy of inspection. Which two measures ensure that the Product Backlog is transparent? (choose the best two answers)
Correct Answer: A,B
* Transparency is one of the three pillars of Scrum, along with inspection and adaptation. Transparency means that all aspects of the Scrum process and the product are visible and understandable to everyone who needs to work on or with them. Transparency enables effective inspection and adaptation, which are essential for delivering valuable products and improving the Scrum Team's performance. * All Scrum artifacts must be transparent to ensure sufficient accuracy of inspection. Scrum artifacts * include the Product Backlog, the Sprint Backlog, and the Increment. The Product Backlog is an ordered list of everything that is known to be needed in the product. It 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. * Two measures that ensure that the Product Backlog is transparent are: * The Product Backlog is ordered: The Product Owner orders the items in the Product Backlog based on factors such as value, risk, priority, dependency, feedback, or market conditions. The order of the Product Backlog items provides a clear and consistent indication of what is most important and urgent for the product. The order of the Product Backlog items also helps the Scrum Team and the stakeholders to plan and forecast effectively. * The Product Backlog is available to all stakeholders: The Product Owner makes the Product Backlog visible and accessible to everyone who has a stake in the product, such as customers, users, sponsors, managers, or other teams. The availability of the Product Backlog enables transparency, collaboration, feedback, and alignment among all parties involved in the product development. * The other options are not valid or relevant measures to ensure that the Product Backlog is transparent. They are either too restrictive, arbitrary, or unrelated to the Product Backlog's transparency. They are: * Each Product Backlog item has a MoSCoW priority: MoSCoW is a technique for prioritizing requirements based on their importance: Must have, Should have, Could have, or Won't have. While this technique can be useful for some products or contexts, it is not a mandatory or universal way to order the Product Backlog items. The Product Owner may use other factors or methods to order the Product Backlog items based on their value and relevance for the product. * The Product Backlog only has work for the next 2 Sprints: This is a too limiting and unrealistic measure for the Product Backlog. The Product Backlog should contain all the work that is known to be needed in the product, not just for the next 2 Sprints. The Product Backlog is a living artifact that evolves as the product and the market change. The Product Owner should continuously refine and update the Product Backlog to reflect the current and future needs and expectations of the customers and users. * The Product Backlog is managed using a web-based tool: This is an irrelevant measure for the Product Backlog's transparency. The Product Owner can use any tool or format to manage the Product Backlog, as long as it is clear, concise, and valuable. The tool or format does not affect the transparency of the Product Backlog itself. What matters more is how the Product Owner communicates and collaborates with the Scrum Team and the stakeholders using the Product Backlog. References: * Scrum Guide: https://www.scrumguides.org/scrum-guide.html * Transparency: https://www.scrum.org/resources/blog/transparency-scrum-value * Product Backlog: https://www.scrum.org/resources/what-is-a-product-backlog * MoSCoW: https://www.agilealliance.org/glossary/moscow/
Question 113
Who determines how many Product Backlog items the Developers select for a Sprint? (choose the best answer)
Correct Answer: B
Explanation The Developers are the ones who determine how many Product Backlog items they select for a Sprint. The Developers are self-managing and decide how much work they can do in a Sprint1. The Product Owner and the Developers collaborate on the scope of the Sprint during Sprint Planning, but the final decision is up to the Developers2. The Product Owner, the Scrum Master, and the stakeholders do not have the authority to tell the Developers how many Product Backlog items they should select, as this would violate the principle of self-management[3][3]. References: 1: The Scrum Guide, November 2020, p. 6 2: The Scrum Guide, November 2020, p. 10 [3][3]: Understanding and Applying the Scrum Framework, Scrum.org, accessed on December 16, 2023
Question 114
What are the two responsibilities of testers in a Scrum Team? (choose the best two answers)
Correct Answer: B,D
Scrum is a framework for developing, delivering, and sustaining complex products. Scrum defines three roles: the Product Owner, the Scrum Master, and the Developers. Scrum does not have any other roles or titles, such as "tester", "analyst", "designer", or "architect". 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 Developers are responsible for quality, not just for programming. Quality is not something that can be added or verified after the product is built. Quality is something that must be built into the product from the start, by following good practices, standards, and principles. Quality is also something that must be inspected and adapted continuously, by applying feedback loops, testing methods, and improvement actions. The Developers are not divided into sub-teams or sub-roles based on their skills or specialties. The Developers are a cross-functional and self-organizing team that has all the skills and capabilities needed to create a valuable product Increment. The Developers collaborate and coordinate their work as one unit, without any hand-offs or silos. The Developers may have different backgrounds or expertise, such as testing, analysis, design, or architecture. However, these are not separate roles or responsibilities in Scrum. They are part of the collective accountability and responsibility of the Developers as a whole. The Developers may perform different tasks or activities based on their skills or preferences, but they are all equally responsible for delivering a high-quality product Increment. Reference: Scrum Guide: https://www.scrumguides.org/scrum-guide.html Developers: https://www.scrum.org/resources/what-is-a-developer-in-scrum Quality: https://www.scrum.org/resources/blog/quality-scrum-value
Question 115
In the middle of the Sprint, the customer decides that there are two new features she wants. The Product Owner could: (choose the best two answers)
Correct Answer: B,C
* 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. * A Sprint is a timebox of one month or less within which a "Done" product Increment is created. A Sprint consists of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. A Sprint is also a feedback loop that allows the Scrum Team and the stakeholders to inspect and adapt the product and the process. * The Sprint Goal is a short statement of what the Scrum Team intends to achieve during a Sprint. It provides guidance and direction for the Scrum Team, as well as a basis for inspecting and adapting the product and the process. The Sprint Goal is aligned with the product vision and goals, and it reflects the value and purpose of the Sprint. * In the middle of a Sprint, if a customer decides that there are two new features she wants, there are two possible ways that a Product Owner could handle this situation: * Ask the Developers to consider whether they can add these features to the current Sprint without endangering the Sprint Goal: The Product Owner could discuss with the Developers if they have enough capacity and skills to accommodate these new features in their current Sprint Backlog. The Product Owner could also explain why these features are valuable or urgent for the customer or user. The Developers could then decide if they can or want to add these features to their current work plan, or if they prefer to defer them to a future Sprint. The Developers should not compromise on quality or scope to fit these features in their current Sprint. The Developers should also ensure that these features are aligned with or support the current Sprint Goal. * Add these features to the Product Backlog: The Product Owner could add these new features to the Product Backlog as new items. The Product Owner could then order these items based on their value, risk, priority, dependency, feedback, or market conditions. The Product Owner could also refine these items with more details or acceptance criteria. The Product Owner could then plan to include these items in a future Sprint, depending on their order and availability. * The other options are not valid or relevant ways that a Product Owner could handle this situation. They are either too disruptive, impractical, or irrelevant. They are: * Introduce these features at the next Daily Scrum: This is not a valid way for a Product Owner to handle this situation. The Daily Scrum is an event for the Developers to inspect their progress toward the Sprint Goal and adapt their plan for the next 24 hours. The Daily Scrum is not a status meeting or a reporting session for anyone else. The Product Owner may attend the Daily Scrum as an observer or as an invited participant if they have something valuable to contribute or if they need some clarification from the Developers. However, introducing new features at this event would be disruptive and inappropriate for both parties. * Have the Scrum Master add these features to the current Sprint: This is not a valid way for a Product Owner to handle this situation. The Scrum Master is not responsible for adding or * removing any work from the current Sprint. 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. References: * Scrum Guide: https://www.scrumguides.org/scrum-guide.html * Product Owner: https://www.scrum.org/resources/what-is-a-product-owner * Developers: https://www.scrum.org/resources/what-is-a-developer-in-scrum * Sprint: https://www.scrum.org/resources/what-is-a-sprint-in-scrum * Sprint Goal: https://www.scrum.org/resources/what-is-a-sprint-goal * Daily Scrum: https://www.scrum.org/resources/what-is-a-daily-scrum * Scrum Master: https://www.scrum.org/resources/what-is-a-scrum-master
