Scrum Practice Questions, Discussions & Exam Topics by our Authors
Marian is the Product Owner envisioning a project for a new release of her product. She made a projection of a release date based upon a sustained velocity of 17 completed units of work per Sprint. Over the first 3 Sprints, the average velocity was 13 for work that the Development Team estimated as 90% done. Th...
To determine the best course of action for Marian and her team, let's break down each option based on Scrum principles, focusing on the need for transparency, adaptability, and a realistic approach to velocity and project planning.
Option A: The Development Team makes sure that all of the selected scope per Sprint is as "Done" as possible. The undone work is estimated and added to the Sprint Backlog of the next Sprint, so it doesn't mess up the Product Backlog.
This option suggests that any undone work from a Sprint is carried forward, with proper estimation and integration into the following Sprint. However, in Scrum, the definition of "Done" is crucial. If work isn't completed, it's not considered "Done" and should not be counted as part of the Sprint's completed work. This solution may mask the reality of the project's progress by artificially inflating the "completed" scope and potentially distorting velocity projections. It also does not adequately address the fundamental problem: the discrepancy between the projected velocity and actual progress.
Scenario where this could be used: This could be used when the team is trying to "save face" and continue progressing despite incomplete work, but it doesn’t align with the true Scrum values of transparency and realistic estimation.
Option B: Add enough people to the Development Team for the deadline to be made.
This option suggests adding more team members in an attempt to hit the planned velocity. While it might seem like a quick fix, adding more people to a team doesn't guarantee an increase in velocity and often results in diminishing returns due to the time it takes for new team members to become productive. It can also reduce team cohesion and collaboration, both of which are critical in Scrum. Additionally, velocity is not directly tied to the number of team members; it’s more about the team's ability to collaborate and efficiently complete work.
Scenario where this could be used: This might be proposed in organizations that are overly focused on deadlines without understanding the core principles of Scrum, but it's not an effective approach in a well-managed Scrum environment.
Option C: The opportunity to inspect and adapt is los...
Author: Layla · Last updated May 20, 2026
The time-box for a Daily Scrum is:
In Scrum, the Daily Scrum is a key event to ensure the team remains aligned and focused on the Sprint Goal. Let’s go through each option:
A) Two minutes per person – While it’s often ideal to keep each person’s update brief in a Daily Scrum, Scrum doesn’t prescribe a time per person. The time-box for the event as a whole is defined, not individual speaking durations. This option is too specific and doesn't reflect the time-box for the entire event.
B) 15 minutes – This is the correct answer. The Daily Scrum is time-boxed to 15 minutes, regardless of the number of team members. This ensures the meeting is short and focused, promoting quick updates on progress and any obstacles. The purpose is to synchronize activities, not to provide lengthy discussions or problem-solvin...
Author: Stella · Last updated May 20, 2026
What is the Product Owner responsible for during the Sprint Retrospective? (Choose the best answer.)
To determine the best answer for the Product Owner’s role during the Sprint Retrospective, let’s examine each option based on the Scrum framework and the purpose of the Sprint Retrospective.
Option A: Participating as a Scrum Team member
The Sprint Retrospective is a key event for the Scrum Team to reflect on the past Sprint and identify improvements for future Sprints. The entire Scrum Team, which includes the Scrum Master, Product Owner, and Development Team, should participate in the Retrospective. The Product Owner, as a Scrum Team member, is involved in these discussions, but not in a leadership capacity. Their participation is valuable for ensuring alignment and understanding of the team’s dynamics and processes.
Scenario where this could be used: This option is the best answer, as it aligns with the Scrum Guide, which encourages all Scrum Team members (including the Product Owner) to actively participate in the Retrospective to help improve the team's collaboration, processes, and performance.
Option B: Summarizing and reporting the discussions to the stakeholders that they represent in the Scrum Team
While the Product Owner might communicate with stakeholders outside the Scrum Team, this is not their role during the Sprint Retrospective. The Retrospective is about internal team reflection and process improvement, not about reporting to external stakeholders. The Scrum Master typically ensures that the Retrospective stays focused on improving the team’s work, rather than summarizing the discussions for external parties.
Scenario where this could be used: This phrase could apply if the PO were misinterpreting their role and focusing too much on communication with external st...
Author: Krishna · Last updated May 20, 2026
The length of a Sprint should be:
To determine the best answer for the length of a Sprint, let’s evaluate each option based on the key principles of Scrum and how Sprints are designed to operate.
Option A: Short enough to keep the business risk acceptable to the Product Owner
This is a relevant consideration in Scrum. The length of the Sprint should be short enough to allow the Product Owner to make adjustments based on feedback and reduce the business risk. However, this description doesn’t fully capture the broader guidelines for Sprint length, which involve more than just managing business risk.
Scenario where this could be used: This option could apply in a context where the Product Owner needs to regularly assess whether the product is moving in the right direction and whether risks are being minimized. But it doesn’t fully capture the flexibility and guidelines around the Sprint's duration.
Option B: Short enough to be able to synchronize the development work with other business events
This statement also captures an important aspect of Sprint length, particularly in terms of ensuring the development process can align with business events, customer needs, or market cycles. While synchronization is important, it does not capture the idea that Sprints should be a standard length (e.g., 1-4 weeks) and should not be altered too frequently.
Scenario where this could be used: This option could work in organizations where timing and synchronization with key business events (e.g., product launches or marketing events) are critical. However, it’s more about external timing than ...
Author: Nathan · Last updated May 20, 2026
What is the role of management in Scrum? (Choose the best answer.)
The role of management in Scrum focuses on providing support and resources to the Scrum Teams to ensure they can work effectively and improve. Let’s analyze each option:
A) To present the Scrum Teams with insights and resources that help them improve – This is the best option. In Scrum, management is responsible for providing the necessary resources, support, and environment that allow the team to be successful. They should help remove any organizational impediments that the team may face, provide guidance on improving processes, and offer insights that facilitate the team’s growth. Management should not micromanage or dictate how the teams work but focus on ensuring the teams have what they need to succeed.
B) To monitor the Development Team's productivity – This is not the primary role of management in Scrum. Scrum emphasizes self-organizing teams, where the Development Team manages their own work. Management should avoid micromanaging productivity. Instead, they should focus on providing support for the team to remove impediments and maintain a sustainabl...
Author: StarryEagle42 · Last updated May 20, 2026
Which phrase best describes a Product Owner?
To determine the best phrase that describes a Product Owner (PO), let’s first examine each option based on the role's primary responsibilities.
Option A: Go-between development team and customers
A Product Owner acts as a bridge between stakeholders (including customers) and the development team. They gather requirements, understand customer needs, and prioritize features to ensure the product delivers value. However, this description is somewhat limited because it only highlights communication without emphasizing the decision-making and prioritization responsibilities of the PO.
Scenario where this could be used: This phrase could describe a PO in a scenario where their main job is to communicate customer requirements to the development team, but it misses the full scope of the role, especially around value and prioritization.
Option B: Value optimizer
A Product Owner's primary responsibility is to maximize the value of the product, ensuring the team is working on the most important tasks that will deliver the greatest benefit to customers and stakeholders. This phrase emphasizes the PO’s key role in prioritizing features and aligning the product’s direction with business goals, ensuring efficient use of resources.
Scenario where this could be used: This phrase would be most appropriate in agile and product-centric organizations where the PO is seen as a value maximizer who focuses on the business impact of each feature and iteration.
Option C: Requirements engineer
A Product Owner certainly defines and manages...
Author: Max · Last updated May 20, 2026
What are two responsibilities of testers in a Scrum Team? (Choose two.)
In a Scrum Team, there are specific responsibilities that testers typically take on. Here's a breakdown of each option:
A) Verifying the work of programmers – Testers may be involved in verifying the work of programmers through testing, but this is not necessarily their sole responsibility in Scrum. In a cross-functional team, the responsibility of verifying work can be shared, and everyone may contribute to this process.
B) Everyone in the Development Team is responsible for quality – This is a fundamental principle of Scrum. The Development Team (including testers) is collectively responsible for ensuring quality, so this option is a valid answer because it emphasizes shared ownership of quality within the team, rather than isolating the task to testers alone.
C) Tracking quality metrics – Tracking quality metrics may be an aspect of a tester’s role, but it is not usually a primary responsibility in Scrum. While metrics can be helpful for identifying improvements, Scrum focuses more on delivering value in short iterations and continuous improvement through feedback, not solely on metrics.
D) Finding bugs – Testers do help identify bugs, but th...
Author: Amelia · Last updated May 20, 2026
Which of the following are true about the length of the Sprint? (Choose two.)
Let's break down the options and assess them carefully:
A) The length of the Sprint should be proportional to the work that is done in between Sprints.
- This option is incorrect. The length of the Sprint is not determined by the amount of work done between Sprints. Sprint length should be consistent, based on factors like the need for feedback, adaptation, and delivering increments. While the amount of work in the Sprint is important, it doesn’t directly determine the length. The key goal is to keep Sprints consistent to allow for regular review and adaptation.
B) It is best to have Sprints of consistent length throughout a development effort.
- This is correct. Having consistent Sprint lengths helps the team establish a steady rhythm and predictability. It also supports the Scrum process by allowing for regular opportunities for inspection and adaptation. When the length is consistent, the team can more easily evaluate their performance and improve their processes over time. This is a core principle in Scrum, as it allows for better planning and tracking.
C) Sprint length is determined during Sprint Planning, and should hold the time it will take to code the planned features in the upcoming Sprint, but does not include time for any testing.
- This is incorrect. The Sprint length should not be based on just the time required for coding or only the work planned for the Sprint. It should cover the entire scope of work required to deliver a done Increment, which...
Author: Aarav2020 · Last updated May 20, 2026
Which technique is the best way the Scrum Master can ensure that the Development Team communicates e...
In order to ensure effective communication between the Development Team and the Product Owner, the Scrum Master plays a key role in fostering collaboration and facilitating the process. Let’s analyze each option:
A) Monitor communications between them and facilitate direct collaboration – This is the best option. The Scrum Master should not only monitor communication but actively facilitate direct collaboration between the Development Team and the Product Owner. Scrum encourages open communication, transparency, and collaboration. The Scrum Master’s role is to remove any barriers to communication and create an environment where both the Development Team and the Product Owner can communicate openly and effectively with each other.
B) Teach the Development Team to talk in terms of business needs and objectives – While it's important for the Development Team to understand business needs and objectives, this option focuses too much on altering the way the Development Team communicates, rather than facilitating direct collaboration. Effective communication goes both ways, and it’s essential that both the Development Team and Product Owner understand each other’s perspectives...
Author: Kai · Last updated May 20, 2026
What is a Development Team responsible for? (Choose two.)
The correct answers are A) Resolving internal team conflicts and D) Organizing the work required to meet the Sprint Goal.
Reasoning:
The Development Team in Scrum is responsible for creating the product increment and organizing its work in a way that supports achieving the Sprint Goal. Let’s analyze the options:
A) Resolving internal team conflicts.
- This option is correct because Scrum encourages the Development Team to be a self-organizing and cross-functional group. One of the aspects of self-organization includes managing team dynamics, which includes resolving conflicts internally. While the Scrum Master is responsible for facilitating the team and removing impediments, the Development Team members themselves are expected to handle conflicts that arise within the team.
- Selected as correct because self-organizing teams are expected to handle internal conflicts effectively.
B) Reporting productivity.
- This option is incorrect because reporting on productivity is typically not the responsibility of the Development Team in Scrum. Scrum focuses on the completion of the work and its quality rather than productivity metrics. The team works collaboratively to deliver value and may use the Sprint Review or Sprint Retrospective to discuss progress and improvements, but the development team's primary responsibility isn't to report on productivity.
- Rejected because Scrum...
Author: Sara · Last updated May 20, 2026
What is the timebox for the Sprint Planning event?
Let's analyze each option based on the guidance from Scrum:
A) 4 Hours for a monthly Sprint.
- Reason to reject: The timebox for Sprint Planning is proportional to the length of the Sprint. For a one-month Sprint, it should be 8 hours (not 4). This option doesn't align with the correct timebox for a monthly Sprint.
B) 8 Hours for a monthly Sprint.
- Reason to accept: According to Scrum, the timebox for Sprint Planning is 8 hours for a one-month Sprint. For shorter Sprints, the timebox is shorter (typically 4 hours for a two-week Sprint, for example). This is the correct answer because it aligns with the prescribed timebox in the Scrum Guide.
C) Monthly.
- Reason to reject: This option is too vague. ...
Author: Isabella · Last updated May 20, 2026
A Scrum Master is essentially the same thing as a traditional PM (Project Manager).
The correct answer is B) False.
Reasoning:
The question specifically asks whether a Scrum Master is essentially the same as a traditional Project Manager (PM). The short answer is no, they are not the same, and the roles differ significantly in terms of responsibility, focus, and approach. Let's break this down:
Scrum Master vs. Traditional Project Manager:
- A Scrum Master serves the Scrum Team by facilitating Scrum processes, removing impediments, coaching the team on Scrum practices, and helping foster self-organization. They focus on ensuring the team is following Scrum values and principles, helping improve team dynamics, and supporting the team in delivering value.
- A Project Manager (PM), in traditional project management, typically focuses on controlling the project, managing timelines, budgets, resources, risks, and overseeing the execution of the project according to predefined plans. The PM often has decision-making authority over the project scope and direction, which contrasts with the Scrum Master’s role of supporting and coaching rather than directing.
Key Differences:
- Authority and Leadership Style: The Scrum Master is a servant-leader, helping the team to function efficiently. The traditional PM often has more authority over decision-making and controlling the project.
- Focus on Proces...
Author: Julian · Last updated May 20, 2026
Which Scrum Value is affected by a lack of trust in the Scrum Team?
Let's analyze how each Scrum Value is affected by a lack of trust in the Scrum Team:
A) Focus
- Reason to reject: While lack of trust can indeed affect the team's ability to focus, focus is primarily about prioritizing and dedicating attention to the most important work. A lack of trust could make it harder for the team to focus, but it doesn't directly impact the value of focus as much as other values like openness or respect.
B) Respect
- Reason to reject: Respect is crucial for the team’s interactions, and a lack of trust might lead to issues with respect. However, the core issue in the question is not about how the team interacts but how the lack of trust impacts openness, communication, and collaboration.
C) Openness
- Reason to accept: Openness is directly affected by trust. When trust is lacking, team members may hesitate to share information, ask for help, or be transparent about their challenges and progress. Trust is essential for creating an open environment where everyone feels safe to communicate honestly and share both successes and setbacks.
D) Courage
- Reason to reject: Courage is important for taking on challenges and stepping into the unknown. Whi...
Author: IceDragon2023 · Last updated May 20, 2026
Which two ways of creating Development Teams are consistent with Scrum's values? (Choose two.)
The correct answers are A) Existing teams propose how they would like to go about organizing into the new structure and D) Bring all the developers together and let them self-organize into Development Teams.
Reasoning:
In Scrum, the values of self-organization, collaboration, and empowerment are key to creating effective Development Teams. The way teams are created or restructured should align with these values to ensure that the teams can function autonomously and effectively.
A) Existing teams propose how they would like to go about organizing into the new structure.
- This option is consistent with Scrum’s values of self-organization and empowerment. Scrum encourages teams to take ownership of their work and their structure. If existing teams have input into how they want to be organized, it aligns with the principle that teams should be able to self-organize and choose what works best for them.
- Selected as correct because it allows for self-organization, which is a core Scrum value.
B) Managers personally re-assign current subordinates to new teams.
- This option is not consistent with Scrum’s values. While managers may have a role in providing resources or facilitating organizational changes, Scrum promotes self-organization by teams, rather than top-down assignments by management. Involving managers in re-assigning subordinates goes against the idea of the Development Team having autonomy over its own structure and membership.
- Rejected because it undermines the self-organizing nature of Scrum teams.
C) Managers collaborate to assign individuals to specific teams.
- Similar to option B, this is not aligned with Scrum’s values. Scrum emphasizes that teams should be self-organizing, and although managers may provide support and guidance, assigning individual...
Author: Amira99 · Last updated May 20, 2026
A Product Owner wants advice from the Scrum Master about estimating work in Scrum. What guidance should a...
Let's break down the options step-by-step to understand which one is best for guiding a Product Owner regarding estimating work in Scrum:
A) Product Backlog items must be estimated in story points.
- Reason to reject: Scrum does not mandate the use of any specific units for estimation. Story points are a popular method, but they are not a requirement in Scrum. Other units like ideal days or hours can also be used depending on the team's preference.
B) Estimates are made by the people doing the work.
- Reason to accept: This is in line with Scrum principles. The people doing the work, i.e., the Developers, should provide the estimates because they have the best understanding of the effort required to complete the tasks. This approach is part of the collaborative nature of Scrum, ensuring estimates are realistic and informed.
C) Estimates must be in relative units.
- Reason to accept, but secondary to B: Scrum encourages relative estimation rather than absolute estimation. The relative approach helps teams assess how much effort different Product Backlog items might require compared...
Author: Noah · Last updated May 20, 2026
Multiple Scrum Teams working on the same project must have the same Sprint start date.
The correct answer is B) False.
Reasoning:
The statement suggests that multiple Scrum teams working on the same project must have the same Sprint start date. However, this is not a requirement of Scrum. Let’s break this down:
In Scrum, multiple teams can work on the same product (project), but they do not have to start their Sprints on the same date. The key factor here is that each team is working within the framework of Scrum and should follow the Scrum principles (such as time-boxed Sprints, a Product Backlog, and a Definition of Done), but they can have their own Sprint schedules as long as their work is aligned with the overall product goals and coordinated properly.
Why is this the case?
- Each Scrum team is self-organizing and may work at different paces based on their scope of work or expertise. For instance, some teams might need shorter Sprints, others longer ones, depending on their tasks.
- Scrum allows flexibility as long as there is good coordination between teams to ensure that dependencies are managed and that the Product Owner is able to prioritize the work across teams.
Let’s examine the options:
A) True.
- This option would imply that all Scrum teams on the same proje...
Author: Olivia · Last updated May 20, 2026
The Product Owner is not collaborating with the Development Team during the Sprint. What are two valuable ac...
To determine the best actions for a Scrum Master when the Product Owner is not collaborating with the Development Team during the Sprint, let's evaluate each option based on the Scrum framework and the role of the Scrum Master in fostering collaboration and facilitating Scrum events.
Option A: Inform the Product Owner's functional manager
This option may seem like a way to escalate the issue, but it’s not in line with Scrum’s principle of self-managing teams. The Scrum Master should first try to resolve the issue within the Scrum framework, by addressing it with the Product Owner directly or using Scrum events to address collaboration gaps. Escalating to a manager undermines the Scrum Team's autonomy and doesn’t support the PO in improving their engagement with the team.
Scenario where this could be used: This approach might be used in organizations that are overly hierarchical or where Scrum practices are not well understood, but it’s not an ideal solution within a well-functioning Scrum environment.
Option B: Stop the Sprint, send the Product Owner to a course, and restart
This is an extreme and disruptive measure. Stopping a Sprint should only occur in exceptional circumstances, such as if the Sprint Goal becomes impossible to achieve. For issues like a Product Owner not collaborating with the team, there are more effective and less disruptive approaches, such as coaching or addressing the issue in the Sprint Retrospective. Sending the PO to a course is not an immediate solution and can delay addressing the real problem of collaboration.
Scenario where this could be used: This option could be considered in a very urgent situation, but it disrupts the flow of the team and doesn’t focus on a sustainable solution.
Option C: Bring up the problem in the Sprint Retrospective
This is an effective and valuable action. The Sprint Retrospective is the perfect setting for discussing team dynamics, including the lack of collaboration from the Product Owner. It provides a structured opportunity for the Scrum Master and the team to inspect and adapt how they work together, fostering open communication about what’s workin...
Author: Amelia · Last updated May 20, 2026
For the purpose of transparency, when does Scrum say a valuable and useful increment must be availab...
The correct answer is D) At the end of every Sprint.
Reasoning:
In Scrum, the key principle of transparency dictates that a valuable and useful increment must be available at the end of each Sprint. The Scrum Guide emphasizes that the goal of each Sprint is to produce a potentially releasable increment, which means the increment should be in a state where it could be released or delivered to the customer or stakeholders. This is critical for ensuring continuous progress and alignment with the overall product goals.
Now, let's break down the options and explain why each is either rejected or not the best fit:
A) After the Acceptance Testing phase.
- This option suggests that an increment is only valuable and useful after a specific testing phase. However, in Scrum, the increment should be potentially usable and valuable by the end of each Sprint, not after a separate phase like "Acceptance Testing." Scrum does not specify separate testing phases like this; testing is integrated throughout the Sprint, often happening continuously as part of the development process.
- Rejected because it implies the increment is not complete until after acceptance testing, which contradicts Scrum's emphasis on a usable increment at the end of every Sprint.
B) Before the release Sprint.
- This is misleading because there is no "release Sprint" in Scrum. The framework encourages having increments ready at the end of every Sprint that could potentially be released, not just in a "release Sprint." Scrum teams can release an increment at any time, so this option doesn't accurately reflect Scrum's approach.
- Rejected because Scrum doesn't define a separate "release Sprint."
C) Every ...
Author: CrimsonViperX · Last updated May 20, 2026
Who is responsible for tracking the remaining work of the Sprint?
The responsibility for tracking the remaining work of the Sprint falls on the Development Team, as they are the ones actively working on the tasks and ensuring that progress is made toward completing the Sprint Goal. Let's analyze each option to determine which one is correct:
Reasoning for each option:
A) The Development Team:
This is the correct answer. The Development Team is responsible for managing and tracking their own progress in the Sprint. They are the ones who update the work remaining (e.g., in a Scrum board or burndown chart) based on the tasks they've completed or are still working on. It is part of their self-organizing nature, where they hold accountability for the work and the Sprint Goal.
B) The Scrum Master:
The Scrum Master facilitates the Scrum process and ensures that the Scrum Team follows Scrum practices, but they are not responsible for tracking the remaining work. The Scrum Master helps remove impediments and may assist the team in tracking, but the responsibility lies with the Development Team, not the Scrum Master.
C) The Project Manager:
In Scrum, there is no Project Manager role, so this option is incorrect. Scrum ...
Author: Aarav2020 · Last updated May 20, 2026
The Sprint Review is mainly an inspect and adapt opportunity for which group?
The Sprint Review is a key Scrum event that provides an opportunity for inspection and adaptation regarding the product increment. Let’s assess each option to identify the group for whom this event serves as a primary inspect-and-adapt opportunity:
Option A: The Development Team and stakeholders.
While the Development Team and stakeholders play important roles in the Sprint Review, the event is primarily focused on the Scrum Team (which includes the Product Owner and Scrum Master), and it involves stakeholders for their feedback. The goal is to inspect the increment and adapt the Product Backlog based on the feedback received, but the main inspection and adaptation are performed by the entire Scrum Team.
Why rejected: The Sprint Review is not just for the Development Team and stakeholders; it’s more inclusive of the entire Scrum Team. It’s also about adapting the Product Backlog, a responsibility of the Product Owner, so focusing on just the Development Team and stakeholders misses that key role.
Option B: The Product Owner and Development Team.
While the Product Owner and Development Team are integral parts of the Sprint Review, the event’s purpose goes beyond just these two groups. Stakeholders’ input is critical because they help provide external feedback on the product increment, which informs decisions about future work. Limiting the event to only the Product Owner and Development Team would miss out on the valuable perspective of the stakeholders.
Why rejected: This option overlooks the important role stakeholders play in the Sprint Review, particularly when providing feedback and aligning the product’s direction with customer or business needs.
Option C: The Scrum Team and stakeholders.
This is the most accurate option. The Sprint Review is an event for the entire Scrum Team (Product Owner, Scrum Master, and Development Team) and the stakeholders who provide feedback. During the Sprint Review, the team inspects the increment, and stakeholders offer their feedback, which helps the Scrum Team adapt the Product Backlog and decide on future work. The Scrum Team collectively takes responsibility for making adjustments based on the feedback provided during the review.
Why selected: The Sprint Review is designed for b...
Author: Kai99 · Last updated May 20, 2026
True or False: To get started in terms of what to build, Scrum requires no more than a Product Owner with enough ideas for a first Sprint, a Development Team t...
Let's break down the statement carefully:
"To get started in terms of what to build, Scrum requires no more than a Product Owner with enough ideas for a first Sprint, a Development Team to implement those ideas and a Scrum Master to help guide the process."
This statement is generally True with some context. According to Scrum, to get started with the first Sprint, the framework only requires a few key elements:
1. Product Owner (PO): The PO is responsible for defining and prioritizing the work (often through a Product Backlog). For the first Sprint, the PO should have enough ideas or product backlog items to begin work. These ideas can evolve over time as the product is built, so the PO does not need to have everything figured out upfront.
2. Development Team (DT): The Development Team is responsible for building the product increment. They have the necessary skills to take the Product Backlog items and turn them into a potentially shippable product increment.
3. Scrum Master (SM): The Scrum Master helps guide the process by ensuring Scrum practices are followed, removing impediments, and fostering a productive environment.
The key point here is that Scrum can start with these thr...
Author: Andrew · Last updated May 20, 2026
What is the timebox for the Sprint Review?
The Sprint Review is an important Scrum event where the Scrum Team and stakeholders inspect the increment, assess the work done, and discuss what to do next. To ensure that the event is focused and effective, Scrum specifies a timebox for the Sprint Review based on the length of the Sprint.
Reasoning for each option:
A) As long as needed:
This is incorrect. Scrum prescribes a timebox for the Sprint Review to keep it efficient and productive. Having no timebox could lead to unstructured and prolonged meetings, which would be counterproductive. The timebox is specifically defined to prevent excessive time spent on the review process.
B) 2 hours for a one-month Sprint:
This is incorrect. While the timebox for shorter Sprints might be adjusted accordingly, the standard timebox for a one-month Sprint is not 2 hours. A 2-hour timebox would be too short to adequately discuss a month's worth of work.
C) 4 hours for a one-m...
Author: Aarav2020 · Last updated May 20, 2026
What is the tactic a Scrum Master should use to divide a group of 100 people into multiple Developme...
When dividing a group of 100 people into multiple Development Teams, the Scrum Master needs to ensure that the teams are cross-functional, autonomous, and capable of delivering value independently. Below, I'll break down each option and assess its suitability.
Option A: Create teams based on their skills across multiple layers (such as database, UI, etc.)
This approach suggests organizing the teams based on specialized skills, such as developers focused on specific layers of the technology stack (e.g., database, UI, back-end). While this might help with specialization, it undermines the principle of Scrum that teams should be cross-functional. In Scrum, the goal is to have self-contained teams capable of handling all aspects of the development process, including analysis, design, coding, testing, and deployment. If teams are divided by specialized skills, they may become siloed and less effective at delivering end-to-end value.
Why rejected: Scrum requires teams to be cross-functional, so having people specialize by layer would not allow for the autonomy that Scrum teams require. It may also lead to slower delivery and communication issues.
Option B: Ask the Product Owner to assign the people to teams.
While the Product Owner has a critical role in prioritizing the product backlog and ensuring the team delivers valuable increments, they are not in a position to understand the detailed skill sets and interpersonal dynamics of the individuals in the group. The Scrum Master should take the lead in forming the teams to ensure balanced skill sets, persona...
Author: Daniel · Last updated May 20, 2026
A product Increment must be released to production at the end of each Sprint.
Let's analyze the statement: A product Increment must be released to production at the end of each Sprint.
A) True
- Reason to reject: While the Product Increment must be "done" (meaning it meets the definition of done and is potentially releasable), it does not necessarily have to be released to production at the end of each Sprint. The decision to release the Increment is made by the Product Owner, based on factors such as business value, timing, and other constraints. The Increment must be potentially shippable, but it doesn't have to go live in production every Sprint.
B) False
- Reason t...
Author: Rohan · Last updated May 20, 2026
If burndown charts are used to visualize progress, what do they track?
Burndown charts are primarily used in agile project management to visualize progress over time. Specifically, they track the work remaining across time to indicate how much effort is left to complete a project or sprint. These charts typically plot remaining work (e.g., story points, tasks, or effort) against the time available, showing whether the team is on track to meet the deadline.
Reasoning for each option:
A) Accumulated cost:
Burndown charts are not designed to track costs. While cost management is an essential aspect of project management, burndown charts focus on the completion of work, not the financial aspect. Therefore, this option is rejected.
B) Individual worker productivity:
Burndown charts do not typically track individual performance. They aggregate the progress of the entire team, not breaking it down by individual worker. This ma...
Author: Kunal · Last updated May 20, 2026
A Scrum Master is keeping a list of open impediments, but it is growing and he/she has been able to resolve only a small portion of the impediments. Which thre...
Let's break down each option based on the situation of a Scrum Master managing a growing list of open impediments:
A) Consulting with the Development Team.
- Reason to accept: The Scrum Master should work closely with the Development Team to understand the impediments more thoroughly. Consulting with them will help identify which impediments are most pressing or blocking their progress, and this collaboration ensures that the team is involved in resolving the issues. It aligns with the Scrum Master’s role in helping remove impediments and supporting the team.
B) Prioritizing the list and working on them in order.
- Reason to accept: Prioritizing the list of impediments is critical when there are many unresolved issues. The Scrum Master should focus on the most critical impediments that have the greatest impact on the team's progress. This approach ensures that the most important issues are tackled first, enabling the team to continue working effectively. Prioritization will make the list manageable and prevent the Scrum Master from feeling overwhelmed.
C) Arranging a triage meeting with all project managers.
- Reason to rejec...
Author: Julian · Last updated May 20, 2026
How is management external to the Scrum Team involved in the Daily Scrum?
The Daily Scrum is a key event in Scrum, where the Development Team synchronizes their work and discusses progress. It is important to understand the role of management, or external parties like managers, in this context. The Scrum framework encourages self-organization, meaning the Development Team leads the Daily Scrum themselves, without direct interference from external parties.
Reasoning for each option:
A) The Scrum Master speaks on their behalf:
While the Scrum Master facilitates the Scrum process, they do not "speak on behalf" of anyone in the Daily Scrum. The Development Team leads the meeting by sharing updates about their work. The Scrum Master ensures that the event takes place and follows the framework, but doesn't speak on behalf of others in the team. This option is rejected.
B) Managers are not required at the Daily Scrum:
This is the correct answer. The Daily Scrum is designed for the Development Team to discuss their work and plan for the next 24 hours. Management is not involved in the Daily Scrum, and their presence is not required. This allows the team to self-organize and discuss progress in a safe, open environment without external pressure or influence. ...
Author: MysticJaguar44 · Last updated May 20, 2026
Which statement best describes a Product Owner's responsibility? (Choose the best answer.)
The role of the Product Owner in Scrum is central to maximizing the value delivered by the Scrum Team. Let's break down each option:
Option A: Optimizing the value of the work the Scrum Team does.
This is the most accurate description of the Product Owner’s responsibility. The Product Owner’s primary responsibility is to ensure that the team is delivering the most valuable product possible. This includes maintaining a well-prioritized Product Backlog, engaging with stakeholders to understand their needs, and making sure that the team’s efforts align with business objectives. The Product Owner ensures that the Scrum Team works on the highest-priority items that will provide the most value to the organization.
Why selected: The Product Owner's main responsibility is to maximize value, which aligns with this option. The focus is on ensuring the team works on what matters most to the business, optimizing the work to meet business goals.
Option B: Ensuring that the work meets the commitments to the stakeholders.
This option implies a somewhat more tactical or operational role for the Product Owner, focusing on commitments to stakeholders. While the Product Owner needs to communicate regularly with stakeholders and ensure their needs are reflected in the backlog, it is not about “ensuring commitments” in the sense of guaranteeing fixed timelines or features. In Scrum, flexibility is encouraged, and the scope can adjust based on feedback. The focus should be on delivering the highest value, rather than rigidly meeting predefined commitments.
Why rejected: While the Product Owner does communicate with stakeholders and seeks to meet their needs, the responsibility is not about rigidly ensuring commitments. The Scrum Team’s focus should be on maximizing value, not simply meeting a set of pred...
Author: Zara1234 · Last updated May 20, 2026
Which three of the following are feedback loops in Scrum? (Choose three.)
In Scrum, feedback loops are mechanisms that allow teams to reflect on progress, identify improvements, and adjust accordingly. These loops promote continuous improvement, alignment with goals, and adapting to changing circumstances. Let's evaluate each option in this context.
Key factors in reasoning:
- Sprint Review: This is a feedback loop because it allows the team and stakeholders to inspect the increment, provide feedback, and adjust the backlog or future work based on what was delivered. This event occurs at the end of each Sprint.
- Release Planning: This is not typically considered a feedback loop in Scrum. While it may involve reviewing progress toward a release, it does not occur regularly in the iterative, inspect-and-adapt nature of Scrum. Scrum doesn't focus on long-term release planning; it prioritizes short, incremental iterations.
- Sprint Retrospective: This is a feedback loop because it gives the team an opportunity to reflect on the process itself and identify areas for improvement in future Sprints. The focus is on improving the way the team works.
- Refinement Meeting: This is an event for refining or detailing Product Backlog items, not a feedback loop. While it ensures the backlog is ready for upcoming Sprints, it doesn’t involve reflecting on past work or adjusting based on feedback from previous Sprints.
...
Author: Sophia Clark · Last updated May 20, 2026
What are the two primary ways a Scrum Master keeps a Development Team working at its highest level o...
To answer this question, let's evaluate each option carefully with the focus on how the Scrum Master helps the Development Team work at its highest level of productivity:
A) By ensuring the meetings start and end at the proper time: While it's true that a Scrum Master is responsible for managing the time-boxing of Scrum ceremonies (e.g., ensuring meetings start and end on time), this is more of a logistical responsibility than one that directly drives the team’s productivity. Ensuring that meetings stay on schedule can help the team remain efficient, but it’s not a primary factor in boosting productivity on its own.
B) By keeping high-value features high in the Product Backlog: This responsibility lies more with the Product Owner than the Scrum Master. The Product Owner ensures that the Product Backlog is ordered with high-value features at the top, based on stakeholder needs. Although the Scrum Master may coach the Product Owner, it's not a primary responsibility of the Scrum Master to manage the Product Backlog.
C) By facilitating Scrum Team decisions: This is an important role of the Scrum Master. By facilitating team decisions, the Scrum Master ensures that the team can resolve issues quickly and collaboratively, leading to better al...
Author: Emily · Last updated May 20, 2026
Which of the following might the Scrum Team discuss during a Sprint Retrospective?
To answer the question, let’s go through each option one by one:
A) Methods of communication: This could definitely be discussed in a Sprint Retrospective. The Scrum Team may reflect on how they communicated during the sprint and whether it was effective. If the communication wasn't clear or efficient, they might come up with ways to improve it in the next sprint.
B) The way the Scrum Team does Sprint Planning: The team might also discuss how Sprint Planning went in the retrospective, especially if they feel it could be improved. However, this is more about the process of Sprint Planning, so it's a valid point but more specific to the actual planning phase, not the overall process of delivery during the Sprint.
C) Skills needed to improve the Development Team's ability to deliver: This is a very common discussion point in a retrospective. The team might identify skills that need improvement to improve their ability to deliver the product, such as technical expertise or communication skills.
D) Its Definition of Done: The Scrum Team might discuss whether their Definition of Done (DoD) is clear and effective in ensuring quality and completeness. ...
Author: Layla · Last updated May 20, 2026
When is the Sprint Backlog created?
Let's break down the question and evaluate each option carefully based on the Scrum framework.
Key factors in reasoning:
- Sprint Backlog: The Sprint Backlog is a list of tasks and items that the Development Team commits to completing during the current Sprint. It consists of selected Product Backlog items, along with a plan for delivering the Increment.
- Sprint Planning: According to Scrum, the Sprint Backlog is created during the Sprint Planning meeting. During this meeting, the Development Team, Product Owner, and Scrum Master collaborate to define the work that will be done in the Sprint and select the Product Backlog items that will be moved into the Sprint Backlog.
Analysis of options:
- A) At the beginning of the project: This is incorrect. The Sprint Backlog is not created at the beginning of the project as a whole. Instead, it is created for each individual Sprint, beginning with Sprint Planning.
- B) During the Sprint Planning meeting: This is correct. The Sprint Backlog is created during the Sprint Planning meeting. In this meeting...
Author: FrostFalcon88 · Last updated May 20, 2026
When a Development Team is having trouble delivering a working Increment because they don't understand a...
When a Development Team is struggling to deliver a working Increment due to not understanding a functional requirement, it’s important to focus on addressing the misunderstanding and resolving any ambiguities. Let’s evaluate each option based on the principles of Scrum.
Key factors in reasoning:
- Scrum encourages collaboration between the Development Team and the Product Owner to clarify requirements and adjust the scope when necessary.
- Inspect and adapt: Scrum emphasizes inspecting progress and adapting the plan throughout the Sprint, so any misunderstanding of requirements should be resolved early rather than deferred.
- The Product Owner’s role is to ensure the team has a clear understanding of the functional requirements, and it’s important to maintain transparency and collaboration.
Analysis of options:
- A) Add a specialist to the Development Team: This is not typically the best solution in Scrum. The Development Team is cross-functional, meaning it should have all the skills needed to complete the work. Adding a specialist might not address the underlying communication problem or misunderstanding between the Development Team and the Product Owner.
- B) Partially complete the functionality, and discuss the remaining work at the Sprint Review: While this opt...
Author: William · Last updated May 20, 2026
What is the recommended size for a Scrum Team?
Let’s break down the options with the key focus on the recommended size for a Scrum Team:
A) 7 plus or minus 3: This is the recommended size for a Scrum Team, as outlined in the official Scrum Guide. The ideal Scrum Team size is between 5 and 9 members. This range allows the team to remain small enough to be agile and collaborative, yet large enough to have the necessary skills and diversity to complete work efficiently. Having too many members can lead to coordination challenges, while too few members may result in a lack of necessary skill sets or capacity.
B) At least 7: While a team size of 7 is within the recommended range, the Scrum Guide suggests a size between 5 and 9 members rather than "at least 7." So, this is not the most accurate description of the Scrum Team size recommendation. It limits the flexibility of the range and excludes the possibility of having a team smaller than 7.
C) 9: This is at the upper end of the recommended range. A Scrum Team of 9 membe...
Author: Sophia Clark · Last updated May 20, 2026
Which of the following services are appropriate for a Scrum Master in regard to the Daily Scrum?
Let's evaluate the role of the Scrum Master in relation to the Daily Scrum and each of the provided options.
Key factors in reasoning:
- Scrum Master’s role: The Scrum Master’s primary role in the Daily Scrum is to facilitate the event, ensuring that the team adheres to Scrum principles. The Scrum Master is not there to dictate the content of the meeting but to help the team self-organize and stay on track.
- Daily Scrum: The Daily Scrum is a time-boxed event for the Development Team to inspect progress and adapt their plan for the day. It’s an opportunity for the team to align on goals, discuss obstacles, and review progress toward the Sprint Goal.
- Self-organization: The Development Team is responsible for conducting the Daily Scrum, and the Scrum Master is there to ensure the process is effective but does not directly manage the team’s discussions.
Analysis of options:
- A) Lead the discussions of the Development Team: This is incorrect. The Scrum Master does not lead the discussions during the Daily Scrum. The Development Team is responsible for discussing their progress and challenges. The Scrum Master facilitates the event, but the team drives the content.
- B) Make sure that all 3 questions have been answered by each member of the team: This is incorrect. While the three questions (What did you do yesterday? What will you do today? Are there any obstacles?) are a common structure, the Scru...
Author: James · Last updated May 20, 2026
The Product Owner determines how many Product Backlog items the Development Team selects for a Sprin...
Let's break down the question and examine each option based on the Scrum framework.
Key factors in reasoning:
- Product Owner's role: The Product Owner is responsible for the Product Backlog and ensuring it is prioritized according to the needs of the stakeholders.
- Development Team's role: The Development Team is responsible for deciding how much work they can take on in a Sprint, based on their capacity and ability to complete work during the Sprint.
- Sprint Planning: The Development Team collaboratively decides the amount of work they can commit to during the Sprint Planning meeting.
- Scrum Master: The Scrum Master facilitates the process and ensures that Scrum practices are followed but does not directly determine what or how much work is selected for the Sprint.
- Resource Manager/Project Manager: Scrum does not specifically assign a role to the Resource Manager or Project Manager in determining Sprint capacity or commitment; the Development Team handles their own capacity.
Analysis of each option:
- A) False: The Product Owner does not directly determine how many Product Backlog items the Development Team selects. The Development Team decides this based on their capacity and the work required for the Sprint.
- B) True, accordingly to what was committed to the stakeholders: This is incorrect because the Product Owner is responsible for prio...
Author: RadiantJaguar56 · Last updated May 20, 2026
In order to achieve the benefits of Scrum, it is important to enact the value of commitment. What two actions demonstrate...
To achieve the benefits of Scrum, commitment is one of the core values that the Scrum Team must demonstrate. This value represents dedication to achieving the team’s goals, collaborating effectively, and continuously improving. Let's assess each option based on what commitment means in the context of Scrum.
Option A: Always deliver the items in the Sprint forecast.
Delivering the items forecasted in the Sprint is a strong demonstration of commitment. The Sprint forecast is made during the Sprint Planning and represents the team’s commitment to completing the work during the Sprint. Commitment means the team does its best to deliver the work agreed upon, but it's also important to adapt based on new learnings or obstacles. Thus, consistently delivering what was forecasted shows dedication to meeting the Sprint goal.
Why selected: This demonstrates the commitment to meeting the Sprint goals and delivering the agreed-upon work, which is essential in Scrum.
Option B: Help the other Scrum Team members.
Helping other team members demonstrates teamwork, collaboration, and mutual respect — key elements of Scrum. Commitment in Scrum is not just about delivering your own work but ensuring the success of the team as a whole. Helping colleagues shows a commitment to collective success, and when one team member is struggling, others should step in to offer support.
Why selected: Commitment is not only about individual tasks but also about supporting your teammates to achieve shared goals. This reflects the Scrum value of teamwork and mutual accountability.
Option C: Do your best.
Doing your best aligns with the Scrum value of commitment. Scrum Team members are expected to put in their best effort to achieve Sprint goals and deliver high-quality work. While doing your best is essential, it’s also critical to communicate and work as a team, adapt when necessary, and focus on delivering valuable outcom...
Author: Amelia · Last updated May 20, 2026
Which of the following best describes an increment of working software?
The question asks for the best description of an increment of working software. An increment, in Scrum, refers to a functional piece of software that is potentially shippable, meaning it can be used or released by the stakeholders if needed. Let's break down each option:
Option A: A decomposition of all Product Backlog items into tasks for future Sprint Backlog lists.
This option refers to breaking down Product Backlog items into smaller tasks, which is an important activity for planning and organizing work in the Sprint. However, it doesn't describe an increment of working software. A decomposition is part of the planning process, not the result (the increment) of work.
Why rejected: This describes work preparation, not the actual result of completed work (the increment).
Option B: Additional features in a usable state that complement those delivered in previous iterations.
This is the most accurate description of an increment of working software. An increment is defined as a newly completed, usable piece of functionality that builds on previously delivered work. It is tested, functional, and ready for use or release, thus adding value and complementing what was delivered in earlier iterations.
Why selected: This correctly describes the concept of an increment in Scrum, which is new, usable software that integrates with or adds to what was previously delivered. It is in a usable state and complements earlier work.
Option C: A new user interface design for functionality delivered in previous iterations.
While a new user interface design could be part of an increment, the key to an increment is that it is working software. A design alone, without functional software that users can interact with, does ...
Author: Liam · Last updated May 20, 2026
Every Scrum Team must have a Product Owner and Scrum Master.
The question is asking if every Scrum Team must have both a Product Owner and a Scrum Master. The Scrum framework defines specific roles and responsibilities, and these roles cannot be arbitrarily replaced or disregarded.
Let’s analyze each option:
A) True. Outcomes affected by their participation and availability.
- Selected: This is correct. The Product Owner and Scrum Master are essential roles in the Scrum Team. The Product Owner is responsible for managing the Product Backlog and ensuring that the team works on the highest-value items. The Scrum Master is responsible for facilitating Scrum processes and ensuring that the team adheres to Scrum practices. The outcomes of the team’s work are definitely affected by their participation and availability, making these roles crucial.
B) False. A Product Owner can be replaced by a business analyst in the Development Team.
- Rejected: This is incorrect. In Scrum, the Product Owner is a distinct role, separate from other roles like a business analyst. While a business analyst may assist with gathering requirements, they do not take on the responsibilities of the Product Owner. The Product Owner makes decisions on what to build, prioritizes the backlog, and represents the stakeholders, none of which are responsibilities of a business analyst i...
Author: Joseph · Last updated May 20, 2026
Which of the following are topics for the Developers to discuss at the Daily Scrum as they inspect their pr...
The question asks for the topics that the Developers should discuss at the Daily Scrum to inspect their progress toward the Sprint Goal. The Scrum framework specifies that the Daily Scrum is meant for team members to inspect progress and plan the next steps to achieve the Sprint Goal, focusing on any obstacles or necessary adjustments.
Now, let’s analyze each option:
A) What have we learned since yesterday, and how should we modify our plan to increase our ability to meet the Sprint Goal?
- Selected: This option is relevant because it's asking about progress and how to adjust the plan accordingly. The goal of the Daily Scrum is to ensure that the team adapts quickly, so discussing lessons learned and potential changes to the plan aligns with inspecting progress and adjusting toward the Sprint Goal.
B) Are there any impediments blocking progress toward the Sprint Goal?
- Selected: This is a critical topic for the Daily Scrum. Impediments directly affect the ability to meet the Sprint Goal, and the team should address them to ensure smooth progress. Scrum explicitly emphasizes identifying and removing impediments.
C) What will I be working on tomorrow?
- Rejected: While this is a potential point for discussion, it doesn't fully address inspecting progress toward...
Author: Ahmed · Last updated May 20, 2026
Which two activities will a Product Owner engage in during a Sprint? (Choose two.)
Let's break down the options and analyze the roles and responsibilities of the Product Owner during a Sprint:
A) Run the Daily Scrum: The Daily Scrum is a meeting for the Development Team to synchronize their work and plan for the next 24 hours. The Scrum Master facilitates it, not the Product Owner. The Product Owner may attend, but they do not run the Daily Scrum. This is not an activity the Product Owner directly engages in.
B) Prioritize the Development Team's work on the Sprint Backlog: This is the responsibility of the Product Owner. However, the Sprint Backlog is created during Sprint Planning and is the Development Team’s responsibility to manage throughout the Sprint. The Product Owner works with the Product Backlog, which is prioritized and then used to guide the Sprint Backlog. While the Product Owner doesn’t directly prioritize the Sprint Backlog once the Sprint is underway, they provide input and guidance during Sprint Planning, ensuring that the Development Team focuses on the most important items.
C) Update the Sprint burndown chart: The Sprint burndown chart is typically managed by the Development Team or the Scrum Master to track the progress of the Sprint. The Product Owner does not typically update the burndown chart as it reflects progress toward the Sprint Goal, which is more of a Development Team concern.
D) Answer questions from the Devel...
Author: Mia · Last updated May 20, 2026
What are two good ways for a Scrum Team to ensure security concerns are satisfied? (Choose two.)
The question is asking for two good ways for a Scrum Team to ensure that security concerns are satisfied. Security should be integrated into the Scrum process continuously, not handled as a separate task or delayed, to ensure that the product is secure throughout the development cycle.
Let’s analyze each option:
A) Postpone the work until a specialist can perform a security audit and create a list of security-related Product Backlog items.
- Rejected: This option is not a good approach. Postponing security work and waiting for a specialist to perform an audit creates delays and could lead to risks being overlooked during the sprint. Security should be addressed continuously as part of the development process, not postponed to a later time.
B) Add security concerns to the definition of "Done".
- Selected: This is a good approach. By adding security concerns to the Definition of Done (DoD), the team ensures that security checks are always part of the completion criteria for any work item. This ensures that security is baked into the development process and not treated as an afterthought.
C) Add a Sprint to specifically resolve all security concerns.
- Rejected: This option is not ideal because it treats security as a separate concern rather than something that should be continuously addressed throughout the development cycle. Isolating security into one Sprint could lea...
Author: Olivia · Last updated May 20, 2026
Which are properties of the Daily Scrum? (Choose two.)
The question asks for properties of the Daily Scrum, which is a Scrum event designed for the team to inspect their progress toward the Sprint Goal and plan the next steps. Let's analyze each option to determine which are correct properties:
A) It is facilitated by the team lead.
- Rejected: The Daily Scrum is not facilitated by the team lead. It is typically self-organized by the Development Team. The Scrum Master’s role is to ensure the event happens and that it adheres to the Scrum framework, but not to directly facilitate it. The team itself drives the discussion.
B) It is held first thing in the morning.
- Rejected: While it is common to hold the Daily Scrum in the morning, it is not a strict rule. The important aspect is that it is held at a regular, consistent time, not necessarily first thing in the morning. The goal is to align the team and set the direction for the day, not the specific timing.
C) It is fifteen minutes or less in duration.
- Selected: This is a core property of the Daily Scrum. The Daily Scrum should be short and focused—typically 15 minutes or less. This ensures that it is efficient and does not take time away from actual development work. The brevity helps the team stay aligned without derailing productivity.
D) It is free from and designed to promote conversation.
- Rejected...
Author: Max · Last updated May 20, 2026
You are the Scrum Master of a new, to be developed product. Development is going to require 45 people. What is a good first question for yo...
To approach this question, we should focus on the main goal when forming teams for a new product. The Scrum Master’s role here is to help guide the team toward an optimal structure, ensuring that they have the right mix of skills and are set up for success. Let’s analyze each option carefully:
A) How will we make sure all teams have the right amount of expertise?: This is an excellent first question. In Scrum, cross-functional teams are a key principle, meaning each team should have all the necessary skills to complete its work. This question ensures that the Scrum Master encourages teams to be self-sufficient and to think about the skills required for success, such as development, testing, design, and any other domain expertise needed. Ensuring the right expertise in each team supports team autonomy and efficiency.
B) What is the right mixture of senior and junior people on each team?: This is a valid consideration but comes after the team formation question about expertise. While balancing experience levels is important for mentorship and development, it is secondary to making sure that the team has the right skill sets to begin with. The first priority should be ensuring that teams are balanced in terms of the expertise needed to deliver the product, and then you can think about mixing senior and junior members.
C) Who are going to be the team leads?: Scrum does not have "team leads" as a role. Scrum relies on a self-organizing t...
Author: Daniel · Last updated May 20, 2026
Cross-functional teams are optimized to work on one technical layer of a system only (e.g. GUI, data...
The question is asking whether cross-functional teams are optimized to work on only one technical layer of a system (like GUI, database, middle tier, or interfaces). Cross-functional teams, according to Scrum principles, are supposed to be capable of working on all aspects of a system within a sprint, not limited to just one technical layer. These teams bring together individuals with a variety of skills to collaboratively solve problems across the entire system, enabling flexibility and versatility in delivering the product.
Let’s analyze each option:
A) True
- Rejected: This statement is incorrect because cross-functional teams in Scrum are designed to work on all aspects of the product, not just one technical layer. They are meant to be able to handle the full stack of work required to meet the Sprint Goal, across different layers (e....
Author: VenomousSerpent42 · Last updated May 20, 2026
The Sprint Goal is a result of Sprint Planning, as is the Sprint Backlog.
The Sprint Goal and Sprint Backlog are indeed products of Sprint Planning. Let’s analyze each option based on that premise:
- A) True: This option aligns with the Scrum framework. During Sprint Planning, the Scrum Team creates the Sprint Goal, which is a concise summary of what the team aims to achieve during the Sprint. Additionally, the Sprint Backlog is created, which is the set of items the team commits to working on during the Sprint, broken down into actionable tasks. Both the...
Author: Ava · Last updated May 20, 2026
Who can abnormally terminate a Sprint?
To determine who can abnormally terminate a Sprint, let’s consider the key roles in Scrum and how they align with this decision:
- The Scrum Master: The Scrum Master is primarily responsible for facilitating the Scrum process and ensuring that the team follows Scrum practices. However, the Scrum Master does not typically have the authority to terminate a Sprint unless it's due to external factors, like the Sprint being a failure or no longer aligning with organizational priorities. So, while they can help manage the process, the authority to "abnormally" terminate the Sprint lies elsewhere.
- The Development Team or its members: The Development Team focuses on completing the work within the Sprint. They cannot unilaterally terminate the Sprint without external justification, as it is usually not within their control to end it early. The team can certainly raise con...
Author: John · Last updated May 20, 2026
When should a Sprint Goal be created?
The Sprint Goal is a key component of Scrum and helps the Scrum Team focus on a common objective for the Sprint. Let’s analyze each option:
- A) It should have been created in the previous Sprint during Product Backlog refinement: While Product Backlog refinement involves preparing and clarifying items in the backlog, the Sprint Goal is not something that should be created beforehand. The Sprint Goal should be established at the start of the Sprint, during Sprint Planning, and not in a previous Sprint or during backlog refinement.
- B) It must be established before Sprint Planning in order to begin planning: This is incorrect because the Sprint Goal is a product of Sprint Planning, not something that needs to be defined before the meeting begins. Sprint Planning itself is where the Sprint Goal is defined in collaboration between the Scrum Team, based on the Product Backlog items selected for the Sprint.
- C) A...
Author: Liam · Last updated May 20, 2026
True or False: The Product Owner makes sure the Developers select enough from the Product Backlog fo...
Let's break down the statement:
"The Product Owner makes sure the Developers select enough from the Product Backlog for a Sprint to satisfy the stakeholders."
- Rejection: In Scrum, the Product Owner is responsible for ensuring that the Product Backlog is well-structured, prioritized, and contains the necessary items to maximize value. However, it is the Development Team (not the Product Owner) that selects the items from the Product Backlog to work on during Sprint Planning. The Development Team decides how much work they can commit to based on their capacity and the team's understandi...
Author: FlamePhoenix2025 · Last updated May 20, 2026
A new Developer is having continuing conflicts with existing members of the Scrum Team, which is impacting the delivery of the Increment. If necessary, ...
In Scrum, conflicts within the team should be addressed in a way that preserves the team's ability to collaborate and deliver a valuable product increment. Let’s evaluate each option:
A) The hiring manager is responsible, because they hired the Developer.
- Rejection: While the hiring manager is responsible for bringing the Developer onto the team, they are not responsible for resolving interpersonal conflicts that arise within the team itself. The hiring manager typically does not have the authority or insight into the day-to-day dynamics and collaboration issues within the Scrum Team.
B) The Product Owner is responsible, because they control the return on investment (ROI).
- Rejection: While the Product Owner is responsible for the product backlog and maximizing ROI, they are not directly responsible for team dynamics and interpersonal conflicts. Their focus is on delivering value through the product, not on managing the team’s internal issues.
C) The Scrum Master is responsible, because they remove Impediments.
- Selection...
Author: NightmareDragon2025 · Last updated May 20, 2026
