What is one way to determine if the Product Owner is interacting with the Developers enough throughout a Sprint?
(choose the best answer)
A. The Developers should determine the percentage of time the Product Owner is required to be present and monitor whether the Product Owner's average presence is around this figure.
Answer : D
Some reasons why the other options are not correct are:
C: Observe whether the Developers need to ask the Product Owner questions at times other than during the Daily Scrum. This option is not correct because it implies that asking questions is a sign of insufficient interaction, which may not be true. Asking questions is a natural and healthy part of communication and collaboration between the Product Owner and the Developers. It shows that they are engaged, curious, and willing to learn from each other. It also helps them to clarify requirements, expectations, and feedback, and to resolve any ambiguities or conflicts. Asking questions does not necessarily mean that there is a lack of interaction, but rather that there is a need for more information or clarification.
What is an Increment? | Scrum.org
What Is a Daily Standup? | A Guide to Running Effective Standup Meetings | Atlassian
A Developer from the Scrum Team is always missing the Daily Scrum. She feels that if she is doing her job well, it does not matter whether she attends or not. The other Developers on the team have not done anything about it. As the Scrum Master how should you respond to this situation?
(choose the best answer)
Answer : B
As the Scrum Master, your role is to serve the Scrum Team by helping them to work effectively and deliver value. You are not responsible for managing the work or assigning tasks to the Developers. You should respect the self-organization and autonomy of the Developers, and support them in finding their own solutions to the problem. You should also facilitate collaboration and communication among the Developers and with other stakeholders.
Some reasons why option B is the correct answer are:
The Scrum Master should also help the Developers to come up with their own solutions on how to ensure full attendance and participation in the Daily Scrum. The Scrum Master should not impose or dictate a solution, but rather coach and guide the Developers to find what works best for them. The Scrum Master should also help the Developers to agree on some ground rules or norms for their Daily Scrum, such as when, where, and how to conduct it, what topics to discuss, and how to handle any issues or conflicts that may arise.
Some reasons why the other options are not correct are:
What is a Daily Scrum? | Scrum.org
What Is a Daily Standup? | A Guide to Running Effective Standup Meetings | Atlassian
You are the Scrum Master for four teams working from the same Product Backlog. Several of the Developers come to you complaining that work identified for the upcoming two Sprints will require full time commitment from Phil, an external specialist. As the Scrum Master what should you do to solve this upcoming problem?
(choose the best answer)
Answer : C
As the Scrum Master, your role is to serve the Scrum Team by helping them to work effectively and deliver value. You are not responsible for managing the work or assigning tasks to the Developers. You should respect the self-organization and autonomy of the Developers, and support them in finding their own solutions to the problem. You should also facilitate collaboration and communication among the Developers and with other stakeholders, such as Phil and the Product Owner.
Some reasons why the other options are not correct are:
A: Preparing the Sprint Backlogs each day for the teams so Phil can spend some time in each team. This option is not correct because it violates the Scrum framework and the Scrum Master role. The Sprint Backlog is owned and managed by the Developers, not by the Scrum Master. The Scrum Master should not interfere with or dictate how the Developers plan and execute their work. The Scrum Master should also not impose a solution that may not be optimal or feasible for the teams or for Phil.
B: Allocate Phil to one team per Sprint, so that over four Sprints every team will have had the support it requires. This option is not correct because it violates the Scrum framework and the Scrum Master role. The Scrum Master should not allocate resources or assign tasks to the teams or to Phil. The Scrum Master should also not impose a solution that may not be aligned with the Product Owner's priorities or the teams' needs.
D: Ask Phil for a plan to hire and train additional people in his domain, and in the meantime work with the Product Owner and Developers to re-prioritize the work so that tasks not depending on Phil can be done first. This option is not correct because it violates the Scrum framework and the Scrum Master role. The Scrum Master should not ask Phil to do something that may be beyond his authority or responsibility. The Scrum Master should also not work with the Product Owner and Developers to re-prioritize the work, as this is the Product Owner's accountability. The Scrum Master should respect the Product Owner's decisions on what is valuable and what is not, and support the Developers in delivering that value.
What is a Scrum Master? | Scrum.org
What is a Sprint Backlog? | Scrum.org
Who is responsible for dependency management? | Scrum.org
[Managing Dependencies in Scrum - Scrum Alliance]
In the Sprint Retrospective, there is discussion that the quality of the Increment is not sufficient tor going to production In response, a Scrum Team member points out the high velocity reached by the team. What are the two best actions tor the Scrum Master to take?
(choose the best two answers)
Answer : B, D
Some actions that the Scrum Master can take in this situation are:
Facilitate a discussion on how to improve the quality to a level sufficient for production, even if the measured velocity will drop in the next Sprint. This action will help the Scrum Team to identify and address the root causes of the quality issues, and to plan actions for improvement. The Scrum Master should encourage the Scrum Team to inspect their Definition of Done, their testing and quality assurance practices, their technical debt, and their collaboration with stakeholders. The Scrum Master should also help the Scrum Team to prioritize quality over quantity, and to understand that delivering a potentially releasable Increment at the end of every Sprint is one of the goals of Scrum.
Stress the value of working product over measured velocity. This action will help the Scrum Team to align their work with the Agile values and principles, and to focus on delivering value to the customers and users. The Scrum Master should remind the Scrum Team that velocity is not a goal or a measure of success, but a tool for planning and forecasting. The Scrum Master should also help the Scrum Team to avoid falling into the trap of velocity-driven development, where they sacrifice quality, sustainability, and customer satisfaction for higher numbers.
Some actions that the Scrum Master should not take in this situation are:
Agree and praise the Developers for their hard work, so they are motivated to do even more in the next Sprint. This action will not help the Scrum Team to improve their quality or effectiveness, but rather reinforce a false sense of achievement based on velocity. The Scrum Master should acknowledge and appreciate the Developers' efforts, but also challenge them to inspect and adapt their work processes and outcomes. The Scrum Master should also help the Developers to balance their motivation with realism, and to avoid overcommitting or overestimating their capacity.
Acknowledge the hard work, but remind the Developers that they need to improve to do even more in the next Sprint. This action will not help the Scrum Team to improve their quality or effectiveness, but rather put pressure on them to increase their velocity. The Scrum Master should not imply that doing more work is equivalent to doing better work, or that higher velocity is expected or desired. The Scrum Master should also help the Developers to avoid burnout, stress, and fatigue caused by unrealistic or unsustainable expectations.
The Sprint Retrospective - What It Is & Tips for Making the Most of Your Meeting | Scrum Alliance
How to Measure Sprint Velocity in Agile | Parabol
What is a Sprint Retrospective? - Zeolearn
What Is the Goal of Sprint Retrospective Meeting? | Wrike
What is a Sprint Retrospective? | Scrum.org
[Principles behind the Agile Manifesto]
[What is a Product Increment? | Scrum.org]
[Velocity-driven development: A trap waiting for you | Agile Alliance]
Respect is one of the five Scrum values. Which statements demonstrate respectful behavior in the Scrum Team?
(choose the best two answers)
Answer : A, C
Respect is one of the Scrum values that means recognizing the value of each individual and their contribution, trusting them to fulfill their tasks, listening to and considering their ideas, and acknowledging their accomplishments. Respect also means honoring the diversity of people, their experiences, and their opinions. Respect facilitates collaboration, learning, and creativity in the Scrum Team.
Some statements that demonstrate respectful behavior in the Scrum Team are:
Respect the accountabilities of the Scrum Team members. This means that each role in the Scrum Team has a clear set of responsibilities and expectations, and that other team members respect those boundaries and do not interfere with or undermine them. For example, the Product Owner is accountable for maximizing the value of the product and the work of the Developers, and the Developers respect that by following the Product Owner's guidance on what to work on and what not to work on. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide, causing change that increases the productivity of the Scrum Team, and working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization. The Developers respect that by adhering to the Scrum framework, being open to feedback and improvement, and collaborating with other Scrum Teams when needed.
Respect people, their experience, diversity, and difference in opinion. This means that each person in the Scrum Team is valued as a skilled professional who brings unique perspectives and insights to the team. The team members respect each other's expertise, skills, and ideas, and are willing to learn from each other and from their stakeholders. They also respect that people may have different opinions or preferences on how to approach a problem or a solution, and they seek to understand those differences rather than dismiss or ignore them. They engage in constructive dialogue and respectful disagreement when necessary, and they support team decisions even if they are not their personal choices.
Some statements that do not demonstrate respectful behavior in the Scrum Team are:
Respect the Product Owner by letting them change the Sprint Goal during the Sprint. This is not respectful because it violates the Scrum framework and undermines the Developers' autonomy and commitment. The Sprint Goal is a shared objective that provides guidance to the Developers on why they are building an Increment. It is crafted by the Product Owner in collaboration with the Developers during Sprint Planning, and it remains fixed for the duration of the Sprint unless a significant change occurs that invalidates it. Allowing the Product Owner to change the Sprint Goal during the Sprint would disrupt the focus and alignment of the Developers, introduce uncertainty and confusion, and reduce transparency and accountability.
Respect stakeholder expectations that Scrum Teams will meet their forecast. This is not respectful because it implies that stakeholders have unrealistic or unreasonable expectations that are not based on empirical evidence or feedback. The forecast is a plan for what functionality will be delivered in an Increment by the end of a Sprint. It is based on what is known at Sprint Planning, but it is not a guarantee or a commitment. The forecast may change during the Sprint as new information emerges or as unforeseen challenges arise. The Scrum Team respects stakeholders by being transparent about their progress and any changes to their forecast, by delivering a valuable Increment at least by the end of every Sprint, by seeking feedback from stakeholders during Sprint Review, and by incorporating that feedback into future Sprints.
What are two signs that a Scrum Team is self-managing?
(choose the best two answers)
Answer : C, D
A self-managing Scrum Team is one that internally decides who does what, when, and how. It does not need external direction or supervision to accomplish its work. A self-managing Scrum Team can resolve conflicts and continue working, as this shows that the team members can collaborate effectively and handle disagreements without escalating them. Creativity flourishes and new possibilities are explored, as this shows that the team members are empowered to experiment and innovate, rather than following a fixed plan or process.
The Scrum Guide 20201, section ''The Scrum Team''
The Scrum Master Learning Path2, module ''The Self-Managing Scrum Team''
The Professional Scrum Master II Course3, topic ''Self-Management''
A Scrum Team has been working together for nine Sprints. A new Product Owner comes in, unsure about his responsibilities. As the Scrum Master you have observed how the functional and business insights of the Developers have grown over the past Sprints. The Product Owner however is relatively new to the company and to the product. What are two activities you would direct the new Product Owner towards focusing on?
(choose the best two answers)
Answer : A, D
The Product Owner is responsible for maximizing the value of the product and the work of the Developers. The Product Owner is also accountable for managing the Product Backlog, which is an ordered list of what is needed in the product. The Product Owner should collaborate with the Developers and the stakeholders to create and refine the Product Backlog, as well as to define and communicate the product vision and goals. Therefore, as a Scrum Master, you should direct the new Product Owner towards focusing on:
Building a good relationship with the stakeholders of the product (A), which is a valid option as it helps the Product Owner to understand and align with the changing organizational or market expectations, as well as to invite and receive feedback from the appropriate stakeholders during the Sprint Review, which is an event that inspects the outcome of the Sprint and determines future adaptations.
Relying on others in the Scrum Team and the stakeholders to formulate the Product Backlog (D), which is another valid option as it helps the Product Owner to leverage the functional and business insights of the Developers and the stakeholders, who are more familiar with the product and the customer needs. By questioning them and working with them, the Product Owner will quickly become more productive and effective.
The other options are not correct because they:
Inform the Product Owner that it is important that the Developers are updated on changing business priorities on a daily basis at the Daily Scrum (B), which is not a good option as it shows a misunderstanding of the purpose and format of the Daily Scrum, which is an event for the Developers to inspect their progress and plan their work for the next 24 hours, not a status report or a meeting for changing requirements or scope. The Product Owner should respect and support the Developers' commitment to their Sprint Goal and Sprint Backlog, and only introduce changes that do not endanger them.
Tell the Product Owner to make sure that there are no ambiguities or possible misunderstandings in the items on the Product Backlog by capturing the functional requirements during an analysis phase , which is not a good option as it shows a misunderstanding of the nature and process of the Product Backlog, which is a dynamic and emergent artifact that can change as more is learned about the product, users, market, and technology. The Product Owner should collaborate with the Developers to refine and clarify the Product Backlog items throughout the product development, not create detailed documents that are considered as final outputs of analysis Sprints.