Scrum Practice Questions, Discussions & Exam Topics by our Authors
When many Scrum Teams are working on the same product, should all of their Increments be integrated ...
When multiple Scrum Teams are working on the same product, integrating their Increments every Sprint is critical for maintaining transparency, alignment, and ensuring that the product evolves coherently. Let’s break down each option:
A) Yes, but only for Scrum Teams whose work has dependencies.
- This option is too narrow because the goal in Scrum is to have a fully integrated Increment at the end of each Sprint, regardless of dependencies. Focusing only on teams with dependencies could lead to fragmented product development and create silos, which undermines the Agile principle of collaboration across teams.
B) Yes, otherwise the Product Owners (and stakeholders) may not be able to accurately inspect what is done.
- This is the most appropriate answer. When multiple Scrum Teams are involved, integrating their work ensures that all teams are aligned on the same version of the product. Without regular integration, the Product Owner and stakeholders may struggle to get a clear, accurate view of the overall progress, leading to incomplete or misleading feedback. The purpose of Scrum is to deliver a potentially shippable I...
Author: Arjun · Last updated May 20, 2026
Which output from Sprint Planning provides the Development Team with a target and overarching direct...
In Sprint Planning, the output that provides the Development Team with a clear target and overarching direction for the Sprint is crucial to guiding their efforts throughout the Sprint. Let's analyze each option:
A) The Sprint Backlog.
- The Sprint Backlog is a list of the tasks or items the Development Team plans to complete during the Sprint. While it is essential for guiding the team's daily work and tracking progress, it doesn't provide the team with an overarching direction or a "target" for the Sprint. It’s more focused on specific work items, not on the broader goal of the Sprint.
B) The Sprint Goal.
- This is the correct answer. The Sprint Goal is the output from Sprint Planning that provides the Development Team with a clear target and overarching direction for the Sprint. It is a concise, high-level objective that helps the team understand the purpose of the Sprint and what they are trying to achieve. The Sprint Goal provides focus and alignment, helping the team prioritize work and make decisions throughout the Sprint.
C) The rele...
Author: Oscar · Last updated May 20, 2026
Who can cancel a Sprint?
Let's carefully evaluate the options in light of the question "Who can cancel a Sprint?" and the principles of Scrum.
A) The Scrum Team.
- Rejected: While the Scrum Team, as a whole, is responsible for delivering the Sprint Goal, they do not have the authority to cancel the Sprint. A Sprint can be canceled, but it is not a decision for the team collectively to make unless it is done in agreement with the Product Owner and potentially other stakeholders. The Scrum Team does not have the explicit power to cancel the Sprint without the involvement of the Product Owner.
B) The Scrum Master.
- Rejected: The Scrum Master is responsible for facilitating Scrum practices and ensuring that the team adheres to the Scrum framework. However, the Scrum Master does not have the authority to cancel a Sprint. This responsibility lies elsewhere, as their role is to support the team and the Product Owner, not to make decisions about the Sprint itself.
C) The Product Owner.
- Selected: According to the Scrum Guide, the Product Owner has the authority to cancel the Sprint. This is usua...
Author: IceDragon2023 · Last updated May 20, 2026
When is a Sprint over?
To determine when a Sprint is over, it’s essential to focus on the Scrum framework and the fundamental aspects of time-boxing, goals, and inspection. Let’s break down each option:
A) When the Product Owner says it is done.
- This is incorrect. While the Product Owner plays a critical role in the Sprint, especially in terms of guiding the direction and ensuring that the product is delivering value, the decision of when a Sprint ends is not solely up to them. The end of a Sprint is based on the time-box and completion of the Sprint Goal, not just on the Product Owner’s say-so.
B) When all Product Backlog items meet their definition of “Done.”
- This is not correct for determining when the Sprint is over. While the team aims to complete Product Backlog items in accordance with the definition of "Done," the Sprint itself is time-boxed. The Sprint ends when the time-box expires, regardless of whether every individual item has met the definition of "Done." Items may be complet...
Author: MoonlitPantherX · Last updated May 20, 2026
During Sprint Planning the Product Owner and the Developers are unable to reach an understanding about the highest order Product Backlog items. Because of this, the Developers are unable to determine how many Product Backlog items they can forecast for the upcoming Sprint. However, the Product Owner ...
Let’s go through the options carefully, keeping in mind the key factors such as Sprint Planning, collaboration between the Product Owner and Developers, and focus on the Sprint Goal.
A) Cancel the Sprint. Send the entire team to an advanced Scrum training and then start a new Sprint.
- Rejected: This option is not aligned with Scrum principles. Canceling the Sprint should only occur when the Sprint Goal becomes obsolete or unattainable. Sending the team to advanced training is a significant disruption to the team's workflow and does not address the immediate issue at hand. The issue here is that the Product Owner and Developers haven't reached an agreement on the backlog items, not that the team lacks skills.
B) Forecast the Product Backlog items that are most likely to meet the Sprint Goal and create the Sprint Backlog. Conclude Sprint Planning and start the development work. Continue to analyze, decompose, and create additional functionality during the Sprint.
- Selected: This option is a practical and efficient approach within the Scrum framework. The team already agreed on a Sprint Goal, so they can move forward by selecting Product Backlog items that align with this goal and start the Sprint. It’s acceptable for some forecasting and planning to happen at a high level initially, and then as work progresses, further decomposition and refinement can occur. The focus on the Sprint Goal allows the team to proceed even if all details aren’t yet clear.
C) Continue the Sprint Planning event past its timebox until an adequate number of Product Backlog items are well enough understood for the Developers to make a complete forecast. Then start the Sprint.
- Rejected: This violates the Scrum principle of respecting the timebox. The Sprint Planning event should have a timebox, and while it’s important for the team to understand the backlog items, going past the timebox leads to...
Author: Noah · Last updated May 20, 2026
How should a Development Team deal with non-functional requirements?
Non-functional requirements (NFRs) are important aspects of a product that define how the system performs, rather than what it does. These include aspects like performance, security, usability, and scalability. Let’s evaluate each option for handling NFRs in a Scrum context:
A) Ensure every Increment meets them.
- This is the most appropriate approach. In Scrum, the Development Team is responsible for delivering a potentially shippable Increment at the end of each Sprint. Non-functional requirements are integral to the quality of the product and should be addressed continuously as part of every Increment, not deferred to a later time. The Development Team must ensure that every Increment meets both functional and non-functional requirements, as these contribute to the overall product quality.
B) Make sure the release department understands these requirements, but it is not the Development Team's responsibility.
- This option is incorrect because it implies that non-functional requirements are someone else's responsibility (in this case, the release department). However, non-functional requirements are just as important as functional requirements, and it is the Development Team's responsibility to ensure that the product meets all the necessary requirements, including non-functional ones. Shifting responsibility to another depart...
Author: Aarav · Last updated May 20, 2026
How much time is required after a Sprint to prepare for the next Sprint?
Let’s break down each option carefully in relation to the Scrum framework and the key concept of how time is handled between Sprints.
A) The break between Sprints is time-boxed to 1 week for 30-day Sprints, and usually less for shorter sprints.
- Rejected: Scrum does not require a fixed, time-boxed break between Sprints. The Scrum Guide does not prescribe a specific time for a break between Sprints, and Sprints should start immediately after the previous one ends. The break between Sprints should not be arbitrarily set to a specific duration like one week. Scrum values the continuous flow of work, meaning the team should immediately start the next Sprint.
B) Enough time for the requirements for the next Sprint to be determined and documented.
- Rejected: In Scrum, the Product Backlog should already be refined and prioritized before the Sprint Planning meeting. The Sprint Planning itself is used to determine which items from the Product Backlog will be taken into the upcoming Sprint. The idea is not to have a dedicated time for determining or documenting requirements after the Sprint but to focus on planning and refining the backlog before the Sprint starts.
C) Enough time for the Development team to finish the testing from the last Sprint.
- Rejected: This option misses the point of Scrum. If testing tasks remain from the previous Sprint, it’s an indication that the work was not properly completed within the last Sprint. Scrum emphasizes that work should...
Author: Benjamin · Last updated May 20, 2026
What are two effective ways for the Scrum Team to make non-functional requirements visible? (Choose ...
To answer the question, we need to focus on the idea of "making non-functional requirements visible" within the Scrum process, with an emphasis on ensuring transparency, prioritization, and traceability of those requirements. Let’s break down each option:
A) Put them on a separate list on the Scrum board, available for all to see.
- Rejected: While this option can help make non-functional requirements visible, creating a separate list specifically for them on the Scrum board may cause confusion, as it could be seen as a task or checklist. Non-functional requirements should be treated with the same importance as functional ones, and having them in a separate list could make them seem secondary or less critical. It doesn’t promote visibility within the broader Scrum artifacts like the Product Backlog.
B) Add them to the Product Backlog to ensure transparency.
- Selected: This is a strong choice because adding non-functional requirements to the Product Backlog ensures that they are visible to all team members, stakeholders, and the Product Owner. By making them part of the backlog, non-functional requirements are subject to the same level of prioritization and refinement as any other work item. This supports transparency, visibility, and better alignment with the overall product goals. Furthermore, this also ensures that non-functional requirements can be managed, tracked, and assessed continuously.
C) Run the integration and regression tests before the end of the Sprint, and capture the open work for the Sprint Backlog of the next Sprint.
- Rejected: This option doesn't directly address the visibility of non-functional requirements. It talks about the...
Author: Chloe · Last updated May 20, 2026
When can a Development Team cancel a Sprint?
In Scrum, the decision to cancel a Sprint is generally based on significant issues that prevent the team from meeting the Sprint Goal or producing valuable work. Let’s break down each option to determine the most appropriate one:
A) It can't. Only Product Owners can cancel Sprints.
- This is incorrect. While the Product Owner plays a key role in managing the Product Backlog and the Sprint Goal, the decision to cancel a Sprint is made by the Scrum Team as a whole. Typically, the Product Owner is involved in the decision, but the Development Team and Scrum Master also have input. The whole team collaborates to assess whether a Sprint is still valuable.
B) When functional expectations are not well understood.
- This is not a reason to cancel a Sprint. If the functional expectations are unclear, the team should seek clarification from the Product Owner or stakeholders during the Sprint and adapt as needed. Canceling a Sprint is reserved for more extreme situations, where the work in the Sprint is no longer relevant or achievable.
C) When the Product Owner is absent too often.
- This is not a valid reason to cancel a Sprint. While the Product Owner’s involvement is crucial, the Sprint should continue if the team can still collaborate effectively to work on the product. If the Product Owner is frequently absent, it may indicate a problem with the process, but it's not a...
Author: Isabella · Last updated May 20, 2026
Who creates the definition of `Done`?
The definition of "Done" refers to the criteria that determine when work on a product backlog item (or increment) is complete. It involves aspects like coding, testing, and documentation requirements to ensure the product meets the expected quality.
Let's break down the options one by one:
A) The Scrum Master as he/she is responsible for the Development Team's productivity.
- While the Scrum Master is responsible for facilitating Scrum processes and removing impediments, they are not typically the ones who define "Done." They guide the Scrum Team to follow the framework but do not define the criteria for completion.
B) The Scrum Team, in a collaborative effort where the result is the common denominator of all members' definition.
- This option is the most accurate. The Scrum Team, as a whole, defines the "Done" criteria collaboratively. This involves all roles: the Product Owner, Scrum Master, and Development Team. Since it requires agreement from all involved parties, this approach ensures alignment and clarity about when a product increment...
Author: GlowingTiger · Last updated May 20, 2026
What are three ways Scrum promotes self-organization? (Choose three.)
To answer the question of how Scrum promotes self-organization, we need to consider the principles of Scrum that encourage teams to take ownership of their work, make decisions, and work collaboratively. Let’s analyze each option:
A) By not allowing documentation.
- This option is incorrect. Scrum does not prohibit documentation; it only encourages keeping it "just enough" to deliver value. Documentation should not be seen as an obstacle to self-organization but rather as a tool that can be used efficiently. Scrum emphasizes value delivery over excessive documentation, but it does not mean that documentation is entirely disallowed.
B) By the Development Team deciding what work to do in a Sprint.
- This is a correct option. One of the key ways Scrum promotes self-organization is by giving the Development Team the autonomy to decide how to accomplish the work during the Sprint. The Scrum Team collectively decides what work is feasible, and the Development Team takes ownership of the task, organizing itself to complete it within the Sprint. This autonomy fosters accountability and empowerment.
C) By preventing stakeholders from entering the development room.
- This option is incorrect. Scrum does not prohibit stakeholders from interacting with the team. In fact, the Pro...
Author: Vikram · Last updated May 20, 2026
Five new Scrum Teams have been created to build one product. A few of the developers on one of the Scrum Teams ask the Scrum Master how to coordinate ...
To address the situation where developers from one Scrum Team are asking the Scrum Master how to coordinate with the other teams, we need to consider the role of the Scrum Master in helping teams collaborate and align their efforts in an efficient, self-organizing way.
Let’s analyze each option:
A) Teach the Product Owner to work with the lead developers on ordering Product Backlog in a way to avoid too much technical and development overlap during a Sprint.
- This option partially addresses coordination but focuses too much on the Product Owner's role. The Product Owner is responsible for ordering the Product Backlog based on business value, but it is not necessarily the Product Owner’s job to minimize technical overlap. Coordination to avoid overlap between Scrum Teams should be facilitated by the Scrum Master or through the teams themselves.
B) Teach them that it is their responsibility to work with the other teams to create an integrated Increment that is inclusive of all five team's work.
- This is the best option. Scrum Teams must collaborate to ensure the integration of their work to create a cohesive, working Increment. The Scrum Master’s role here is to gu...
Author: Ishaan · Last updated May 20, 2026
Who determines when it is appropriate to update the Sprint Backlog during a Sprint?
In Scrum, the Sprint Backlog is an essential tool that is owned and updated by the Development Team. Let's evaluate each option:
A) The Project Manager
The Project Manager is not a role in Scrum. Scrum focuses on self-organizing teams, and the Project Manager's role is not part of the Scrum framework. Therefore, this is not the correct option.
B) The Development Team
This option is correct. The Development Team is responsible for managing and updating the Sprint Backlog. As they work through the Sprint, they may find it necessary to make adjustments to the tasks or items within the Sprint Backlog based on new insights or challenges. The Development Team has the autonomy to manage and adjust their backlog accordingly to meet the Sprint...
Author: Deepak · Last updated May 20, 2026
True or False: The purpose of a Sprint is to produce a valuable, useful Increment.
A) True
This statement is True. The purpose of a Sprint in Scrum is to produce a valuable, useful Increment of the product. Each Sprint aims to deliver a potentially shippable Increment that adds value to the product, which can be inspected and potentially used by the Product Owner, stakeholders, or end-users. The Increment must meet the Definition of Done and provide value toward t...
Author: Emma Brown · Last updated May 20, 2026
Which of the following is required by Scrum?
Let’s evaluate each option based on the Scrum Guide and the requirements within the Scrum framework.
A) Sprint Retrospective.
- Selected: The Sprint Retrospective is explicitly required by Scrum. It is an essential event where the Scrum Team reflects on the past Sprint and identifies improvements for the next Sprint. The goal is continuous improvement, which is a fundamental Scrum value. It provides the team with the opportunity to inspect and adapt their processes.
B) Members must be stand up at the Daily Scrum.
- Rejected: While the Daily Scrum is a required event in Scrum, the Scrum Guide does not mandate that members must stand up. The key requirement is that the Daily Scrum is a short, focused meeting (typically 15 minutes) where the team discusses progress and challenges, but standing is not a formal requirement. It’s often used as a practice to keep the meeting brief and focused, but it’s not enforced by Scrum.
C) Sprint Burndown Chart.
- Rejected: The Sprint Burndown Chart is a helpful tool, but it is not a required artifact by Scrum. While it can aid in tracking the progress of work during the Sprint, Scrum does not explicitly require teams to use a burndown chart. Teams may use different methods for tracking progress, such as Kanban boards, or rely on...
Author: Noah · Last updated May 20, 2026
When do Development Team members take ownership of a Sprint Backlog item? (Choose the best answer.)
The Sprint Backlog is a key artifact for the Development Team in Scrum, and they are responsible for managing and executing it throughout the Sprint. Let’s break down each option:
A) At the Sprint planning meeting
This is the best answer. During the Sprint Planning meeting, the Development Team discusses the items from the Product Backlog that will be worked on in the upcoming Sprint, and they break them down into smaller, more manageable tasks. Each team member then takes ownership of specific items in the Sprint Backlog based on their skills, capacity, and preferences. This marks when the team members actively commit to the items they will work on during the Sprint.
B) During the Daily Scrum
While the Daily Scrum is a meeting where team members synchronize and discuss the work done, it is not the point at which they take ownership of Sprint Backlog items. Ownership is typically established during Sprint Planning...
Author: Sophia Clark · Last updated May 20, 2026
Which two things should the Development Team do during the first Sprint? (Choose two.)
The question asks about what the Development Team should do during the first Sprint. It's important to remember that in Scrum, the focus is on delivering small, valuable increments of the product while continuously refining the work. Here’s the analysis of each option:
A) Make up a plan for the rest of the project.
- This option is not correct. In Scrum, planning is done incrementally, and the focus is on the immediate work (the first Sprint) rather than making a detailed plan for the entire project upfront. Scrum encourages flexibility and responsiveness to change, meaning there is no need to plan for the whole project from the outset.
B) Analyze, describe, and document the requirements for the subsequent Sprints.
- This option is partially valid, but it is not ideal for the first Sprint. In the first Sprint, the focus should be on delivering tangible, working functionality. While refining requirements (also known as backlog refinement) happens throughout the project, doing a heavy amount of analysis and documentation for future Sprints is not the primary goal of the first Sprint.
C) Develop at least one piece of functionality.
- This is a good choice. The f...
Author: Ethan · Last updated May 20, 2026
Who must attend the Daily Scrum?
The Daily Scrum is a crucial event in the Scrum framework, where the Development Team synchronizes and plans for the day. Let's break down the options:
A) The Scrum Master and Product Owner
While the Scrum Master may attend the Daily Scrum to ensure it runs smoothly, and the Product Owner can be present if necessary, neither of them is required to attend. The Scrum Master’s role is to facilitate and ensure the event happens, not to participate in the discussions unless needed. The Product Owner is not a mandatory attendee for the Daily Scrum unless they have a direct need to provide input. Therefore, this option is incorrect.
B) The Development Team
This option is correct. The Daily Scrum is primarily for the Development Team. They are the ones who meet every day to synchronize their efforts, discuss progress, and plan their work for the next 24 hours. The meeting is designed to focus on the team's needs for coordination and collaboration, and it is their responsibility to attend and participate in it.
C) The Developmen...
Author: Leah Davis · Last updated May 20, 2026
What is the purpose of a Sprint Review?
A Sprint Review is a key Scrum event where the Scrum Team, including the Product Owner and stakeholders, inspect the progress made in the Sprint and collect feedback. Let's break down each option:
A) To take time to judge the validity of the project
This option focuses more on assessing the overall validity of the project. However, a Sprint Review is about reviewing the increment of the product and gathering feedback, not evaluating the entire project's validity. Hence, this is not the right option.
B) To inspect the product Increment with the stakeholders and collect feedback on next steps
This option correctly describes the purpose of the Sprint Review. The Scrum Team and stakeholders inspect the Increment to see what was accomplished during the Sprint, and feedback is gathered to guide the next steps. Th...
Author: Isabella1 · Last updated May 20, 2026
What does it mean to say that an event has a time-box?
To say that an event has a time-box means that there is a constraint on the maximum amount of time that the event can take. A time-box defines an upper limit on the duration of the event, ensuring it does not go over a certain period of time. Let's break down each option:
Option A: "The event must happen at a set time."
- This option refers to a specific start time, not duration. A time-box does not necessarily require a fixed start time; it focuses on limiting the duration. Therefore, this option is incorrect.
Option B: "The event must happen by a given time."
- This option refers to an event needing to be completed by a specific end time, but it does not focus on a fixed duration. The idea of time-boxing is to focus on the event's length, not necessarily on when it should finish. This is not alig...
Author: Suresh · Last updated May 20, 2026
Scrum is a methodology that tells in detail how to build software incrementally.
Let's break down the statement: "Scrum is a methodology that tells in detail how to build software incrementally."
Key Points:
- Scrum is often misunderstood as a methodology, but it is, in fact, a framework for building software (or any product) incrementally.
- Scrum provides guidelines, roles, and events to help teams organize their work and continuously deliver valuable increments of the product. However, Scrum does not prescribe specific steps or detailed instructions for how to build software. Instead, it provides a flexible structure that can be adapted by the team.
Option A: "True"
- This option suggests that Scrum is a methodology with detailed instructions on how to build software incrementally. This is not accurate, as Scrum is not a prescriptive m...
Author: Zara · Last updated May 20, 2026
As the Sprint Planning meeting progresses, the Development Team sees that the workload is greater than they can h...
Let's analyze each option in the context of the situation described: the Development Team realizes the workload in the Sprint Planning meeting is greater than they can handle.
A) Recruit additional Development Team members before the work can begin.
- Incorrect option. The Scrum framework does not encourage adding more members mid-sprint. The Development Team is self-organizing, and the Sprint should not be altered in terms of team composition after it has started. Introducing new members could disrupt team dynamics and slow down progress due to onboarding and integration. The team should focus on adjusting the scope or work rather than recruiting additional members.
B) The Development Team ensures that the Product Owner is aware, starts the Sprint, and monitors progress.
- Correct option. If the Development Team realizes that the workload is too great, they should communicate with the Product Owner and make them aware of the situation. The Sprint can still begin, and the team should focus on working together to complete what is feasible, regularly monitoring progress. However, this option emphasizes that communication is key and that the team works within the bounds of the Sprint, making adjustments as needed, rather than halting or changing the entire approach.
C) Cancel the Sprint.
- Incorrect option. Cancelling a Sprint is a drastic measure. It is generally only done in extreme cases where the Sprint goal becomes obsolete or irrelevant (for example, if the Product Owner changes priorities dramatically). The Sprint should not be cancelled merely because the team feels the workload is too hi...
Author: Olivia · Last updated May 20, 2026
What is the key concern when multiple Development Teams are working from the same Product Backlog?
When multiple Development Teams are working from the same Product Backlog, coordination and collaboration become crucial. The concern is not just about how to organize the work, but also how to avoid conflicts, ensure smooth progress, and maintain alignment across the teams. Let’s analyze each option:
A) Minimizing dependencies between teams.
- This is the correct option. One of the key concerns when multiple teams are working from the same Product Backlog is minimizing the dependencies between them. If teams are heavily reliant on each other’s work, it can lead to delays, confusion, and bottlenecks. Scrum encourages teams to be as independent as possible to maximize productivity and avoid slowdowns caused by cross-team dependencies. This is critical when multiple teams are involved.
B) Clear definition of requirements.
- While clear requirements are important in any Scrum environment, this is not the primary concern when multiple teams are working from the same backlog. Having a well-defined Product Backlog is essential, but the main challenge when multiple teams are involved is ensuring that they can work together without creating delays due to dependencies. Clear requirements are part of the process, but they don't address the primary concern here, which is team coordination and dependency management.
C) Meeting original scope projections.
- Meeting sco...
Author: Ahmed · Last updated May 20, 2026
A properly functioning Scrum Team will have at least one Release Sprint and may well have several.
Let's break down the statement in the question and evaluate the options accordingly.
Question Analysis:
The statement says, "A properly functioning Scrum Team will have at least one Release Sprint and may well have several." In Scrum, there is no explicit mention of "Release Sprints" as a separate type of Sprint. A Sprint is always an opportunity to create an increment of work that can be released (if it meets the Definition of Done and is potentially releasable). The decision to release the increment, however, does not require a special "Release Sprint."
Option A: "True"
- This option would imply that Scrum teams are required to have at least one Sprint explicitly for releasing the product. However, the Scrum Guide does not mention a distinct "Release Sprint" and suggests that any Spr...
Author: Leah Davis · Last updated May 20, 2026
Which outcome is expected as Scrum Teams mature?
As Scrum teams mature, they gain experience and improve in various aspects of their process. Let’s analyze each option in terms of what typically happens during Scrum team maturation:
Option A: "They will improve their definition of 'Done' to include more stringent criteria."
- As Scrum teams mature, they typically refine their Definition of Done to ensure higher-quality deliverables and more precise expectations. This is aligned with continuous improvement, a key principle of Scrum. The team might refine their DoD to include more detailed criteria over time. This is a realistic and expected outcome.
Option B: "The Sprint Retrospectives will grow to be longer than 4 hours."
- Sprint Retrospectives are time-boxed based on the Sprint length, with a maximum of 3 hours for a one-month Sprint. Scrum encourages teams to keep retrospectives efficient, even as they mature. The expectation is not for the retrospectives to grow in length but rather to become more effective. So, this option is not expected.
Option C: "There is no need for a time-boxed Sprint."
- Scrum heavily emphasizes the use of time-boxed Sprints, which are integral to the framework. Even as teams mature, the practice of time-boxing...
Author: Isabella1 · Last updated May 20, 2026
Currently, your Development Teams are organized to address a single layer only (for example, front end, middle tier, back end, and interfaces). What are three things to consider when deci...
Let's carefully evaluate each option in the context of the shift from component teams (focused on a specific layer, e.g., front end, back end) to feature teams (which handle end-to-end functionality):
A) You cannot do Scrum without feature teams.
- Incorrect option. This is not true. While Scrum can benefit from feature teams, it is not a strict requirement. Scrum is a framework for organizing work and does not mandate the use of feature teams. Many organizations use component teams and still apply Scrum principles effectively. It’s about how work is organized to best meet customer needs, not about the specific team structure.
B) Productivity may suffer when making this kind of move.
- Correct option. Shifting from component teams to feature teams can initially lead to a temporary dip in productivity. This is because the teams will need time to adjust to new roles, develop cross-functional skills, and get comfortable with the different workflow of managing entire features instead of focusing on individual layers. The transition involves a learning curve and reorganization, which may reduce immediate productivity, though it can lead to more sustainable long-term efficiency.
C) Getting support from the business side first helps.
- Correct option. Moving to feature teams often requires significant organizational changes. Support from the business side is crucial because they must align with the new approach. Feature teams focus on delivering end-to-end features that provide business value, so it is important to have business stakeholders on board to help facilitate the transition and ensure that teams are aligned with the overall goals and product strategy.
D) Feature teams have less communication overhead.
- Correct option. Fe...
Author: Akash · Last updated May 20, 2026
For which is the Scrum Master responsible?
To address the question thoroughly, let's break down the roles of a Scrum Master and examine the provided options.
A) Managing the performance of the Scrum Team:
- This option is incorrect. While a Scrum Master helps remove impediments and facilitates the team's growth and development, managing performance directly is not their role. The Scrum Team is self-organizing, and performance management is typically handled by the organization or through peer reviews rather than by the Scrum Master.
B) The meetings and the objectives that a Scrum Team sets for itself:
- This option is partially correct. A Scrum Master does facilitate Scrum ceremonies (like Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), and they support the team in achieving their objectives. However, the Scrum Team itself sets its objectives (via the Product Backlog and Sprint Goal). The Scrum Master helps the team adhere to Scrum principles and provides guidance in meetings, but doesn’t directly set the objectives.
C) The Scrum framework being adopted and used properly:
- This option is correct. The Scrum Master is responsible for ensuring that the Scrum framework is properly adopted and used by the team. They act as a servant-leader, guiding the team to fol...
Author: Olivia · Last updated May 20, 2026
When must a Scrum Team release each Increment?
Let's analyze each option carefully in the context of when a Scrum team must release each Increment:
Option A: "When it makes sense to release it."
- This option suggests releasing an Increment when it is deemed appropriate or beneficial. While this is a reasonable approach in some situations, the Scrum Guide does not specify that the decision of when to release should be based solely on when it "makes sense." The framework emphasizes regular, incremental deliveries, but it doesn't allow for indefinite delays based on subjective timing. Therefore, this option does not directly address the timing requirement in Scrum.
Option B: "When the Scrum Team finishes their work."
- In Scrum, the focus is on delivering an increment that is "Done" and meets the Definition of Done (DoD). However, this does not necessarily mean the Increment must be released immediately after the team finishes their work. The Increment might be ready for release but could be held back due to business or technical reasons, such as a release schedule or dependency on other increments. This option oversimplifies the release timing and does not fully align with the Scrum Guide.
Option C: "Whenever the product is free of defec...
Author: Max · Last updated May 20, 2026
The Developers ask their Product Owner to re-order the Product Backlog. The team is waiting for an external supplier to deliver a component. Without that component there will not be enough work in the next Sprint...
Let's break down the roles and context presented in the question before selecting the correct advice for the Product Owner:
Key context:
- The Developers are asking the Product Owner to reorder the Product Backlog.
- The team is waiting on an external supplier for a component.
- Without that component, there won't be enough work for the full team in the next Sprint.
A) Remind the Product Owner that his primary concern is the flow of value reflected in the ordering of the Product Backlog.
- Correct option. The primary role of the Product Owner is to ensure that the Product Backlog is ordered in a way that maximizes the delivery of value to the customer and the business. The Product Owner should prioritize items based on business value, customer needs, and urgency. In this case, if the external component is blocking some work, the Product Owner might need to reprioritize the backlog to ensure the highest value work can still be done during the Sprint, even if some tasks have to wait for the component.
B) Tell the Product Owner to re-order the Product Backlog so the work involving the external component can be planned in a separate sprint.
- Incorrect option. Although this is a potential approach, it focuses more on "scheduling" rather than prioritizing the value-driven work. The Product Owner’s role is not about splitting tasks across sprints based solely on external dependencies, but rather about ensuring the highest value work is prioritized. If there is enough valu...
Author: Olivia · Last updated May 20, 2026
Who should make sure everyone on the Scrum Team does his or her tasks for the Sprint?
The question asks about who should ensure that everyone on the Scrum Team does their tasks for the Sprint. In Scrum, the responsibility of ensuring team members are completing their tasks is generally not a single person's job but rather a shared responsibility within the team structure. The team, as a self-organizing entity, is expected to manage itself, with support from key roles like the Scrum Master.
Analyzing Each Option:
A) The Project Manager.
- Rejected: In Scrum, there is no traditional "Project Manager" role. The Scrum framework replaces the role of Project Manager with roles like the Scrum Master and Product Owner. The Project Manager is not a role within Scrum, so they would not be responsible for ensuring that tasks are completed. This goes against Scrum principles of decentralization and self-organization.
B) The Product Owner.
- Rejected: The Product Owner is responsible for the Product Backlog, ensuring the product's vision and goals are clear, and prioritizing work. However, the Product Owner does not manage the team’s day-to-day tasks or ensure that individual tasks are being completed. This is outside their responsibility, which focuses more on the product itself rather than the process of delivering it.
C) The Scrum Master.
- Rejected: The Scrum Master facilitates Scrum events, removes impediments, and helps the team adhere to Scru...
Author: Sam · Last updated May 20, 2026
What is the main reason for the Scrum Master to be at the Daily Scrum?
The Daily Scrum is an event in Scrum where the Development Team synchronizes their work and plans for the next 24 hours. The Scrum Master's role in the Daily Scrum is to ensure that it takes place and that the team adheres to the Scrum process, but they are not there to dominate or micromanage.
Analyzing Each Option:
A) To gather status and progress information to report to management.
- Rejected: The Daily Scrum is not a reporting event for management. It is focused on the Development Team. The Scrum Master does not attend to gather progress information for higher-ups. This contradicts Scrum principles, as the Daily Scrum is for the team’s internal synchronization, not for outside reporting.
B) To write down any changes to the Sprint Backlog, including adding new items, and tracking progress on the burn-down.
- Rejected: The Scrum Master is not responsible for tracking or updating the Sprint Backlog. The Development Team manages the Sprint Backlog. The Scrum Master facilitates the Scrum events, but does not act as a data recorder or tracking authority.
C) They do not have to be there; they only need to ensure the Development Team has ...
Author: Lucas · Last updated May 20, 2026
When is it most appropriate for a Development Team to change the definition of `Done`?
The Definition of Done (DoD) is a shared understanding of the criteria that must be met for a product backlog item (PBI) to be considered complete. The decision to change it should ideally occur when the team recognizes the need to improve their process or quality standards.
Let’s break down each option:
1. A) During Sprint Planning:
Sprint Planning is primarily focused on understanding the backlog items and planning the work for the Sprint. While the team might refer to the DoD during this meeting to ensure they understand what "done" means for the selected work, Sprint Planning is not an ideal time to change the DoD. The DoD should remain stable throughout the Sprint, and changes during this meeting could disrupt the flow of work or confuse expectations.
2. B) Prior to starting a new Sprint:
A new Sprint is typically a time when the team is already aligned on the DoD for the ongoing work. Changing the DoD just before the Sprint starts could lead to confusion or misalignment on the completion criteria. However, it can be a suitable moment if th...
Author: Kai · Last updated May 20, 2026
Which Scrum Values are exhibited by not building Product Backlog items that have low business value?...
When deciding not to build Product Backlog items with low business value, it reflects the Scrum values that help guide decision-making in a way that aligns with the team's and the organization’s goals. Let's break down each option based on the reasoning:
1. A) Economic Value Added:
This is a concept related to maximizing the financial value of decisions and projects, but it's not a Scrum value. While Scrum focuses on delivering high-value work, the specific term "Economic Value Added" does not align with the core Scrum values. It's more of a financial metric than a guiding value for the Scrum framework.
2. B) Respect:
Respect is one of the Scrum values and is about recognizing the contributions, opinions, and skills of others. However, while respecting others’ input is crucial, the decision to prioritize high business value over low-value items is more about focusing on delivering value rather than about respect for individuals. Thus, this value is indirectly involved but not the primary value at play here.
3. C) Focus:
Focus is directly relevant here. By not building low-value Product Backlog items, the team is prioritizing the most important and valuable work, which reflects the value of focus....
Author: Stella · Last updated May 20, 2026
How often should Scrum Team membership change?
When considering how often Scrum Team membership should change, it is important to understand that team stability is crucial for building trust, improving collaboration, and increasing efficiency. Scrum emphasizes self-organizing teams, and frequent changes in team composition can undermine these qualities. However, changes in team membership may sometimes be necessary to address specific needs or circumstances.
Analyzing Each Option:
A) As needed, while taking into account a short-term reduction in productivity.
- Selected Option: This is a balanced approach. It acknowledges that changes to the team membership may sometimes be necessary, whether due to personnel changes, skills requirements, or other organizational needs. Importantly, it recognizes that these changes can temporarily reduce productivity, and teams should plan for that. This option allows for flexibility while keeping the potential impact on the team’s effectiveness in mind.
B) Never, because it reduces productivity.
- Rejected: While team stability is important, this option is too rigid. There may be valid reasons for changing team membership, such as scaling the team, addressing skill gaps, or organizational changes. Saying "never" ignores the reality that sometimes adjustments are required to meet evolving needs. Moreover, Scrum allows for team evolution...
Author: Kai99 · Last updated May 20, 2026
The Daily Scrum is an event that happens every day. What would be three key concerns if the frequency were to be l...
If the frequency of the Daily Scrum were lowered to every two or three days, it would have a significant impact on the team's ability to communicate, identify issues, and adapt quickly. Let's analyze the options based on this reasoning:
1. A) Opportunities to inspect and adapt the Sprint Backlog are lost.
The Daily Scrum is a key moment for the team to inspect their progress towards the Sprint Goal and adapt the Sprint Backlog if needed. Reducing the frequency of the Daily Scrum would decrease the team's ability to make timely adjustments, potentially leading to a misalignment with the Sprint Goal or missing opportunities to re-prioritize tasks.
2. B) Impediments are raised and resolved more slowly.
The Daily Scrum provides a forum for the team to raise impediments as soon as they arise. If the frequency is reduced, the team may be slower to identify and address blockers, potentially causing delays in progress. Timely removal of impediments is critical for maintaining momentum in the Sprint, so this is a valid concern.
3. C) The Product Owner cannot accurately report progress to the stakeholders.
The Daily Scrum is a time for the Development Team to align on progress and potential issues. While the Product Owner may gather some insights, they don't typically rely on the Daily Scrum to report progress to stakeholders. Progress reporting is usually based on other artifacts like the Burndown Chart, and this issue wouldn't necessari...
Author: Lucas Carter · Last updated May 20, 2026
Which statement best describes Scrum?
To best describe Scrum, it's essential to focus on its core characteristics:
1. A) A defined and predictive process that conforms to the principles of Scientific Management.
This option is not suitable for describing Scrum. While Scrum does provide structure and processes, it is empirical and adaptive, not predictive or rigidly defined. Scrum encourages flexibility and iterative improvements, which contradicts the fixed nature of Scientific Management principles. Scrum's focus is on managing complexity, not being a predictive, rigid process.
2. B) A complete methodology that defines how to develop software.
This is also incorrect. Scrum is not a complete methodology but a framework. It does not define every detail about how to develop software; rather, it provides a set of principles and practices that help teams organize their work, collaborate, and deliver value incrementally. Scrum leaves room for different technical practices and does not prescribe specific technical solutions.
3. C) A cookbook that defines best practices for software development.
Scrum ...
Author: Victoria · Last updated May 20, 2026
How should Product Backlog items be chosen when multiple Scrum Teams work from the same Product Back...
When multiple Scrum Teams work from the same Product Backlog, it’s crucial that the process for selecting Product Backlog items ensures alignment, minimizes dependencies, and supports the efficient delivery of value. Each option must be evaluated in the context of Scrum principles and how best to manage multiple teams while still maintaining a cohesive overall product vision.
Analyzing Each Option:
A) The Scrum Team with the highest velocity pulls Product Backlog items first.
- Rejected: This approach undermines the collaboration between teams and prioritizes teams based on speed rather than the value or priority of the work. Velocity can vary between teams, and prioritization should be based on value to the product, not team performance. This method can lead to inefficiency, misalignment, and potentially unbalanced workloads among teams.
B) The Development Teams pull in work in agreement with the Product Owner.
- Selected Option: This is the most appropriate choice because it allows for a collaborative approach where the teams work together with the Product Owner to select and pull in work. This ensures that the selection of items is based on priority, value, and dependencies, with the Product Owner guiding the overall product vision. It also allows for coordination across teams to ensure that the work aligns with the product goals and the teams’ capacities.
C) The Product Owner should provide each team with its own Product Backlog.
- Rejected: This contradicts the concept of a shared Product Backlog. In Scrum, the...
Author: John · Last updated May 20, 2026
You have six teams using a traditional method to deliver a product. Your management has asked you to start using Scrum. In the initial project there were separate plans and teams for the layers of a software system, i.e. one for the front-end, one for the middle tier, one for the back-end, and one for the interfaces and services. This resembles what is known as compo...
When transitioning from a traditional method to Scrum, it’s important to evaluate the structure of the teams and how they will be organized in a way that supports agility. In this case, the question asks about keeping component teams while starting Scrum, and the reasoning behind each option needs to consider the advantages and drawbacks of maintaining component teams in the early stages of Scrum adoption.
Analyzing Each Option:
A) There's less initial disruption than organizing into new teams. As they start, they will discover what works best, and how to potentially re-organize towards this.
- Selected Option: This is a reasonable approach because initially, shifting directly into feature teams can cause significant disruption. If component teams are already in place, keeping them in the early stages of Scrum allows teams to become familiar with Scrum practices without the additional complexity of team reorganization. The teams can gradually adjust to the Scrum framework, iterating toward more cross-functional feature teams as they become more comfortable with Scrum practices and principles. This approach helps ease the transition and avoid overwhelm.
B) Component teams generally have the skills needed to create a working Increment of software that provides business value.
- Rejected: While component teams may have the technical skills to build specific parts of the system, the key disadvantage here is that they tend to work in silos. Scrum requires teams to be cross-functional so that they can deliver a potentially shippable Increment in each Sprint. Component teams often have to rely on hand-offs, creating bottlenecks and delays. As Scrum promotes faster, end-to-end delivery with minimal dependencies, feature...
Author: Olivia · Last updated May 20, 2026
During a Sprint, when is new work or further decomposition of work added to the Sprint Backlog?
Let’s break down the options and assess when new work or further decomposition of work can be added to the Sprint Backlog during a Sprint:
A) When the Product Owner identifies new work.
- Incorrect option. While the Product Owner is responsible for managing and prioritizing the Product Backlog, they do not directly add new work to the Sprint Backlog. The Sprint Backlog is owned by the Development Team, and only they can decide how to break down work or add new tasks during the Sprint. The Product Owner can suggest new work or prioritize items, but they don’t control when or how new work is added to the Sprint Backlog.
B) As soon as possible after they are identified.
- Correct option. The Development Team is responsible for managing the Sprint Backlog and can add new work or further decompose existing work as soon as it is identified. This could happen anytime during the Sprint, especially during the Sprint as new information comes to light or as work needs to be broken down into smaller tasks. This ensures that the Sprint Backlog is kept up-to-date with what needs to be done and reflects the current understanding of the work.
C) When the Scrum Master has time to enter them.
- Incorrect option. The Scrum Master’s role is to facilitate and ensure the Scrum process is being followed, but they do not directly add work to the Sprint Backlog...
Author: Leah Davis · Last updated May 20, 2026
You are the Scrum Master on a newly formed Scrum Team. Which three of the following activities would probabl...
When starting up a newly formed Scrum Team, it’s crucial to focus on activities that foster communication, alignment, and understanding of roles and goals. Let’s analyze the options based on these factors:
Option A: Introduce a bonus system for the top performers in the team.
This approach doesn’t align well with Scrum values, which prioritize collaboration over individual competition. A bonus system may encourage unhealthy competition and undermine teamwork, as team members may focus more on individual achievements rather than working together towards a common goal. Scrum values encourage self-organization, transparency, and shared responsibility, not individual rewards. Therefore, this option isn’t a good fit for helping a newly formed team.
Option B: Have the Scrum Team members introduce themselves to each other and give a brief background of their skills and work history.
This is a great activity to help the team understand each other’s strengths and experiences. In a newly formed team, it's vital for team members to establish rapport and begin to communicate openly. Understanding each other's skills and backgrounds helps facilitate collaboration and trust-building, which are key for a successful Scrum Team. This activity helps the team develop a sense of familiarity and shared purpose.
Option C: Have the development managers for each Development Team member introduce their direct reports and go over their responsibilities on the Scrum Team.
While understanding roles and responsibilities is important, having development managers introduce their reports can create unnecessary hierarchy in a Scrum environment. Scrum emphasizes a self-organizing team, so introducing roles and responsibilities in this top-down manner could undermine team autonomy. The Scrum Team should collectively clarify roles, and managers shouldn’t dictate responsibilities to the team.
Option D: Ensure the Scrum Team members have compatible personalities.
Personality compatibility is often desirable but not a strict r...
Author: Ahmed97 · Last updated May 20, 2026
Select two ways in which technical debt impacts transparency. (Choose two.)
To understand how technical debt impacts transparency, we need to focus on how technical debt affects clarity and understanding of the work being done and its future implications. Let’s analyze the options based on this understanding:
Option A: When calculated and estimated, the total amount of technical debt shows exactly how long until the Product Owner can release the Increment.
This is not accurate. While tracking technical debt can provide insights into the quality and health of the system, it does not directly give a precise estimate for when an Increment will be ready for release. Technical debt reflects areas of the system that require remediation, but it does not offer a straightforward timeline for release. The timeline for release depends on many factors, not just technical debt. Therefore, this option doesn't represent how technical debt impacts transparency.
Option B: It leads to false assumptions about the current state of the system, specifically of an Increment being releasable at the end of a Sprint.
This is correct. Technical debt can hide issues in the system, leading to misunderstandings or false assumptions about the completeness or quality of the work. If technical debt accumulates and isn’t visible or addressed, stakeholders, including the Product Owner, may believe that an Increment is "done" and releasable, when in fact, there might be hidden issues that make it unstable or difficult to deploy. This impacts transparency by distorting the true state of the system.
Option C: As development progresses and code is added, the system becomes mor...
Author: Joseph · Last updated May 20, 2026
Who is responsible for managing the progress of work during a Sprint?
Let's analyze each option carefully:
A) The Scrum Master.
- The Scrum Master plays a critical role in supporting the Scrum Team by removing impediments and facilitating the Scrum events. However, the Scrum Master is not directly responsible for managing the progress of work during the Sprint. They coach the team, but the ownership of the work and progress lies with the team itself. This role helps ensure the team follows Scrum practices but doesn’t directly manage the work progress.
B) The Development Team.
- This is the most accurate option. The Development Team is responsible for managing their own progress during the Sprint. Scrum is built on self-organizing teams, meaning the Development Team must collaborate, track their progress, and make adjustments as necessary to meet the Sprint Goal. They use tools like the Sprint Backlog and daily stand-ups to manage progress. This responsibility is a core principle of Scrum, as the team is empowered to manage their work and delivery.
C) The Product Owner.
- While the Product ...
Author: Emily · Last updated May 20, 2026
Who starts the Daily Scrum?
In a Daily Scrum, the key goal is to ensure the team stays aligned on progress and potential blockers, while also respecting the time-box to keep the meeting focused and effective. Let’s analyze the options one by one:
Option A: The person coming in last.
While this could encourage punctuality, it doesn’t align with the purpose of the Daily Scrum, which is to facilitate communication and synchronization of the team’s progress. The time-boxing is important, but the order of starting doesn't directly impact the core purpose of the meeting. This is more about behavior than ensuring the meeting runs smoothly.
Option B: Whoever the Development Team decides should start.
The Development Team could indeed decide who starts, and it can help with flexibility. However, it doesn’t provide structure for consistency. Scrum generally values clear roles and processes to avoid ambiguity and confusion, so leaving the starting person to random choice could lead to a lack of clarity.
Option C: The person who has the token.
A token can be used as a tool to help with turn-taking, but it is not prescribed as the best method in Scrum. Relying on a token doesn’t have much connection to the Scrum framework’s goal of self-organization, and it may detract from the intent of the Scrum events, which is to communicate and collaborate effectiv...
Author: Nathan · Last updated May 20, 2026
A Development Team is required to deliver a done Increment by the end of a Sprint. Select two statements ...
Let's evaluate the options carefully:
A) All work the Development Team is willing to do.
- This option is not correct because "Done" in Scrum refers to work that is completed according to the Definition of Done (DoD), not just work the team is willing to do. The Definition of Done is a shared understanding of the team that ensures the Increment meets the required quality and standards. Simply doing all the work the team is willing to do doesn’t guarantee that the Increment meets the criteria for being done.
B) Ready for integration.
- This is a valid option. In many Scrum teams, part of the "Done" definition includes ensuring that the work is ready to be integrated into the larger system or product. This means that the Increment is sufficiently tested, stable, and free of known issues so that it can be integrated into the existing product without complications.
C) No work left from the definition of “Done.”
- This is also a correct option. The key part of "Done" in Scrum is that all criteria defined in the Definition of Done (DoD) are met. If the team has completed all the tasks outlined in the DoD, then the work is considered done. There should be no remaining work left according to the DoD. This means the Increment is fully complete, and nothing is left to be done before...
Author: Grace · Last updated May 20, 2026
How much of the Sprint Backlog must be defined during the Sprint Planning event?
Let’s break down each option and evaluate it based on the Scrum framework and Sprint Planning:
A) Just enough tasks for the Scrum Master to be confident in the Development Team's understanding of the Sprint.
- This option focuses on the Scrum Master's perspective, but it doesn't fully align with the purpose of Sprint Planning. The goal of the Sprint Planning event is to ensure that the entire Scrum Team (not just the Scrum Master) understands the scope of work, and the Development Team is empowered to forecast and plan the Sprint work. While the Scrum Master’s confidence is important, it doesn’t mean that this alone is the key to planning.
B) The entire Sprint Backlog must be identified and estimated by the end of the Sprint Planning meeting.
- This option is overly rigid. The Scrum Guide emphasizes that the Sprint Backlog evolves during the Sprint, and it’s not necessary to have the entire Sprint Backlog fully defined upfront. While some work needs to be planned in advance, it's okay for some tasks to emerge as the Sprint progresses. This option would be too constraining and could lead to unnecessary micromanagement of task definition during Sprint Planning.
C) Enough so the Development Team can create its best forecast of what it can d...
Author: David · Last updated May 20, 2026
A Development Team selects a set of Product Backlog items for a Sprint Backlog with the intent to get the selected items `Done` by the end of the Sprint. Which three phr...
The Definition of Done (DoD) is an important concept in Scrum because it helps ensure that the Development Team and stakeholders have a shared understanding of what constitutes a "complete" or "done" item. Let’s analyze each option in relation to the purpose of the DoD:
Option A: It controls whether the developers have performed their tasks.
While the DoD provides criteria for completeness, it does not “control” tasks. It’s not about managing individual tasks or monitoring developers. Instead, the DoD ensures that work is complete according to agreed-upon standards. It sets the quality and scope of work that must be met for an item to be considered "Done," but it doesn’t directly monitor or control individual tasks. Thus, this is not the best description of the DoD’s purpose.
Option B: It provides a template for elements that need to be included in the technical documentation.
While technical documentation could be a part of the DoD, the primary purpose of the DoD is to define when a Product Backlog item is considered done, which might include coding, testing, and integration criteria. The DoD does not serve as a template for documentation specifically but could reference the need for documentation in certain cases, depending on the team’s processes. Therefore, this option is not the best fit.
Option C: It creates transparency over the work inspected at the Sprint Review.
This is a correct description of one of the key purposes of the Definition of Done. The DoD ensures that what is presented in the Sprint Review is complete and ready for inspection. It helps to create transparency, as stakeholders and the team can clearly understand the criteria that define when a backlog item is truly complete. This promotes shared understanding and reduces ambiguity when reviewing the work.
Option D: It tracks the percent completeness of a Product Backlog item.
The Definition of...
Author: Evelyn · Last updated May 20, 2026
Who creates a Product Backlog Item's estimate?
To determine who creates a Product Backlog Item’s estimate, we need to focus on the responsibilities and collaboration outlined in Scrum.
1. A) The Development Team after clarifying requirements with the Product Owner.
This option is close but slightly incomplete. The Development Team plays a key role in estimating Product Backlog items, but the key element here is that the estimate is created by the Development Team, after clarifying the requirements with the Product Owner. This is a good choice because it emphasizes that the Development Team needs to understand the requirements before providing an estimate. However, this option could imply the Product Owner is less involved in the process, which is not true.
2. B) The Product Owner with input from the Development Team.
The Product Owner is responsible for managing the Product Backlog and ensuring it is clear, but they do not create the estimates. The estimate is created by the Development Team, though they can, and should, gather clarifications from the Product Owner to ensure they understand the requirements. Therefore, the Product Owner doesn't directly create the estimate.
3. C) The most senior people in the organization, including architects and subject matter experts.
This is incorrect in Scrum. The estimates are not created by senior people or external expe...
Author: Kai · Last updated May 20, 2026
Which of these may a Development Team deliver at the end of a Sprint?
Let’s break down each option and analyze whether it aligns with the concept of a Scrum team’s deliverable at the end of a Sprint, considering the principles of Scrum.
Option A: Failing unit tests, to identify acceptance tests for the next Sprint.
This is not correct. Failing unit tests are an indication of issues with the software, not something that can be delivered. The goal of a Sprint is to deliver an increment of working software, meaning that the team should aim to resolve issues and ensure tests pass. Leaving failing unit tests without resolution would be counterproductive and doesn’t align with the Scrum focus on delivering valuable, functioning software.
Option B: An increment of software with minor known bugs in it.
This is partially correct but not ideal. While it is possible for an Increment to have minor known bugs, Scrum emphasizes that the Increment should be "Done," meaning it meets the agreed-upon Definition of Done (DoD). A properly done Increment is free of major issues and bugs that would prevent it from being shippable or usable. Minor bugs could be allowed if they don't affect the core functionality, but it's important that the Increment is still considered usable and valuable, which means addressing bugs is generally a priority.
Option C: An increment of working software that is "Done."
This is correct. The key goal of a Sprint is to deliver an increment of software that is complete, functional, and meets t...
Author: Ava · Last updated May 20, 2026
What two factors are best considered when establishing the Sprint length? (Choose two.)
Let’s evaluate each option based on the factors that influence Sprint length:
A) The organization has mandated similar length sprints.
- While this could influence Sprint length in some organizations, it is not the best reason for determining Sprint length in Scrum. Scrum promotes flexibility, and the Sprint length should primarily be based on the team’s ability to plan and deliver work within a consistent timeframe, rather than being dictated by organizational mandates. Although consistency in Sprint length across teams can help with coordination, it's not the most essential factor when choosing Sprint length for a specific team.
B) The level of uncertainty over the technology to be used.
- This is a strong factor in determining Sprint length. When a team faces high uncertainty—such as exploring new technologies or solving complex technical problems—shorter Sprints (typically one to two weeks) allow for quicker feedback and adaptation. Shorter Sprints enable teams to quickly validate assumptions, adjust plans, and reduce risks. If the technology is unfamiliar or the problem is complex, shorter Sprints allow the team to learn and iterate more rapidly, making this a critical factor.
C) The frequency at which team formation can be changed.
- While team formation is impor...
Author: Olivia · Last updated May 20, 2026
The CEO asks the Development Team to add a `very important` item to a Sprint that is in progress. Wh...
In the scenario where the CEO asks the Development Team to add a "very important" item to a Sprint that is already in progress, let's analyze the options:
A) Add the item to the current Sprint and drop an item of equal size – This option implies that the team can adjust the current Sprint backlog to accommodate the new item. However, this approach isn’t ideal because it would require dropping an existing item, which could disrupt the team's commitment to the Sprint Goal and the expected value of the work. Sprint scope changes should be managed by the Product Owner in collaboration with the team.
B) Add the item to the current Sprint without any adjustments – This option would overload the Sprint without regard to the team's capacity, potentially jeopardizing the quality of the work and the Sprint Goal. The Development Team has a limited capacity in a Sprint, and adding new work without adjustments could lead to overwork, burnout, and failed commitments.
C) Inform the Product Owner so he/she can work with the CEO – This is the best course of action. The Product Owner is responsible for managing the Product B...
