Scrum Practice Questions, Discussions & Exam Topics by our Authors
As the Development Team starts work during the Sprint, it realizes it has selected too much work to ...
In this scenario, the Development Team realizes that it has selected too much work for the Sprint and needs to adjust. Let's break down each option:
A) Inform the Product Owner at the Sprint Review, but prior to the demonstration.
- Rejection: This option is not ideal because waiting until the Sprint Review, especially before the demonstration, doesn’t allow for any course correction during the Sprint itself. The team would have already missed the chance to address the issue earlier in the Sprint.
B) Find another Scrum Team to give the excess work to.
- Rejection: This is not a good practice within Scrum. Teams should work with what they have committed to for the Sprint. Trying to offload work to another team can disrupt the focus and commitment of both teams, causing potential misalignment. It also undermines the concept of the team taking responsibility for the work they commit to.
C) As soon as possib...
Author: Vikram · Last updated Jul 24, 2026
In accordance with Scrum theory, how should a group of 100 people be divided into multiple Developme...
In Scrum, the formation of Development Teams should be done in a way that enables them to work effectively and autonomously to deliver valuable increments of the product. Let’s evaluate each option:
A) Understanding the product, the product vision, and the rules of the Scrum framework, the group divides itself into teams.
- Selection: This option is in line with Scrum principles. The Development Teams should be self-organizing, meaning that the group of people (after understanding the product and the vision) should have the autonomy to form teams that they believe would work best together. This fosters collaboration, ownership, and accountability within the team. Scrum encourages self-organization and ownership, making this the most appropriate option for dividing a large group.
B) It doesn't really matter because you can rotate the teams every Sprint to spread knowledge.
- Rejection: While rotating teams can help with spreading knowledge, it doesn't support the idea of creating stable, cross-functional, and dedicated teams that can work on a single product over time. Constantly rotating teams would hinder the team's ability to develop ...
Author: Daniel · Last updated Jul 24, 2026
Which two of the following are appropriate topics for discussion during a Sprint Retrospective? (Cho...
The Sprint Retrospective is a key event in Scrum, where the Scrum Team reflects on the Sprint that just completed and discusses ways to improve their processes, teamwork, and overall performance for the next Sprint. Let’s analyze each option:
- A) Identifying high priority process improvements for the next Sprint: This is a perfect fit for a Sprint Retrospective. One of the primary goals of the retrospective is to discuss how the team can improve its processes and performance in future Sprints. Identifying high-priority improvements aligns with the continuous improvement aspect of Scrum.
- B) The order of items in the Product Backlog: The order of items in the Product Backlog is typically discussed during Sprint Planning and Backlog Refinement sessions, not during the Sprint Retrospective. The retrospective focuses on how the team can imp...
Author: Olivia · Last updated Jul 24, 2026
Which three purposes does the definition of `Done` serve? (Choose three.)
The Definition of Done (DoD) is a crucial concept in Scrum, ensuring that work is completed to a consistent standard. Let's analyze the options to identify which purposes it serves:
A) Guide the Development Team on how many Product Backlog items to select for the Sprint.
- Rejection: The Definition of Done does not guide the team on how many items to select for the Sprint. It provides clarity on the completion criteria for each item but does not influence the amount of work the team commits to during Sprint Planning. The selection of work is based on the team's capacity, not the DoD.
B) Create a shared understanding of when work is complete.
- Selection: This is one of the primary purposes of the Definition of Done. It ensures that the entire team has a shared understanding of what it means for work to be considered "complete." It sets expectations for the level of quality, checks, and acceptance criteria that need to be met, fostering consistency in the work delivered.
C) Describe the purpose, objective, and time-box of each Scrum event.
- Rejection: ...
Author: Henry · Last updated Jul 24, 2026
During a Sprint Retrospective, the Development Team proposes moving the Daily Scrum to only occur on Tuesdays and Thursdays. Which two are the ...
In this scenario, the Scrum Master’s role is to facilitate the team’s continuous improvement, ensuring Scrum events are happening in a way that supports the team’s progress. Let’s analyze each option:
- A) Consider the request and decide on which days the Daily Scrum should occur: This is not the most appropriate response. The Scrum Master should not make this decision for the team. The Scrum Guide emphasizes that the Scrum Team is self-organizing, and the Scrum Master should help the team reflect and make decisions together, rather than imposing their own decisions.
- B) Coach the team on why the Daily Scrum is important as an opportunity to update the plan: This is a good response. The Scrum Master should guide the team on the purpose of the Daily Scrum, emphasizing that it’s an important event for synchronization and adjusting the plan for the day. The Scrum Master should help the team understand the value of the Daily Scrum as a regular event, ideally occurring daily to inspect progress and adapt the plan.
- C) Have the developers vote: While voting could be useful for team decisions, this isn't the most appropriate response in this case. The Daily Scrum is an essential event in Scrum, and changing its frequency or schedule is not something that should be decided just by a vote. The Scrum Master’s role is ...
Author: CrystalWolfX · Last updated Jul 24, 2026
Which statement best describes the Sprint Review?
The Sprint Review is a crucial event in the Scrum framework, focused on inspecting the work completed during the Sprint and determining the next steps. Let's analyze each option and its relevance:
- Option A: "It is used to congratulate the Development Team if it did what it forecast, or to punish the Development Team if it failed to meet its forecast."
- This option is incorrect because the Sprint Review is not about rewarding or punishing the team. Scrum emphasizes collaboration and continuous improvement, not judgment or consequences for meeting or missing forecasts. The focus is on inspection and adaptation, not on performance appraisal.
- Option B: "It is a demo at the end of the Sprint for everyone in the organization to check on the work done."
- While this is partially correct in that the Sprint Review involves showing the work done, it misrepresents the scope. The Sprint Review is not just a demo for the organization to check on the work; it’s an opportunity for the Scrum Team and stakeholders to collaboratively inspect the work done and ...
Author: Sofia · Last updated Jul 24, 2026
Choose two responsibilities of a self-organizing Development Team. (Choose two.)
Let's carefully analyze the responsibilities of a self-organizing Development Team in the context of Scrum:
A) Reorder the Product Backlog.
- This is not a responsibility of the Development Team. Reordering the Product Backlog is the responsibility of the Product Owner, as the Product Owner is the one who manages and prioritizes the Product Backlog. The Development Team works on the items that are prioritized by the Product Owner, but they do not have the authority to reorder it.
B) Pull Product Backlog items for the Sprint.
- This is a correct responsibility of the self-organizing Development Team. The Development Team is responsible for pulling the items from the Product Backlog into the Sprint during Sprint Planning. They commit to delivering the items they pull and determine how much work they can take on during the Sprint based on their capacity and the Product Owner's priorities.
C) Do the work planned in the Sprint Backlog.
- This is another correct responsibility of the self-organizing Development Team. Once the items are selected for the Sprint and moved into the Sprint Backlog, the Development Team is responsible for executing the work. They plan, design, develop, test, and deliver the product increment, taking ownership of the tasks out...
Author: Sophia Clark · Last updated Jul 24, 2026
The Development Team should have all the skills needed to:
To answer this question, let’s first analyze each option in terms of the skills and responsibilities of a Development Team:
A) Turn Product Backlog items into a valuable, useful Increment.
- The Development Team is responsible for developing the features and functionality specified in the Product Backlog and turning them into valuable, working increments of the product. This requires a diverse set of skills, including design, coding, testing, and integration. This aligns with the core responsibility of the Development Team in an agile environment.
B) Do all of the development work, except for specialized testing that requires additional tools and environments.
- This option suggests that the Development Team is responsible for all development work except for specialized testing. In Scrum, the Development Team is expected to handle all aspects of development, including testing, unless there is a specific external resource required (e.g., specialized testing tools or environments). Therefore, this option doesn't fully align with the full scope ...
Author: GlowingTiger · Last updated Jul 24, 2026
Who owns the Sprint Backlog?
The ownership of the Sprint Backlog is a key aspect in understanding Scrum roles and responsibilities. Let’s examine each option and reason through the decision:
- Option A: "The Scrum Team."
- While the Scrum Team as a whole collaborates on the creation and maintenance of the Sprint Backlog, the ownership is not entirely with the whole team. The Scrum Team includes the Product Owner, Scrum Master, and Development Team, but ownership is more specifically assigned to the Development Team as they are the ones responsible for the execution of the work.
- Option B: "The Product Owner."
- The Product Owner is responsible for managing the Product Backlog and ensuring the items in it are prioritized according to business value. However, the Sprint Backlog is created and maintained by the Development Team during the Sprint Planning and throughout the Sprint. The Product Owner does not own the Sprint Backlog; they may collaborate with the Development Team to refine it, but ownership remains with the...
Author: Leo · Last updated Jul 24, 2026
Why does the Product Owner want the Development Team to adhere to its definition of `Done`?
The Product Owner's relationship with the Development Team's definition of "Done" is critical for ensuring transparency and consistent quality in the product development process. Let's analyze the options carefully:
- Option A: "To have complete transparency into what has been done at the end of each Sprint."
- This is the correct option. The Product Owner wants the Development Team to adhere to the Definition of Done (DoD) because it ensures that the Product Owner (and other stakeholders) can rely on complete transparency about what work has been completed and meets the agreed-upon criteria. The Definition of Done provides clarity, consistency, and ensures that any increment that is delivered at the end of the Sprint is of high quality and ready for release. Without a clear DoD, it would be unclear whether the Increment is truly "Done" or if additional work is needed.
- Option B: "To be able to reprimand the team when they don't meet their velocity goal for the Sprint."
- This option is incorrect because Scrum is focused on fostering a collaborative and supportive environment, not on reprimanding team members. The Product Owner’s role is to ensure that the right work is prioritized and delivered, not to penalize the Development Team. Velocity goals are not a reason for adherence to the DoD; rathe...
Author: Rohan · Last updated Jul 24, 2026
Which two things are appropriate for a Scrum Master to do if the Scrum Team doesn't have the tools and environment to completely...
Let's carefully analyze each option in terms of what a Scrum Master should do when the Scrum Team lacks the tools and environment needed to complete Product Backlog items:
A) Coach the Scrum Team to improve its skills, tools, and infrastructure over time and adjust the Definition of Done accordingly.
- This is an appropriate action for the Scrum Master. The Scrum Master’s role is to help the team improve continuously. If the team is lacking tools or infrastructure, the Scrum Master can guide them to make incremental improvements. They can also adjust the Definition of Done to reflect the current capabilities while encouraging the team to work toward improving their environment over time.
B) Encourage the Product Owner to accept partially Done increments until the situation improves.
- This is not an ideal solution because it compromises the quality and completeness of the product. In Scrum, the goal is to deliver a fully "Done" increment that meets the Definition of Done (DoD). The Scrum Master should not encourage accepting partially Done increments, as it undermines the integrity of the process. Instead, the team should work on improving their environment to meet the DoD.
C) Refocus the current Sprint on establishing the Scrum Team's environment instead of delivering an Increment.
- This option is not suitable because it contradicts the purpose of the Sprint. A Sprint should always aim to deliver a potentially releasable increment of the product. Refocusing the Sprint on environment setup would mean abandon...
Author: Amira99 · Last updated Jul 24, 2026
When is implementation of a Product Backlog item considered complete?
Let's analyze each option in the context of when a Product Backlog item is considered complete:
A) At the end of the Sprint.
- This option is not correct. While the Sprint itself may end at a certain time, simply completing the Sprint does not mean that all Product Backlog items are "done." The key is whether the items meet the Definition of Done (DoD). A Product Backlog item is considered complete when it is done, not just when the Sprint ends. Therefore, this option misses the important point of the DoD.
B) When the item has no work remaining in order to be potentially released.
- This is the correct answer. A Product Backlog item is considered complete when it is done, which typically means it meets the Definition of Done and is in a state that could potentially be released. This involves the item being fully developed, tested, and integrated into the product, without any further work required to release it. This aligns with Scrum’s goal of delivering increments that are potentially releasable at the end of each Sprint.
C) When Quality Assurance reports that the item passes all acceptance criteria.
- This option is only partially correct. While it is important for the Product Backlog item to meet the acc...
Author: Lucas Carter · Last updated Jul 24, 2026
When might a Sprint be cancelled?
The cancellation of a Sprint is a serious decision that must be based on clear criteria. Let’s analyze each option carefully:
- Option A: "When the Developers determine the product plan is infeasible."
- While the Developers might face challenges in executing a product plan, the Sprint itself isn’t automatically cancelled based on their assessment of feasibility. The Sprint Goal and Product Backlog are refined and adapted based on feedback, but a Sprint isn’t canceled simply because a plan appears infeasible. Cancellation would require higher-level decisions, often involving the Product Owner or the Scrum Team.
- Option B: "When the Sprint Goal becomes obsolete."
- This is the correct option. A Sprint is canceled when the Sprint Goal becomes obsolete, meaning the original objective of the Sprint is no longer relevant. This could happen if there is a major change in direction or priorities that makes continuing the Sprint unnecessary. For example, a shift in market conditions or a major change in business priorities could make the current Sprint Goal irrelevant, thereby justifying a cancellation.
- Option C: "When the sales department has an important new opportunity."
- While an important new...
Author: Michael · Last updated Jul 24, 2026
Every Development Team should have:
To address this question, let’s examine each option in light of Scrum’s principles regarding the Development Team:
- Option A: "At least one representative from each major software engineering discipline; such as, Quality Assurance, Development, and User Experience."
- This option is incorrect because Scrum does not mandate specific roles or representatives from different disciplines like Quality Assurance or User Experience. Scrum values cross-functional teams, but it does not require representatives from each discipline. A Development Team should be composed of professionals with the skills necessary to complete the work, but these skills can be broad and are not limited to specific disciplines. Scrum emphasizes the ability of the team to collectively deliver the work, not having one representative from each field.
- Option B: "The competencies and skills needed to deliver a Done Increment in a Sprint."
- This is the correct option. A Development Team should have the competencies and skills required to deliver a "Done" Increment by the end of each Sprint. The team should be cross-functional, meaning it can handle all aspects of the work necessary to complete a Product Backlog it...
Author: Charlotte · Last updated Jul 24, 2026
The Scrum Master observes the Product Owner struggling with ordering the Product Backlog. What is an app...
To answer this question, let’s first analyze each option in terms of the role and responsibilities of the Scrum Master and the Product Owner:
A) Suggest the Product Owner extend the Sprint, so he can have more time to order the Product Backlog.
- This option is not appropriate because extending a Sprint is against the Scrum framework's principles. Sprints are fixed in duration, and the Scrum Master should help the Product Owner manage the backlog within the constraints of the current Sprint. Extending the Sprint would not resolve the core issue of backlog management and may set a poor precedent for working within Sprint boundaries.
B) Suggest that the Development Team does the ordering to be sure that it is a feasible ordering of work.
- The Product Owner is responsible for managing and ordering the Product Backlog. The Scrum Master should not suggest that the Development Team takes over the responsibility of ordering the backlog. The Development Team can provide input and technical insights, but the Product Owner must retain control over the ordering of the backlog to maximize value. This suggestion would undermine the Product Owner's role.
C) Offer the Product Owner help in understanding that the goal of ordering the Product Backlog is to maximize value.
- This is the most appropriate course of action. The Scrum Master’s role is to coach and guide the Scrum Team in adhering to Scrum practices. Helping the Product Owner understand the goal of ordering the Product Backlog in a way that maximizes valu...
Author: Ahmed · Last updated Jul 24, 2026
If two Scrum Teams are added to the development of a product that previously had only one Scrum Team, what will be the immediate impact on the pro...
In this scenario, where two Scrum Teams are added to the development of a product that previously had only one Scrum Team, we need to consider several key factors in determining the likely immediate impact on the productivity of the original Scrum Team.
1. Increased Communication Overhead: Adding two new Scrum Teams to the product's development will increase the complexity of communication and coordination. The original team might need to adjust to more stakeholders, interfaces, and possibly even new ways of working in order to collaborate effectively with the new teams.
2. Possible Distractions and Context Switching: As new teams are integrated into the project, the original Scrum Team could experience disruptions such as changes in priorities or dependencies on other teams' work. These distractions could impact their focus and overall productivity.
3. Learning Curve and Adjustment Period: If the two new Scrum Teams are not fully aligned with the existing team's ways of working or the product's architecture, there might be an initial period of adjustment where everyone learns to collaborate effectively. This could impact the original team's productivity.
4. Impact of Additional Teams on the Whole System: In an agile framework, particularly Scrum, increasing the number of teams might not always lead to a linear increase in output. Instead, there can be diminishing returns or even negative impact as more coordinat...
Author: BlazingPhoenix22 · Last updated Jul 24, 2026
Which of the following are true about the Product Owner role? (Choose two.)
In Scrum, the Product Owner role has specific responsibilities, and it's important to understand these to determine which statements are correct. Let's analyze each option based on Scrum principles:
Key Responsibilities of the Product Owner:
- Accountable for managing the Product Backlog.
- Ordering the items in the Product Backlog to maximize value.
- Ensuring the Scrum Team understands the Product Backlog items clearly.
- The Product Owner is a single individual, not a group, to maintain clarity and decision-making authority.
Reasoning for each option:
1. A) The Product Owner is one person:
- True. The Product Owner is explicitly defined as a single person in Scrum. Having one person ensures clear decision-making and accountability. It prevents confusion or conflict that could arise from multiple decision-makers. While the Product Owner can collaborate with others, only one individual holds the role.
2. B) The Product Owner is accountable for ordering the Product Backlog:
- True. One of the primary responsibilities of the Product Owner is to order the Product Backlog to ensure that the highest value items are worked on first. This is a core function ...
Author: Michael · Last updated Jul 24, 2026
A Scrum Master is introducing Scrum to a new Team. The Team has decided that a Sprint Retrospective is unnece...
In this scenario, a Scrum Master is introducing Scrum to a new team, and the team has decided that a Sprint Retrospective is unnecessary. To address this, let's consider key Scrum principles and the role of the Scrum Master in guiding the team.
Key Scrum Principles:
- Scrum Framework: A Scrum Team is self-organizing, but it is also guided by the Scrum framework and the Scrum Guide. The Sprint Retrospective is an essential event in the Scrum framework, specifically designed to allow the team to inspect and adapt its processes, interactions, and work practices.
- Continuous Improvement: The Sprint Retrospective plays a crucial role in continuous improvement. If the team rejects the idea of a Retrospective, they might be missing a key opportunity for learning and enhancement.
Reasoning for the options:
1. A) Call a meeting between the Scrum Team and senior management:
- This option would be inappropriate because senior management is not the right party to resolve a fundamental Scrum process issue within the team. Scrum is about self-organization, and it should not be a top-down decision. This solution would undermine the Scrum Team's autonomy and may not be the best approach to address the problem.
2. B) Comply with the decision of the self-organizing team:
- While Scrum teams are self-organizing, this does not mean they can disregard core elements of the Scrum framework. The Sprint Retrospective is an integral part of Scrum, and the...
Author: Leah · Last updated Jul 24, 2026
What are three benefits of self-organization? (Choose three.)
Self-organization is a key principle of Scrum, where teams are empowered to make decisions, manage their own work, and determine how best to achieve their goals. Let's analyze the benefits of self-organization based on Scrum principles:
Key Benefits of Self-Organization:
1. Increased creativity: Self-organizing teams have the freedom to explore different solutions and approaches to problems. This autonomy fosters an environment where creativity can thrive, as team members are encouraged to think outside the box and come up with innovative solutions.
2. Increased self-accountability: When teams self-organize, they take ownership of their work. This accountability is crucial because team members are responsible for their commitments, performance, and ensuring that their work aligns with the goals of the team and the organization. This can lead to greater focus and a sense of responsibility.
3. Increased commitment: Self-organizing teams often show greater commitment to the success of the team and the project. Since they have more control over their work and the direction of their efforts, they tend to feel a stronger sense of ownership and are more likely to be engaged and motivated to meet the goals set by the team.
Reasoning for each option:
1. A) Increased creativity:
- True. Self-organizing teams are empowered to make decisions and experiment with different approaches to solve problems. This autonomy naturally encourages more creative thinking because team members have the freedom to explore new ideas and solutions without being overly constrained by rigid processes or external directives.
2. B) Increased rule compliance:
- False. While self-organizing teams ta...
Author: Noah · Last updated Jul 24, 2026
Which statement best describes the Sprint Backlog as outcome of the Sprint Planning?
In Scrum, the Sprint Backlog is a crucial artifact that is created during Sprint Planning and helps guide the Scrum Team throughout the Sprint. It is important to understand the true nature of the Sprint Backlog and the role it plays.
Key Elements of the Sprint Backlog:
- It is a dynamic artifact that evolves as the team works on the Sprint.
- The Scrum Team collaboratively selects and commits to the work to be done in the Sprint.
- It consists of the Product Backlog items (PBIs) selected for the Sprint, along with a plan for delivering those items (often broken down into tasks).
- The Sprint Backlog is a shared plan that reflects the work the Scrum Team is actively working on during the Sprint.
Reasoning for each option:
1. A) It is a complete list of all work to be done in a Sprint:
- False. The Sprint Backlog is not a complete list of all work to be done in the Sprint. Rather, it contains the Product Backlog items selected for the Sprint, along with the tasks required to complete them. The list of tasks may evolve as the team gains more understanding of the work during the Sprint.
2. B) Every item has a designated owner:
- False. In Scrum, the team works collectively, and tasks are typically not assigned to individual team members upfront. The team decides who will work on what during the Sprint based on the work at hand. While it’s possible for team members to take ownership of specific task...
Author: Evelyn · Last updated Jul 24, 2026
A Scrum Team has been working on a product for nine Sprints. A new Product Owner comes in, understanding he is accountable for the Product Backlog.However, he is unsure about his responsibilities. Whi...
In Scrum, the Product Owner (PO) plays a pivotal role in ensuring that the team delivers value to stakeholders by managing and prioritizing the Product Backlog. Let's break down the options based on the Product Owner's key responsibilities.
Option A: Ensuring that the most valuable functionality is produced first, at all times.
- Reason for Selection: This is a core responsibility of the Product Owner. The PO is accountable for maximizing the value of the product, and one way to do this is by ensuring that the most valuable functionality (i.e., items with the highest priority) is produced first. This aligns with the Scrum principle of delivering incremental value early and continuously.
- Scenario for Use: When prioritizing backlog items and making decisions about which features or fixes should be developed first, the PO must ensure that the highest value features are always prioritized.
Option B: Interacting with stakeholders.
- Reason for Selection: The Product Owner is responsible for engaging with stakeholders to understand their needs, gather feedback, and ensure their requirements are reflected in the Product Backlog. Regular communication with stakeholders is critical for maintaining alignment with business goals and delivering a product that meets their expectations.
- Scenario for Use: The PO would interact with stakeholders during Sprint Planning, Sprint Review, and throughout the product development lifecycle to clarify requirements and update the backlog.
Option C: Providing the Development Team with detailed specifications.
- Reason for Rejection: While the Product Owner clarifies the backlog items and their priorities, it is not the PO’s responsibility to provide detailed specifications. The Scrum Team, including the Development Team, should collaboratively work on understanding the requirements and break them down into manageable pieces. Over-specifying in advance can lead ...
Author: Liam · Last updated Jul 24, 2026
The Product Backlog is ordered by:
Let’s break down each option carefully:
A) The Product Owner with the most valuable items placed at the top:
This option aligns with the Scrum framework. The Product Owner is responsible for ordering the Product Backlog, and the ordering is typically based on value, with the most valuable items (in terms of delivering business value, customer benefit, or strategic importance) placed at the top. This ensures that the team works on the most valuable features first, maximizing the return on investment.
B) Risk, where safer items are at the top, and riskier items are at the bottom:
While risk management is important in software development, this isn’t the typical way the Product Backlog is ordered. The Product Backlog should focus on delivering business value first, not necessarily by the level of risk. However, riskier items might be prioritized if they affect the overall project delivery, but that is a secondary consideration. The primary driver for ordering the Product Backlog should still be the value of the items.
C) Items are randomly arranged:
This option goes against the principles o...
Author: GlowingTiger · Last updated Jul 24, 2026
You have just been hired by a company new to Scrum. Your management has assigned you to be the Scrum Master of six new Scrum Teams. These teams will build one product. Se...
Let’s break down each option based on the scenario where six Scrum Teams are working on one product.
A) There should be six Product Owners, one for each Scrum Team:
This option is not ideal because it contradicts the Scrum framework’s emphasis on having one Product Backlog and one Product Owner for that backlog. Having multiple Product Owners might lead to fragmentation and confusion about the vision and priority of the product, which could negatively impact collaboration and focus across the teams.
B) There should be six Product Owners, reporting to a chief Product Owner:
This option also isn’t ideal for the same reasons as option A. While having a "chief" Product Owner might seem like a solution, it still results in multiple Product Owners, which could create confusion and misalignment. Scrum emphasizes having a single Product Owner who has the ultimate responsibility for the Product Backlog, so this setup could complicate decision-making and ownership.
C) The product has one Product Backlog:
This is the correct approach. In Scrum, it’s important to have one unified Product Backlog for the entire product. This ensures that all teams are working toward the same product goal, with aligned priorities. A single backlog helps avoid fragmentation, confusion, and ensu...
Author: Sofia · Last updated Jul 24, 2026
You are the Scrum Master for four Scrum 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 a technical specialist who is external ...
Let’s carefully break down each option in this situation:
A) The desire to maintain a stable velocity:
This is a valid concern. Scrum teams aim for predictable, sustainable progress. Having a dependency on an external specialist could cause delays, disruptions, or lack of availability, which could make velocity fluctuate. A stable velocity helps with planning, forecasting, and overall team effectiveness, so this is something to consider when external specialists are involved.
B) The benefit of Development Teams figuring out a solution for themselves:
This is also a valid consideration. Scrum encourages self-organizing teams, meaning the team should ideally solve problems on their own without relying on external specialists. If the team is heavily dependent on an external specialist, it could undermine the team’s autonomy and problem-solving capacity. Encouraging teams to figure out solutions internally supports long-term growth and self-sufficiency.
C) The need to have enough work to keep all Development Team members busy:
While this might be a concern in certain situations, it is less relevant in this specific scenario. The Scrum Team should focus on delivering the highest-value work and meeting the Sprin...
Author: Liam · Last updated Jul 24, 2026
Which topics should be discussed in the Sprint Review?
In a Sprint Review, the goal is to inspect the work completed and adapt the backlog if needed. The focus should be on the outcomes of the Sprint and whether the goal has been met, as well as gathering feedback from stakeholders.
A) The Scrum process, and how it was used during the Sprint:
This is not a primary focus for a Sprint Review. Discussions around the process (e.g., how the Scrum framework was followed or any process-related issues) are typically handled during the Sprint Retrospective, not the Sprint Review. The Sprint Review is about evaluating the deliverables, not the process.
B) Coding and engineering practices:
While these practices are important for the team’s development work, they are also not the central focus of a Sprint Review. The Sprint Review is more about the outcomes (working product increments) and gathering feedback from stakeholders. Technical details like coding practices are better discussed in team-specific setting...
Author: Daniel · Last updated Jul 24, 2026
A member of the Development Team takes the Scrum Master aside to express his concerns about data secur...
Let’s break down the situation and options:
A) Add security to the definition of “Done”:
This is a valid consideration, but adding a requirement like security to the Definition of Done is a long-term decision, not an immediate solution. While the Definition of Done (DoD) should include all necessary criteria to ensure quality (including security), this option doesn’t address the immediate concern raised by the Development Team member about a current security issue.
B) Tell the Product Owner to stop further development of features until the issues are fixed:
This option might be too drastic. The Scrum Master should not directly dictate how the Product Owner manages the backlog. Stopping development might not be necessary unless there’s a critical security risk, which should be assessed and handled appropriately. This is an issue for the team to resolve collaboratively rather than imposing a decision unilaterally.
C) Create a Product Backlog item for security:
This option suggests that security concerns be formally added to the backlog. While this might be appropriate for long-term tracking and prioritization, it doesn’t immediately address the concern the Development Team member raised. The security iss...
Author: Amira · Last updated Jul 24, 2026
Which are NOT appropriate topics for discussion in a Sprint Retrospective? (Choose two.)
In a Sprint Retrospective, the focus is on inspecting and adapting the processes, interactions, and practices within the team to improve performance and collaboration. It's about reflecting on the past Sprint and finding actionable improvements. Now, let’s analyze the options in light of that goal.
Option A: Definition of "Done"
- Reason for Rejection: The Definition of Done (DoD) is a vital part of Scrum, but it should be discussed and clarified outside of the Sprint Retrospective, often during Sprint Planning or in other forums where the Scrum Team comes together to align on its understanding. The Sprint Retrospective is primarily for reflecting on team processes and interactions rather than establishing foundational elements like the DoD.
- Scenario for Rejection: If the team has never aligned on the DoD, a better forum for that discussion would be during Sprint Planning or during a separate workshop, rather than using the Retrospective, which focuses on continuous improvement.
Option B: How the team does its work
- Reason for Selection: This is absolutely an appropriate topic for a Sprint Retrospective. The Retrospective is intended for the team to discuss what went well, what didn’t, and how they can improve the way they work together. Reflecting on processes, tools, communication, and other practices fits perfectly within the scope of a Retrospective.
- Scenario for Use: The team could discuss things like how effective their communication was, whether their meetings were productive, or how well the current tools and processes helped or hindered their work.
Option C: Team relations
- Reason for Selection: Team dynamics, relationships, and collaboration are also appropriate topics for the Sprint Retrospective. The goal is to ensure a healthy, effective, and collaborative environment, so discussing how team members are interacting and improving their collaboration is essential for team growth.
-...
Author: Jack · Last updated Jul 24, 2026
Which best describes the Product Backlog?
The Product Backlog is a central element of Scrum and represents the work needed to develop and deliver the product. It evolves over time based on feedback, learning, and changing requirements. Let's analyze the options to determine which best describes the Product Backlog.
Option A: It is allowed to grow and change as more is learned about the product and its customers.
- Reason for Selection: This option accurately reflects the nature of the Product Backlog. The Product Backlog is a dynamic, living document that evolves as the team learns more about the product, its users, and its market. The Product Owner continuously refines and re-prioritizes the backlog based on feedback, new insights, and shifting business needs. This adaptability is a key principle in Scrum.
- Scenario for Use: The Product Backlog will grow and change between Sprints as the team gathers more information from stakeholders or as new opportunities and issues arise, ensuring that the team is always working on the most valuable and relevant items.
Option B: It provides just enough information to enable a Scrum team to start the design phase of a product.
- Reason for Rejection: This description is misleading because the Product Backlog is not just for the "design phase." The backlog contains all of the work items necessary for the entire product lifecycle, not just design. It is continuously refined to ensure that each item is well-understood, but it doesn't limit itself to only enabling design work. Scrum focuses on iterative and incremental development, and the backlog evolves throughout the entire product development process, not just the initial design phase.
- Scenario for Rejection: If the team were to treat the backlog as only relevant for the design phase, it would ignore the continuous refineme...
Author: GlowingTiger · Last updated Jul 24, 2026
What activities would a Product Owner typically undertake in the phase between the end of the curren...
In Scrum, the Product Owner (PO) plays a crucial role in preparing for the next Sprint, ensuring that the Product Backlog is ready and prioritized for the Development Team. Let's analyze the given options based on the activities the PO would typically undertake between the end of the current Sprint and the start of the next Sprint.
Option A: There are no such activities. The next Sprint starts immediately after the current Sprint.
- Reason for Rejection: While the Scrum framework emphasizes that Sprints are continuous and don’t have long breaks between them, this does not mean that there are no activities between the end of one Sprint and the start of the next. The Product Owner should be actively preparing for the next Sprint, which includes refining the Product Backlog and ensuring that it is in good shape for the next Sprint Planning meeting. Ignoring such activities would undermine the efficiency and focus of the Scrum Team.
- Scenario for Rejection: This would only apply if the team is following an unrealistic and overly rigid schedule where no time is allocated for backlog refinement or communication between Sprints. In practice, there is always some preparatory work to ensure a smooth transition to the next Sprint.
Option B: Refine the Product Backlog.
- Reason for Selection: This is a key activity that the Product Owner should undertake between Sprints. Backlog refinement (often called backlog grooming) ensures that the Product Backlog is well-organized, prioritized, and contains clear and detailed items that the Development Team can work on in the next Sprint. The PO needs to work on the Product Backlog to make sure that it is ready for Sprint Planning, which is essential for the team to understand the most valuable items and plan accordingly.
- Scenario for Use: Between Sprints, the Product Owner might review the Product Backlog, clarify items, reorder priorities based on new information, and make sure that backlog items are appropriately refined to fit into the next Sprint.
Option C: Work with the Quality Assurance departments on the Increment of the current Sprint.
- Reason...
Author: Liam · Last updated Jul 24, 2026
Which of the following are roles on a Scrum Team? (Choose three.)
In Scrum, there are specific roles that make up a Scrum Team. These roles have defined responsibilities and contribute to the overall success of a Scrum project. Let’s go through each option and analyze whether it is part of the Scrum Team or not.
Option A: Users
- Reason for Rejection: "Users" are not a formal role on a Scrum Team. While users are crucial stakeholders whose needs and feedback should inform the work, they do not directly perform any Scrum activities. Users provide input to the Product Owner, but they are not considered a role within the Scrum Team structure.
- Scenario for Rejection: Users would typically interact with the Product Owner to share their needs or feedback, but they are not involved in the Scrum ceremonies or day-to-day responsibilities of the Scrum Team.
Option B: Scrum Master
- Reason for Selection: The Scrum Master is one of the three official roles in a Scrum Team. The Scrum Master serves as a facilitator, helping the team adhere to Scrum practices, removing impediments, and coaching the team to continuously improve their processes. They ensure that Scrum is being followed and help create an environment where the team can be effective.
- Scenario for Use: The Scrum Master helps the Development Team in adhering to Scrum practices, facilitates Scrum events (such as Sprint Planning and Retrospectives), and coaches the team and Product Owner to follow Scrum principles effectively.
Option C: Product Owner
- Reason for Selection: The Product Owner is another key role on a Scrum Team. The Product Owner is accountable for managing the Product Backlog, ensuring that it is clear, prioritized, and reflects the needs of the stakeholders. The PO ensures that the team works on the highest-pri...
Author: CrystalWolfX · Last updated Jul 24, 2026
What are two ways that regulatory compliance issues are dealt with in Scrum? (Choose two.)
In Scrum, regulatory compliance is a critical concern, especially when dealing with industries like finance, healthcare, and other highly regulated fields. These issues must be integrated into the Scrum framework in a way that doesn’t disrupt the team's ability to work iteratively and incrementally while ensuring the product meets legal and regulatory requirements. Let’s examine each option:
A) They are discussed, determined, and documented before the actual feature development Sprints.
- Rejection: This approach contradicts Scrum’s emphasis on flexibility and incremental delivery. Regulatory compliance issues should not be fully determined and locked down before starting feature development. Instead, they should be integrated iteratively as the product evolves. Determining everything in advance would negate Scrum's ability to respond to changes as the project progresses.
- Scenario: This would be more applicable in a waterfall approach, where all requirements (including compliance) are determined upfront.
B) They are addressed along with functional development of the product.
- Selection: This is a key aspect of Scrum. Regulatory compliance issues should be integrated into the development process alongside functional development. Scrum teams work iteratively, and addressing compliance within each Sprint ensures that these concerns are embedded into the product from the beginning, rather than bolted on later.
- Scenario: This approach is suitable when compliance needs to be continuous...
Author: Sara · Last updated Jul 24, 2026
Why does a Development Team need a Sprint Goal?
A Sprint Goal is essential for the Development Team as it provides focus, direction, and a clear objective for the Sprint. It serves as a guiding light, ensuring that the team remains aligned and has a shared understanding of what they are aiming to achieve. Let’s break down each option:
A) A Sprint Goal only gives purpose to Sprint 0.
- Rejection: This option is incorrect. While Sprint 0 might be used to set up initial work for the project, the Sprint Goal is valuable throughout all Sprints, not just for Sprint 0. It’s a vital tool for every Sprint to align the team on the key objectives of that Sprint.
- Scenario: A Sprint Goal applies in all Sprints, regardless of the starting phase of the project.
B) Sprint Goals are not valuable. Everything is known from the Product Backlog.
- Rejection: This is false. The Product Backlog provides a list of items but doesn’t offer the same level of focus that a Sprint Goal provides. A Product Backlog is a collection of tasks, but the Sprint Goal helps prioritize, focus, and direct effort on a specific outcome.
- Scenario: This would apply in a theoretical scenario where a team believes they can operate without directio...
Author: Isabella · Last updated Jul 24, 2026
The IT manager asks a Development Team for a status report describing the progress throughout the Sprint. The Development Team asks the Scrum Maste...
In this scenario, the Scrum Master is tasked with guiding the Development Team in how to manage the IT manager's request for a status report. The Scrum Master’s role is to ensure that the team adheres to Scrum principles while maintaining clear communication. Let’s evaluate each option:
A) Talk to the IT manager and explain that progress in Scrum comes from inspecting an Increment at the Sprint Review.
- Selection: This is the best answer. The Scrum Master should help the IT manager understand that Scrum’s progress is best measured by inspecting the Increment during the Sprint Review, rather than through ad-hoc status reports. The team should focus on delivering work iteratively, and the Sprint Review provides a formal opportunity to assess progress and demonstrate completed work. This explanation aligns with Scrum’s focus on outcomes rather than just tracking activities.
- Scenario: This is appropriate when an external stakeholder (like the IT manager) is requesting a status report but may not understand Scrum’s iterative, outcome-driven approach. The Scrum Master can use this moment to educate and ensure the Scrum process is respected.
B) Tell the Development Team to figure it out themselves.
- Rejection: While the Development Team should be self-organizing, this approach leaves the team unsupported and fails to guide them in aligning with Scrum principles. The Scrum Master is responsible for coaching the team and ensuring they follow Scrum practices. Simply telling them to figure it out doesn’t help them navigate this situation in a Scrum-aligned manner.
- Scenario: This might be used in an environment where the Scrum Master takes a very hands-off approach, but it would not be best practice...
Author: Zara · Last updated Jul 24, 2026
When a Development Team determines that it will not be able to finish the complete forecast, who has to be present when reviewing and ad...
When a Development Team determines that it will not be able to finish the complete forecast (i.e., the Sprint work selected), it is important to review and adjust the work to ensure that the Sprint can still deliver value. Let’s evaluate each option:
A) The Development Team.
- Rejection: While the Development Team is the one directly impacted by not completing the forecasted work, they alone cannot make all the necessary adjustments in isolation. The Product Owner must also be involved because they are responsible for prioritizing the backlog and ensuring that the team focuses on the most valuable work. This scenario doesn’t account for the need to align the team’s adjustments with the product’s goals.
B) The Product Owner and all stakeholders.
- Rejection: In Scrum, stakeholders can provide valuable input, but they are not necessarily part of the team responsible for adjusting the Sprint work. The core participants in adjusting the Sprint’s work should be the Scrum team—specifically the Development Team and the Product Owner. Involving all stakeholders could lead to unnecessary complexity and delay in decision-making.
C) The Product Owner and the Development Team.
- Selection: This is the best answ...
Author: Amira99 · Last updated Jul 24, 2026
Which three behaviors demonstrate that a team is self-organizing? (Choose three.)
A self-organizing team is one that takes responsibility for its own processes, makes decisions independently, and works together collaboratively toward the Sprint Goal without needing external direction for its day-to-day activities. Let's evaluate each option:
A) Stakeholders walking in at the Daily Scrum to check progress and work with the Scrum Master to optimize the functional scope for the Sprint.
- Rejection: This is not an example of a self-organizing team. In fact, it undermines the team’s autonomy. The Daily Scrum is meant to be a team-centric event, not one where external stakeholders intervene to dictate scope or progress. The team should independently assess progress and address any scope issues themselves.
- Scenario: This scenario would apply in a context where the team is not empowered to self-organize and needs external supervision.
B) The Development Team members are working within the boundaries of their functional description and nicely handing off work from analyst to developer to tester to integration.
- Rejection: This reflects a traditional siloed approach where work is handed off between roles. A self-organizing team is expected to collaborate and take collective ownership of tasks, rather than strictly following functional boundaries and creating handoffs.
- Scenario: This would be suitable for teams following a waterfall or sequential approach, but not for Scrum or Agile practices where cross-functional collaboration is emphasized.
C) The Product Owner doesn't need to be at Sprint Retrospectives.
- Rejection: While the Product Owner can contribute to retrospectives, it’s not an indicator of a self-organizing team. The team is responsible for reflecting on their processes and continuously improving, and they have the autonomy to decide what needs to change. The absence of the Product Owner is not directly related to self-organization.
- Scenari...
Author: Sophia Clark · Last updated Jul 24, 2026
Every Scrum Team must have a Product Owner and Scrum Master. (Choose the best answer.)
Let's break down the question and analyze each option carefully to determine the most accurate response.
Statement: "Every Scrum Team must have a Product Owner and Scrum Master."
1. A) True. Outcomes affected by their participation and availability.
- This option correctly acknowledges that the participation and availability of both the Product Owner and Scrum Master are critical to the success of a Scrum Team. A Scrum Team must have these roles, as they serve distinct functions. The Product Owner represents the stakeholders and manages the Product Backlog, while the Scrum Master facilitates the Scrum process and helps remove impediments. Their roles are foundational, and their presence influences the team's effectiveness and outcomes. So, this is a solid answer, but the key word here is "must" and how their availability is crucial for success, rather than implying other roles could replace them.
2. B) False. A Product Owner can be replaced by a subject matter expert in the Scrum Team.
- This is incorrect. While a Subject Matter Expert (SME) may have valuable input, the Product Owner is a specific role in Scrum, responsible for managing the Product Backlog, prioritizing features, and ensuring that the team is working on the most important tasks. An SME is not equipped with the same responsibilities and authority to make decisions about what should be built...
Author: Aarav2020 · Last updated Jul 24, 2026
Several Sprints into a project, the Product Owner tells the Scrum Master that a key stakeholder just started using the product. The stakeholder is unhappy with the quality of...
Let's break down the situation carefully and look at the best options for the Scrum Master to handle the concern raised by the key stakeholder about the quality of the product.
1. A) Wait to bring this up until the Sprint Retrospective.
- This option is not ideal because the concern is about the current product's quality, which requires prompt attention, not just a discussion at the Sprint Retrospective. Waiting for the retrospective could delay addressing the issue, and the stakeholder’s dissatisfaction is ongoing. The Scrum Master should address the concern as soon as possible to prevent further issues.
2. B) Encourage the Product Owner to put quality specifications on the Product Backlog and express the stakeholder's concern to the Developers.
- This is a good option. The Product Owner is responsible for managing the Product Backlog, and it makes sense for the Product Owner to add quality-related specifications as part of the backlog items. Additionally, the Scrum Master should help the Product Owner communicate the stakeholder's concerns to the Development Team to ensure alignment on quality expectations. This proactive approach helps to address the issue early and integrates quality into the work.
3. C) Bring the concern to the testers to improve how the Product is verified.
- While it's important for testers to ensure product quality, this option is too narrow. The concern isn't just about testing; it's about overall product quality, which involves more than just verification. The Scrum Master should help address quality holistically with the e...
Author: Ethan · Last updated Jul 24, 2026
An organization has decided to adopt Scrum, but management wants to change the terminology to fit with terminology already used. What wi...
Let's break down the question and the answer choices carefully. The key point here is that the organization wants to adopt Scrum, but management wants to change the terminology to fit with what they already use. We need to evaluate the possible consequences of such a change.
1. A) Without a new vocabulary as a reminder of the change, very little change may actually happen.
- This option is plausible but not the most accurate in this case. While a new vocabulary can help reinforce the change, changing terminology alone does not necessarily guarantee a lack of transformation. The issue here is more about how adopting Scrum without using its intended terminology can confuse the actual implementation and hinder its success. So, while this could happen, it's not the primary concern in the context of terminology changes.
2. B) The organization may not understand what has changed within Scrum and the benefits of Scrum may be lost.
- This is the best answer. If management changes the terminology, it can lead to confusion about Scrum's principles and practices. The language in Scrum is purposeful—it reflects the roles, events, and artifacts necessary for S...
Author: Carlos Garcia · Last updated Jul 24, 2026
At the seventh Sprint Review, the stakeholders are disappointed and angry. They have determined that the product or system being built will not meet their needs and will cost more ...
Let's analyze the situation and break down the factors that likely contributed to the stakeholders’ disappointment and anger at the seventh Sprint Review.
1. The Project Management Office (PMO) has not been engaged adequately.
- The PMO typically handles project oversight and ensures alignment with the larger organizational goals. However, if the product is already in development and we are discussing a Scrum process (with a focus on iterative progress and reviews), the direct involvement of the PMO might not be the most significant factor. The issue seems more centered around the Scrum team and stakeholders’ interactions, rather than a failure in project oversight. Therefore, this option seems less likely to be the core cause.
2. The Product Owner has not been keeping the stakeholders aware of the progress of the project.
- This is a key factor. The Product Owner is responsible for maintaining communication between the team and stakeholders, ensuring that stakeholders are aware of the product’s progress and that their feedback is incorporated. If the Product Owner failed to keep the stakeholders informed about how the product was evolving, this would likely result in unmet expectations and disappointment at the Sprint Review.
3. The stakeholders haven't been using the Sprint Reviews to inspect and evaluate p...
Author: Elizabeth · Last updated Jul 24, 2026
Which two activities will a Product Owner engage in during a Sprint? (Choose two.)
In Scrum, the Product Owner has a defined role with specific responsibilities. Let's evaluate each option carefully based on Scrum principles:
---
✅ D) Answer questions from the Development Team about items in the current Sprint.
Selected.
Reason:
One of the Product Owner’s key responsibilities is to ensure that the Development Team understands the Product Backlog items to the necessary level. This includes being available during the Sprint to clarify requirements, provide feedback, and answer questions about the work being done. This helps ensure that the team builds the right product.
---
✅ C) Update management on what is being worked on.
Selected.
Reason:
While not a formal Scrum event, communication with stakeholders, including management, is part of the Product Owner’s responsibility. The Product Owner is the primary point of contact for stakeholders and represe...
Author: Vikram · Last updated Jul 24, 2026
Which of the following is an example of an Increment? (Choose the best answer.)
The question asks for an example of an Increment, and we need to consider the definition of an Increment in Scrum. In Scrum, an Increment is a potentially releasable and working piece of the product that adds value to the customer or end user. Each Increment is the sum of all the Product Backlog items completed during the Sprint, which should be usable and functional.
Now, let's evaluate the options:
A) A plan for the overall product release – This is not an Increment. A product release plan is a strategic document, not a working piece of the product. It may inform when and how Increments will be released, but it’s not an Increment itself.
B) A mock-up of the product marketing materials – While this could be useful for the product, it is not an Increment. A mock-up is a visual representation, but not necessarily a functional, usable, or valuable working piece of the product. An Increment should be more than a visual or marketing asset—it needs to have functional value.
C) A design for the product – Similar to the mock-up, a design could contribute to the pr...
Author: Deepak · Last updated Jul 24, 2026
Which are appropriate topics for discussion in a Sprint Retrospective? (Choose three.)
The question asks about appropriate topics for discussion in a Sprint Retrospective. The Sprint Retrospective is a meeting where the Scrum Team reflects on the past Sprint and discusses how they can improve their processes and work better together in the next Sprint. Let's review each option in this context:
A) Arranging the Sprint Backlog for the next Sprint – This is not an appropriate topic for the Sprint Retrospective. The Sprint Backlog is typically discussed during Sprint Planning, not the Retrospective. The Retrospective focuses on process improvements and team dynamics, not on specific tasks or items for the upcoming Sprint.
B) The value of work currently represented in the Product Backlog – This is also not appropriate. The value of the work in the Product Backlog is generally discussed during Product Backlog Refinement or Sprint Planning meetings. The Retrospective focuses on how the team works and its processes, rather than evaluating product backlog items.
C) Team relations – This is an appropriate topic. The Retrospective is an ideal time to discuss team dynamics, collab...
Author: StarryEagle42 · Last updated Jul 24, 2026
During the Sprint Retrospective a Scrum Team has identified several high priority process improvements. Which of the followin...
The question asks about the Scrum Team’s actions after identifying several high-priority process improvements during the Sprint Retrospective. Let’s analyze the options based on Scrum principles:
A) The Scrum Team may add items to the Sprint Backlog for the next Sprint – This option is correct. During the Sprint Retrospective, the Scrum Team often identifies areas for process improvement, and the team may choose to add these process improvements to the Sprint Backlog as items for the next Sprint. These items are not Product Backlog items but are tasks related to improving the team’s processes, which the team decides to tackle in the upcoming Sprint.
B) The Scrum Team should choose at least one high-priority process improvement to place in the Product Backlog – This is incorrect. Process improvements identified in the Retrospective are typically placed in the Sprint Backlog, not the Product Backlog. The Product Backlog is for features and items that directly contribute to the product. Process improvements relate to how the team works, not the product itself, so they belong in the Sprint Backlog.
C) The Scrum Team should decline to add a process improvement to t...
Author: Aria · Last updated Jul 24, 2026
When must a Product Owner release each Increment? (Choose the best answer.)
The question asks when the Product Owner must release each Increment, focusing on the timing and conditions that trigger a release. Let’s carefully evaluate each option in the context of the Scrum framework.
A) When it makes sense to release it – This is a reasonable answer. The Product Owner is responsible for deciding when an Increment should be released based on customer needs, business value, market conditions, and other factors. While the Scrum framework encourages frequent releases, the decision on when to release is determined by the Product Owner in alignment with stakeholder needs and business goals.
B) When the Scrum Team finishes their work – This is not entirely accurate. The Scrum Team's completion of work does not directly dictate when the Increment is released. The work might be done, but the decision to release lies with the Product Owner, based on value, readiness, and business needs.
C) Whenever the product is free of de...
Author: Ahmed · Last updated Jul 24, 2026
The Sprint Backlog is a result of Sprint Planning, and it includes the Sprint Goal.
The question is discussing the Sprint Backlog and its connection to the Sprint Goal. The Sprint Backlog is a list of tasks and items that the team will work on during the sprint, which is created during the Sprint Planning meeting. The Sprint Goal defines the overarching objective the team aims to achieve during the sprint, and it is an essential part of the Sprint Backlog.
Now, let's look at the options:
A) True – This option is correct. The Sprint Backlog does indeed include the Sprint Goal, which is established during Sprint Planning. The Sprint Goal serves as a focus for the team during the ...
Author: Oscar · Last updated Jul 24, 2026
Who determines how work is performed during the Sprint?
To understand who determines how work is performed during the Sprint, we need to focus on the principle of self-management within the Scrum framework. Scrum emphasizes that the team is responsible for organizing their work and deciding how to best achieve the Sprint goal.
Option A: The Developers
- Why it's the best choice: In Scrum, Developers are self-managing, which means they are responsible for determining how the work in the Sprint is carried out. They decide the methods, tools, and techniques used to complete the work required to meet the Sprint Goal. While they collaborate with the Scrum Master and Product Owner, it is the Developers themselves who determine how the work is done on a daily basis.
Option B: The Scrum Team
- Why it's not ideal: While the Scrum Team as a whole is accountable for delivering the Increment and achieving the Sprint Goal, it is the Developers within the Scrum Team who specifically determine how the work is done. The Scrum Team collectively decides what work to do, but when it comes to how to perform that work, the decision lies with the Developers.
Option C: The Scrum Master
- Why it's not ideal: The Scrum Master...
Author: Mia · Last updated Jul 24, 2026
Which approach is best for Scrum Teams in order to produce valuable Increments? (Choose the best ans...
To determine the best approach for Scrum Teams to produce valuable Increments, we need to align the solution with Scrum principles like collaboration, cross-functionality, and delivering potentially shippable Increments.
Option A: Each Developer works on the component where they feel they can contribute.
- Why it's not ideal: While this option allows for individual contributions based on preferences or strengths, it doesn’t ensure that the Scrum Team as a whole is producing a complete, usable Increment. Scrum promotes a cross-functional team approach where members collaborate to deliver the entire product increment, rather than focusing on personal preferences.
Option B: Each Scrum Team is accountable for developing functionality from beginning to end.
- Why it's the best choice: This option aligns closely with Scrum principles of cross-functionality, collaboration, and ownership. In Scrum, a team is responsible for delivering a complete increment of value at the end of each Sprint. Teams should take accountability for all aspects of product development, from concept through to the finished product, to ensure quality and coherence. This fosters a holistic approach where each member contributes across the full development lifecycle, creating a more valuable and fully integrated inc...
Author: Sam · Last updated Jul 24, 2026
Which topics should be discussed in the Sprint Review?
To identify the topics that should be discussed in a Sprint Review, we need to focus on the purpose of the Sprint Review within Scrum, which is to inspect the Increment and adapt the Product Backlog. It's a collaborative event where the Scrum Team and stakeholders discuss progress, future needs, and any changes necessary to ensure the product is evolving in the right direction.
Option A: The Scrum process, and how it was used during the Sprint.
- Why it's not ideal: The Scrum process is important, but the Sprint Review is focused on the product Increment, not necessarily on the Scrum process itself. Discussing the Scrum process is more appropriate for a Sprint Retrospective, which is a separate Scrum event where the team reflects on the process and looks for improvements.
Option B: Coding and engineering practices.
- Why it's not ideal: While coding and engineering practices are important for quality, the Sprint Review isn’t the right venue to focus on them. The Sprint Review is about the product Increment and stakeholder feedback, not a detailed discussion on technical practices. Such topics are usually better suited for team-level discussions or the Sprin...
Author: Chloe · Last updated Jul 24, 2026
Developers are self-managing, which of the following do they manage?
To understand which aspect Developers manage, we need to reflect on the Scrum framework, where Developers are self-managing. This means they have control over the work they do within the boundaries set by the Scrum Team and the Product Owner, but they don't directly manage all aspects of the process.
Option A: Sprint length.
- Why it's not ideal: The Sprint length is typically established by the Scrum Team at the start of the project and should remain consistent throughout the project. It’s not something that Developers directly manage themselves during each Sprint. The Scrum Master and Product Owner may help in adjusting the length if needed, but the Developers don't decide the duration.
Option B: Sprint Backlog.
- Why it's the best choice: The Sprint Backlog is managed by the Developers. It consists of the work that the team has committed to completing during the current Sprint. Developers are self-managing in that they select and organize the work to complete during the Sprint. They can make adjustments to the backlog throughout the Sprint based on new information, and they are responsible for its progress and completion.
Option C: Stakeholders for the Sprint Review.
- Why it's not ideal: The Scrum ...
Author: Julian · Last updated Jul 24, 2026
Which Scrum Values are violated by building Product Backlog items that have low business value? (Cho...
When building Product Backlog items that have low business value, several Scrum values are likely to be violated, as Scrum emphasizes delivering value efficiently and iteratively. Let’s explore each option in the context of the situation.
Option A: Respect
- Why it’s violated: Respect is a core Scrum value that encourages trust, collaboration, and valuing each individual’s contributions. When the team builds Product Backlog items with low business value, they may not be respecting the stakeholders’ needs or priorities, as they are not focusing on the most important or valuable items first. This lack of prioritization can show disrespect for the business objectives or the team’s commitment to delivering value.
Option B: Earned Value
- Why it’s not ideal: Earned Value is a project management concept used to track performance and progress, but it is not a Scrum value. Scrum values are centered on principles like transparency, collaboration, and value delivery, not specific performance measurement techniques like Earned Value.
Option C: Courage
- Why it’s violated: Courage is about having the bravery to take on difficult challenges and make tough decisions, even when the team faces uncertainty. Building low-value items could indicate a lack of courage to address the most impactful work or prioritize the highest val...
