Several Sprints into a project, the Product Owner tells the Scrum Master that a key stakeholder has just started using the product. The stakeholder is unhappy with the quality of the product, and the Product Owner agrees with the stakeholder's assessment that the quality is low. How should the Scrum Master respond to the Product Owner? (Choose the best two answers.)
Correct Answer: B,C
The best answers are B and C because the Scrum Master serves both the Product Owner and the Scrum Team by helping address quality concerns in a constructive, transparent, and Scrum- consistent way. Quality in Scrum is not handled outside the team or delegated only to testers. When a stakeholder raises a concern about low quality, the issue should be made visible and addressed through the Product Backlog, the Definition of Done, and direct collaboration within the Scrum Team. Option B is correct because quality expectations and stakeholder concerns should be reflected in Product Backlog items when appropriate, and the Developers need to understand those concerns clearly. Option C is also correct because the Scrum Master helps the Product Owner find an effective way to work with the Developers and address the issue empirically.
Question 28
What are two effective ways for the Scrum Team to make non-functional requirements visible? (choose the best two answers)
Correct Answer: C,D
The two effective ways for the Scrum Team to make non-functional requirements visible are C and D . C . Add them to the Definition of Done so the work is taken care of every Sprint. The Definition of Done (DoD) is a shared understanding of what it means for a Product Backlog item to be complete and potentially releasable1. The DoD can include non-functional requirements that apply to the entire product or system, such as performance, security, usability, etc. By adding them to the DoD, the Scrum Team ensures that they are met every Sprint and that the quality of the product is maintained2. D . Add them to the Product Backlog to ensure transparency. The Product Backlog is an ordered list of everything that is known to be needed in the product1. The Product Backlog can include non-functional requirements that are specific to certain features or functionalities, such as response time, availability, scalability, etc. By adding them to the Product Backlog, the Scrum Team ensures that they are visible to all stakeholders and that they are prioritized and refined along with the functional requirements3. A and B are not effective ways for the Scrum Team to make non-functional requirements visible. A . Run the integration and regression tests before the end of the Sprint, and capture the open work for the Sprint Backlog of the next Sprint. This approach does not make non-functional requirements visible, but rather postpones them until the end of the Sprint. This can lead to incomplete or low-quality Increments that do not meet the expectations of the customers or users. Moreover, this approach does not account for any changes or feedback that may occur during the Sprint4. B . Put them on a separate list on the Scrum board, available for all to see. This approach does not make non-functional requirements transparent, but rather isolates them from the functional requirements. This can lead to confusion or inconsistency in how they are handled by the Scrum Team. Moreover, this approach does not align with the principle of having a single source of truth for the product requirements, which is the Product Backlog5.
Question 29
The CEO asks the Development Team to add a "very important" item to a Sprint that is in progress. What should the Development Team do?
Correct Answer: B
Question 30
A Development Team selects a set of Product Backlog items for a Sprint Backlog with the intent to get the selected items "Done" by the end of the Sprint. Which three phrases best describe the purpose of a definition of "Done"? (Choose three.)
Correct Answer: C,E,F
The correct answers are C, E, and F, because these phrases best describe the purpose of a definition of "Done". It creates transparency over the work inspected at the Sprint Review, as it defines what it means for an Increment to be potentially releasable. It guides the Development Team in creating a forecast at the Sprint Planning, as it helps them estimate how much work they can accomplish in a Sprint. It defines what it takes for an Increment to be ready for release, as it ensures that the product meets the quality expectations of the stakeholders.
