PMI Practice Questions, Discussions & Exam Topics by our Authors
A newly formed development team experienced difficulty with accurately estimating product backlog items. As a result, the team failed to deliver all of the features in the sprint backlog for the pas...
To address the challenge of inaccurate estimates, it's important to focus on improving the team's ability to make better and more realistic estimates, rather than merely altering the external factors like sprint duration or team size. Let’s break down each option:
A) Decrease the sprint time box until the team is able to deliver the entire agreed-upon sprint backlog in a single sprint.
- Why this might be rejected: Reducing the sprint duration doesn’t solve the underlying issue with inaccurate estimations. It might result in even more pressure on the team, potentially leading to rushed or poor-quality work. If the team is consistently failing to deliver in the current sprint duration, cutting the time might only worsen the situation without addressing the root cause of the inaccurate estimates.
- Key consideration: Estimation skills, not sprint length, need to improve.
B) Discuss estimating techniques in the daily scrum meeting.
- Why this might be selected: The Daily Scrum is primarily a meeting for synchronization, not for problem-solving. Although it's important to regularly discuss obstacles in the team, the focus of estimating techniques should ideally happen in a dedicated meeting or retrospective, where the team can reflect on past sprints and adjust estimation practices. Continuously discussing estimation methods in the Daily Scrum could take away from the focus of that meeting.
- Key consideration: Estimation techniques should be reviewed in a focused manner, such as during sprint planning or retrospectives, rather than daily.
C) Increase the size of the development team until the team is able to deliver the entire agreed-upon sprint backlog in a single sprint.
- Why this might be rejected: Simply adding more people does not guarantee more accurate estimations or improved performance. In fact, it can lead to coordination challenges and higher complexity in communication. The issue is likely not...
Author: SolarFalcon11 · Last updated May 12, 2026
Midway through a sprint, the scrum master identifies that reassigning a certain task could help the team meet its spr...
In this scenario, the scrum master identifies a potential improvement that could help the team meet the sprint goals by reassigning a task. However, the scrum master must take care to follow Scrum principles and make the most collaborative, transparent, and empowering decision with the team. Let's break down each option:
A) Alert the team that sprint goals might not be met and create an alternative plan.
- Why this might be rejected: This option might be premature and not aligned with the Scrum approach. Alerting the team that sprint goals might not be met could introduce unnecessary concern or urgency without first exploring the potential solutions and consulting the team. Creating an alternative plan without team input may also undermine self-management and transparency. The team is responsible for adapting the sprint backlog and deciding on the best course of action, so this approach feels top-down.
- Key consideration: Scrum promotes collaboration and team autonomy, so alerting the team in this way could be counterproductive.
B) Obtain team buy-in to perform modifications to the sprint backlog.
- Why this might be selected: This is the most aligned with Scrum principles. The scrum master facilitates collaboration but does not dictate what happens to the sprint backlog. If the scrum master believes reassigning a task could help meet the sprint goal, the next logical step is to bring this up with the team to discuss it and obtain their buy-in. The team, not the scrum master, owns the sprint backlog and has the autonomy to decide how to adjust their work. This ensures the team remains self-organizing, empowered, and collaborative.
- Key consideration: Scrum values team autonomy and collaboration. Modifying the sprint backlog requires team consensus, and the scrum master should facilitate that decision-making process.
C) ...
Author: Nia · Last updated May 12, 2026
During the iteration planning of a newly on boarded agile team, the product owner adds a set of high priority user stories into the iteration backlog.
What should t...
When a newly onboarded agile team is preparing for iteration planning and the product owner has added high-priority user stories to the iteration backlog, the next step is crucial for the team to understand what tasks need to be implemented. Let’s evaluate each option:
A) Self-organize
- Why this might be selected: Self-organization is a core principle of Scrum. The team needs to break down the user stories into tasks and decide how to implement them collectively. This process typically involves discussing the user stories, refining the backlog, and collaboratively determining the necessary tasks to achieve the goal. Self-organizing means that the team takes the responsibility for splitting the work and figuring out how to approach it, which aligns with agile values.
- Key consideration: In agile frameworks, it's the team’s responsibility to break down work, discuss how to implement it, and assign it to individuals based on capacity and skill. This ensures ownership and alignment with team capabilities.
B) Assign tasks to each team member
- Why this might be rejected: Assigning tasks to each team member upfront isn’t an effective way to approach agile planning. In Scrum, the team typically decides who works on what based on the work at hand and team availability, rather than having tasks strictly assigned by someone else (like the Scrum Master or Product Owner). The team should self-organize and determine who is best suited for each task during iteration planning or once tasks are clarified.
- Key consideration: Assigning tasks directly could inhibit team collaboration and autonomy, and it might miss the benefits of team ownership over work allocation.
C) Meet with the customer
- Why this migh...
Author: Ryan · Last updated May 12, 2026
A project's first iteration contains item A, and its second iteration contains item B. The first iteration is behind schedule, which will impact the second iteration.
Since items A and B are similar, a tea...
In this scenario, the agile practitioner must consider how to best manage the relationship between the two iterations and address the issue of the first iteration being behind schedule. The key focus is on balancing prioritization, adaptability, and collaboration while ensuring that the team remains aligned with agile principles. Let’s analyze each option:
A) Defer starting the design of item B until the second iteration is being planned.
- Why this might be selected: This option ensures that the team stays focused on completing the current iteration (Item A) and avoids prematurely committing to work for the second iteration. In Scrum, it is important to finish what is started and not overload the team by starting work on future iterations until the current work is completed. This also helps avoid disrupting the planning and scope of the second iteration.
- Key consideration: Agile focuses on delivering value in increments and iterating based on what’s currently in front of the team. Starting work on item B before the second iteration is planned could lead to a lack of focus and inefficient allocation of resources, potentially delaying item A further.
B) Proceed with the design of item B, since it will hasten the second iteration.
- Why this might be rejected: Although starting the design of item B might seem like a good way to "hasten" the second iteration, this approach can be problematic for a few reasons. First, work should only be started once it is clearly part of the scope and priorities for the iteration, which are set during iteration planning. Beginning work on item B in the first iteration could result in wasted effort if the scope or priority of item B changes. Additionally, it might detract from the focus on completing item A, which is the immediate priority.
- Key consideration: Agile values focus and avoiding work that is not directly aligned with the current iteration’s goals. This option could lead to inefficiencies, confusion, and a lack of clarity in both iterations.
C) Esc...
Author: Liam · Last updated May 12, 2026
An Agile team is under pressure to deliver an application. The product owner anticipates many change requests from customers once ...
In this scenario, the Agile team is under pressure to deliver an application, and the product owner expects many change requests after the product release. The team needs to focus on adapting to customer feedback, collaborating closely with the product owner, and managing uncertainty in a way that supports Agile values. Let’s evaluate each option:
A) Demand frequent product reviews by the product owner
- Why this might be rejected: While frequent reviews could provide useful feedback, demanding them might come across as rigid or overly focused on micromanaging the product owner’s involvement. In Agile, collaboration is key, but the focus should be on continuous improvement and iterative feedback rather than just pushing for frequent reviews. This option doesn't specifically address how to handle the anticipated changes and customer requests in a practical, sustainable way.
- Key consideration: Agile emphasizes collaboration and self-organizing teams, but demanding frequent reviews could cause friction or unnecessary pressure on the product owner and disrupt the workflow.
B) Continuously work with the product owner to do backlog refinement and product reviews
- Why this might be selected: This option aligns with core Agile principles of continuous collaboration and feedback loops. The team should engage in backlog refinement sessions regularly with the product owner to ensure that the most important features and changes are prioritized. This is critical for handling changes from customers post-release, as it ensures that the backlog is always updated, that features align with customer needs, and that the team is flexible and responsive to evolving requirements. Frequent product reviews allow the team to get regular feedback, improving the product incrementally.
- Key consideration: This approach fosters proactive engagement with the product owner and provides the team with an evolving understanding of the product's priorities, helping them handle change requests smoothly an...
Author: Liam · Last updated May 12, 2026
During iteration planning, it was determined that an epic should be decomposed.
What was the determ...
The determining factor for decomposing an epic typically revolves around breaking down large, high-priority features or tasks into smaller, more manageable work units that can be completed within a specific iteration. The option selected is based on understanding which factor would most effectively allow teams to start delivering value quickly and make the epic more actionable for iteration planning.
Here’s a breakdown of the options:
A) Size and Priority
- Explanation: This option focuses on breaking the epic down based on its size and the priority of the individual components. Large epics often need to be decomposed into smaller, deliverable pieces so that the team can start working on manageable tasks. The priority ensures that the highest value features are addressed first.
- Why selected: It’s a direct and common approach in Agile environments to decompose epics based on size (to ensure they are actionable within an iteration) and priority (to maximize business value early).
- Why other options are rejected:
- Minimum marketable features: While important, this approach is more about defining the smallest deliverable increment of a product rather than decomposing the entire epic into actionable tasks.
- Release plan: Focuses on when things are released, not necessarily on decomposing an epic for iteration planning.
- Sprint mapping: Sprint mapping involves identifying which tasks go into a specific sprint, but doesn’t directly address decomposing an epic itself.
Best used in: Scenarios where you need to break a large epic into smaller chunks f...
Author: Ava · Last updated May 12, 2026
What should a scrum master do when one team member falls behind in their tasks?
When a team member falls behind in their tasks, the Scrum Master’s primary responsibility is to ensure the team remains focused on achieving its goals and to facilitate collaboration to address issues that arise. The approach should ideally focus on team collaboration and support, not on individual punishment or blame. Let’s break down the options and see which one best addresses the situation:
A) Move the task to another team member who has spare capacity in the sprint
- Explanation: This option is about redistributing the workload within the team. If another team member has spare capacity and is willing, they could pick up the task to ensure the sprint goal is still met.
- Why rejected: While this can be helpful in the short term, it doesn’t address the root cause of why the team member fell behind. It may also lead to burnout or resentment among other team members if overused. The Scrum Master should first try to understand and resolve why the team member fell behind before redistributing work.
- Best used in: Situations where a team member is completely blocked or unable to progress, and there is a need to redistribute tasks immediately to prevent a bottleneck.
B) Ask the team for suggestions
- Explanation: This option leverages the collective knowledge of the team. The Scrum Master can ask the team how to best support the individual who is falling behind, encouraging collaborative problem-solving.
- Why selected: This approach fosters a sense of ownership and collaboration within the team. It opens up a dialogue to understand the issue more deeply and explore solutions together, whether it's adjusting the workload, offering support, or rethinking how the work is being approached. It aligns with the Scrum values of transparency, inspection, and adaptation.
- Why other options are rejected:
- Privately offering encouragement: This is important for maintaining motivation, but it doesn’t help the team member overcome the issue if it’s a recurr...
Author: Emma Brown · Last updated May 12, 2026
A newly formed scrum team wants to foster an environment for transparency and experimentation. The team decides to use a Kanban board to record and track encountered impediments. Emphasis is placed on how issues are resolved and the...
When a newly formed Scrum team emphasizes transparency and experimentation, and uses a Kanban board to track impediments, the goal is to foster a continuous improvement culture. This approach encourages reflection on how issues are resolved and how to prevent them in the future. The focus is on process improvements and addressing bottlenecks to optimize team performance. Let’s examine the options in detail:
A) Kaizen
- Explanation: Kaizen is a Japanese term meaning "continuous improvement." It focuses on small, incremental changes to improve processes over time, which is exactly what this Scrum team is aiming for. By tracking impediments and emphasizing strategies for resolving them and preventing recurrence, the team is engaging in a form of Kaizen. This approach aligns perfectly with the principles of Scrum and Agile, as it encourages constant learning, reflection, and adaptation.
- Why selected: The team is focusing on continuous improvement by identifying and resolving impediments, then experimenting with strategies to prevent them in the future. This leads to a process of ongoing, small improvements—exactly what Kaizen promotes.
- Why other options are rejected:
- SMART goals: While SMART goals are valuable for setting clear objectives, they are typically more about setting specific, measurable targets for performance. This is not the central focus of fostering an environment of transparency and experimentation in this case.
- Key performance indicators (KPIs): KPIs measure performance and can track progress, but they are often used to assess success after the fact. They don't necessarily encourage the same level of experimentation or continual process improvements that Kaizen does.
- Muda: Muda refers to waste or inefficiency in a process. While this is certainly related to the idea of continuous improvement, the emphasis here is on fostering an environment of experimentation and learning. Muda is more about identifying and eliminating waste, but it doesn't explicitly support the focus on experimentation and reflection that the team aims for.
B...
Author: Vikram · Last updated May 12, 2026
A mature agile team welcomes a new member. Due to poor experiences with a previous team, the new member is reluctant to com...
When a mature Agile team welcomes a new member who is reluctant to communicate due to poor previous experiences, the Agile project leader's primary goal should be to create a safe and supportive environment that encourages open communication and trust. The approach should focus on addressing the individual’s concerns while also fostering integration into the team dynamic. Let’s break down the options:
A) Bring up the new member's impediments at the next meeting to demonstrate team support of input
- Explanation: This option proposes raising the new member’s concerns or impediments in a public meeting to show that the team is supportive and values input. However, doing this in a public setting might embarrass the new member or make them feel singled out, especially since they’re already hesitant to communicate. It could backfire by making them feel uncomfortable or defensive.
- Why rejected: While the intent is good (demonstrating support), this approach may inadvertently pressure the new member and reinforce their reluctance to speak up. It's important to address the individual’s concerns privately first before publicly discussing them in a team setting.
B) Assure the new member that inputs on impediments are valued, and demonstrate this at the next meeting
- Explanation: This option emphasizes reassuring the new member that their inputs are valued and provides an opportunity to demonstrate this at the next meeting. By showing appreciation for their contributions, the team leader helps to build trust and encourages the new member to feel safe enough to share. The key here is creating a supportive environment before expecting active participation.
- Why selected: This approach strikes a balance between addressing the new member’s concerns and respecting their pace. The new member is reassured privately about the value of their input, which can help them feel more comfortable over time. This creates a space for them to gradually open up without forcing them into the spotlight.
- Why other options are rejected:
- Bring up the impediments in the meeting: While the team may need to address impediments, doing this publicly risks putting pressure on the new member, which could have the opposite effect of fostering open communication.
- Have a senior leader intervene: While helpful in some situations, having...
Author: Liam · Last updated May 12, 2026
During a sprint, the team encounters a technical problem that becomes an impediment to completing tw...
When a technical problem arises during a sprint and becomes an impediment to completing stories, the Scrum Master's role is to facilitate a solution in a way that fosters collaboration, transparency, and the team’s ability to self-organize. The Scrum Master should focus on empowering the team to solve the problem collectively while ensuring the sprint goal is still achievable.
Let's evaluate each option:
A) Ask the lead developer to identify a solution, and then share the details with the team
- Explanation: This option puts the onus on one individual (the lead developer) to identify the solution and then share it with the rest of the team. While the lead developer may be skilled, this approach is somewhat contrary to the Agile principle of collaboration. The team, as a whole, should ideally come together to solve technical problems, as it promotes ownership, shared learning, and deeper team engagement.
- Why rejected: Asking just one person to come up with the solution can lead to bottlenecks and can create dependency on a single team member. This approach reduces the opportunity for the rest of the team to learn and contribute, which isn’t aligned with the goal of a self-organizing Scrum team.
B) Ask a technical manager or architect to determine a solution to the problem
- Explanation: This option suggests involving a technical manager or architect to solve the problem. While external expertise can be helpful, this undermines the Scrum principle of self-organization. The Scrum team should ideally be empowered to solve problems themselves, rather than relying on outside leadership for problem-solving.
- Why rejected: Involving a technical manager or architect could create a sense of dependency on external authority, which may lead to the team becoming less confident in solving similar problems independently. It also shifts responsibility away from the team, which isn’t ideal in an Agile environment.
C) Work with the product owner to add a spike to the next sprint to identify a solution
- Explanation: A spike is a time-boxed research activity, typically used to gain knowledge or explore solutions to technical problems...
Author: MoonlitPantherX · Last updated May 12, 2026
A new team member asks what changes could accelerate a change to the project plan.
What should be t...
In response to the new team member's question about what changes could accelerate a change to the project plan, we need to consider what factors could directly impact the project's timeline, scope, or resource requirements.
A) Competitors joined forces with the team
While this could create a strategic advantage and may help improve the product or speed up development, it doesn’t immediately relate to accelerating the project's execution. The involvement of competitors might require additional planning, negotiations, or even introduce conflict. It’s not an immediate factor that will accelerate the project unless a clear strategic partnership or synergies emerge.
Reason for rejection: Although this change could be beneficial, it’s more likely to affect the project's strategic direction, not necessarily accelerate its timeline directly.
B) The customer changed requirements
Changes in customer requirements are common, but they typically result in delays rather than acceleration. If the customer asks for new features or changes the scope of the project, this usually requires revising the plan, reassigning resources, or adding new tasks, which can add time to the overall project.
Reason for rejection: While important, this change would likely cause delays or require re-planning rather than accelerate the project. It involves scope changes that need to be managed careful...
Author: MoonlitPantherX · Last updated May 12, 2026
Midway through an iteration, an agile team learns that a team member will be unavailable for the next two iterations.
...
In an agile environment, the team must be flexible, transparent, and proactive when facing disruptions like a team member being unavailable for the next two iterations. The key principle in this scenario is to maintain a high level of collaboration, adapt quickly, and ensure there are no blockers to delivering the product increment.
Let’s analyze each option:
A) Raise an impediment that resource tasks will be blocked and notify the product owner
While raising an impediment is important, simply notifying the product owner about a blocked task without taking any action would not be the most effective solution in a high-performance team. The team should be focused on solving problems rather than just flagging them.
Reason for rejection: Raising the impediment alone doesn’t offer a solution to the issue. It could delay the project further without immediate action or a clear plan to mitigate the missing resource's impact.
B) Ask the delivery manager for a temporary resource
Bringing in a temporary resource might seem like an effective way to fill the gap, but it doesn’t address the real agility principle of cross-functional teams. High-performance teams often have members who are cross-trained and can collaborate to redistribute work within the team, rather than relying on new or temporary resources. Additionally, finding and onboarding a temporary resource mid-iteration can slow down progress and impact team dynamics.
Reason for rejection: While this could be a valid option in certain cases, relying on external resources goes against the core principles...
Author: Aarav · Last updated May 12, 2026
An agile practitioner wants to ensure that stakeholders have current information about a project's prog...
In an agile environment, the focus is on continuous communication and transparency rather than rigid documentation or complex reporting systems. The key goal here is to keep stakeholders informed about the project's progress in an efficient, timely, and non-bureaucratic manner. Let’s evaluate each option:
A) Regularly circulate an updated, detailed version of the project plan
- Why it’s rejected: In Agile, detailed project plans are often considered less valuable because they are prone to frequent changes due to evolving requirements. Agile methodology emphasizes flexibility over fixed planning. The project plan can become outdated quickly, especially in fast-paced projects.
- When it could be used: In traditional project management approaches, where comprehensive documentation and detailed plans are crucial, but this is less common in Agile.
B) Frequently update the online project management office (PMO) repository site
- Why it’s rejected: This approach could work in some situations, but it may be too formal or time-consuming for stakeholders. Updating a PMO repository may not guarantee stakeholders' engagement or immediate feedback. Stakeholders may not always check the repository frequently.
- When it could be used: In larger, more structured organizations that rely on a centralized repository for documentation, but it is less agile and may be disconnected from the actual progress of the project.
C) Invite the stakeholder...
Author: MoonlitPantherX · Last updated May 12, 2026
A company has decided to combine two similar products consisting of multiple teams into one product. Engaged customers want to know how the company is looking at re-organiz...
When merging two similar products and reorganizing teams, the goal should be to foster collaboration, reduce disruption, and capitalize on synergies between the teams. The strategy should create an environment where teams can deliver value seamlessly while minimizing disruption and maintaining focus on the product's overall goals.
Let’s break down each option:
A) All the teams from both products should be simultaneously called together and allowed to completely self-manage
While self-management is a core principle of agile teams, calling all teams together without a clear structure or guidance can lead to confusion, inefficiencies, and a lack of focus. A sudden reorganization where teams are expected to self-manage without proper planning or facilitation could result in a chaotic transition, especially given the scale of merging two separate products.
Reason for rejection: This option is too vague and doesn’t consider the complexity of merging two products. It lacks structured support for the teams during the transition and could lead to confusion and inefficiency.
B) Teams that worked on similar components in the separate products should be combined to minimize disruption and capitalize on synergies
This is a strong option. By combining teams that were already working on similar components in the separate products, the company can reduce disruption by maintaining familiarity with the work. It also allows the company to capitalize on synergies between the teams, as they already have expertise in the same areas, which can accelerate the integration process. This strategy promotes continuity and minimizes the risk of operational inefficiencies.
Reason for selection: This option leverages existing knowledge and relationships, reducing the learning curve and allowing for a smoother inte...
Author: NebulaEagle11 · Last updated May 12, 2026
A client states that a product is not being built as requested.
How should the agile team address t...
When a client states that the product is not being built as requested, the agile team needs to focus on understanding the root cause of the issue and ensuring clear communication with the client. In agile, the goal is to deliver value iteratively and ensure that the client’s feedback is incorporated in real-time.
Let’s examine each option:
A) Conduct an internal review to validate functionality before shipping
An internal review is important to ensure the quality of the product, but it doesn’t directly address the client’s concern that the product is not being built as requested. This option is reactive—it validates what has been built but doesn’t engage the client early enough to clarify misunderstandings or adjust requirements. If the product isn’t aligned with the client’s expectations, it could be too late to make significant changes before shipping.
Reason for rejection: Internal reviews are important, but this option doesn’t address the core issue of understanding the client’s needs and aligning the development process with those expectations. It’s too late in the process and may not solve the misalignment.
B) Audit the quality control process to ensure that the product adheres to requirements
Auditing the quality control process is useful for ensuring that the product meets certain standards and follows the agreed-upon processes. However, this approach assumes the issue is related to a breakdown in quality control, not necessarily a misalignment of the product with the client's original vision or evolving needs. If the product isn’t built as requested, it may be more of a communication issue or a misunderstanding of requirements rather than a pure quality control issue.
Reason for rejection: While auditing quality is important, this doesn’t directly address the potential misalignment betwe...
Author: Olivia Johnson · Last updated May 12, 2026
A new product owner shares the product vision during the team launch event. The team asks for clarification on the product roadmap and ...
In this scenario, the product owner is asked to clarify the product roadmap and high-level features, which typically refer to the strategic direction and key capabilities the product should achieve. Let's evaluate each option carefully.
A) Determine the required tasks for implementing the high-level features
- Reasoning: Determining the specific tasks needed for high-level features is an important step, but it is more granular and tactical. At this stage, the team is asking for clarification on the roadmap and high-level features, not the immediate tasks to implement them.
- Why not: This option would be useful later in the process, when breaking down high-level features into actionable tasks. However, it’s not directly relevant when you’re still in the early stages of clarifying what the features are.
B) Identify the detailed design for the high-level features
- Reasoning: Identifying detailed designs is typically a step that comes after defining the features and understanding the technical and functional requirements. While design is crucial, the product owner should focus on clarifying the vision and features first.
- Why not: The team’s question is not about technical design, but rather about understanding the roadmap and key features from a higher, more strategic perspective. Detailed designs would come later in the development process.
C) Prioritize the product backlog for the upcoming release
- Reasoning: This is a key part of the product owner’s role. After sharing the vision and high-level features, the next logical step is to begin refining and prioritizing the product backlog, which aligns the team’s efforts with the strategic goals. This also helps provi...
Author: StarlightBear · Last updated May 12, 2026
An agile practitioner wants to communicate the effect of technical debt on the project.
What should...
When an agile practitioner wants to communicate the effect of technical debt on a project, they need to highlight the impact technical debt has on the project’s progress, velocity, and quality of deliverables. Let’s analyze each option.
A) Post and discuss rises in the burn down chart
- Reasoning: A burn down chart tracks the work completed over time, typically showing the progress of the team's work within a sprint. While this could be used to reflect delays caused by technical debt (such as slower progress or less work completed), it doesn’t directly communicate the cause of the problem.
- Why not: The burn down chart may not clearly reflect the underlying cause of issues, which is what the practitioner needs to communicate. This chart is better for tracking progress rather than identifying specific problems like technical debt, which requires more clarity about its impact.
B) Adjust story points to account for technical debt
- Reasoning: Adjusting story points could reflect the increased complexity or effort required to deal with technical debt, but this approach can be misleading. Story points are meant to measure effort relative to the difficulty of user stories, not technical debt per se. It might skew the team's understanding of the scope and difficulty of actual features, and it doesn’t directly address the impact of technical debt.
- Why not: This is not the best way to communicate technical debt’s effect, as it would interfere with the agile estimation process, confusing feature complexity with the broader impact of technical debt on the overall project. Adjusting story points doesn’t provide transparency on the long-term effects or how technical debt might slow future work.
C) Log technical debt as an impediment
- Reasoning: Logging technical debt as an impediment is a great way to highlight its impact on the project. An impediment directly communicates a barrier to progress, and it allows the team to acknowledge and track how technical debt is affecting their work. This would be an actionable item that the team can prioritize and address, either by resolving it or planning time to reduce it.
...
Author: Olivia · Last updated May 12, 2026
An agile coach realizes that a team responsible for a major release is a few months behind schedule. The marketing department is unaware of this delay, and is planning to start the...
In this scenario, the agile coach has recognized that the team is behind schedule for a major release, and the marketing department is unaware of this delay. The key challenge here is ensuring that the marketing team is informed and can adjust their plans accordingly, while also addressing the root cause of the delay within the agile team.
Let's analyze each option:
A) Meet with the agile team lead to discuss ways to improve the team velocity and get back on track
- Reasoning: While improving team velocity and performance is important, this approach is too inwardly focused. The team is already behind schedule, and discussing ways to improve velocity will not immediately resolve the issue of misalignment with the marketing campaign or set realistic expectations for stakeholders.
- Why not: The marketing campaign is already underway, and the key concern right now is communication and alignment with external stakeholders. Focusing only on improving velocity within the team doesn’t address the immediate need for transparency and collaboration with marketing.
B) Use this as a learning opportunity and allow the team to handle the situation when the marketing campaign begins
- Reasoning: This option suggests deferring responsibility to the team, letting them manage the situation when the marketing campaign begins. While agile does value learning from failure, this response could lead to frustration and confusion among both the team and marketing stakeholders.
- Why not: Allowing the team to handle the situation on their own without addressing the communication gap with the marketing department could lead to worse outcomes, including unrealistic expectations and potential damage to cross-department relationships. The agile coach has a responsibility to proactively manage these situations.
C) In the upcoming retrospective, discuss ways to improve sharing project status information
- Reasoning: Discussing project status communication in the retrospective is a good idea, but it is a longer-term solution. The current issue is that the marketing department is already unaware of...
Author: Daniel · Last updated May 12, 2026
The product owner of an agile project is frustrated because the team is unable to deliver as many features as expected. The product owner asks the team to reduce test-automation levels, since the quality assurance team will test the product at project completion. The product owner e...
In this scenario, the product owner is proposing a reduction in test-automation levels in hopes of speeding up delivery. The product owner believes that by relying on the quality assurance (QA) team for testing at the end of the project, the team will be able to deliver more features in each iteration. However, this approach raises concerns about long-term quality, feedback loops, and whether it will truly help the team deliver more in the short term.
Let's analyze the options:
A) Ask the opinion of key stakeholders and the client to ensure the correct approach is being used
- Reasoning: While it's always important to involve stakeholders in discussions, this approach doesn't directly address the issue at hand. The problem is about the trade-off between speed and quality within the development team itself. Asking stakeholders or the client may not be as productive because the issue is internal to the development and QA processes.
- Why not: The focus should be on improving the development process and ensuring that quality is maintained through continuous testing and automation, not just getting external opinions. Additionally, stakeholders and clients are likely less involved in the day-to-day technical decisions around test automation.
B) Work with the team to use this approach, and request a quality assurance iteration after every three iterations
- Reasoning: This option suggests working with the team to use the reduced automation approach and adding a QA iteration after every three iterations. While this might increase feature delivery in the short term, it introduces a delay in getting feedback on quality and could result in a bottleneck when testing is done at the end. This is risky because it means that quality issues may only be discovered late in the process, leading to rework or even worse, a failed product at the end.
- Why not: Delaying quality assurance until later iterations reduces the agility of the project. Agile works best when quality feedback is continuous and part of the iteration cycle. Relying on a dedicated QA iteration at the end doesn’t align with the agile principle of delivering working software frequently and could slow down the overall process in the long run.
C) Propose to completely eliminate test automation, since this is a quality assurance function
- Reasoning: This option is extreme and disregards the importance of test automation within an agile process. Test automation is essential for continuous integration and for ensuring that quality is maintained throughout the development process. Eliminating automation would reduce effic...
Author: Scarlett · Last updated May 12, 2026
How can an agile practitioner ensure that all key stakeholders are properly engaged in planning?
When an agile practitioner is ensuring that all key stakeholders are properly engaged in planning, the goal is to make sure that stakeholders are informed, aligned, and have input on the key aspects of the product’s direction, including features, timelines, and goals. Let’s analyze each option in detail:
A) Collect stakeholder requirements
- Reasoning: While collecting stakeholder requirements is an essential part of the planning process, this step usually occurs earlier in the product development lifecycle. It helps in understanding what stakeholders want, but it's not a comprehensive way to engage them in the actual planning of the work itself. Collecting requirements does not ensure active involvement in the planning and iteration process.
- Why not: Collecting requirements is a foundational task, but it doesn’t provide real-time engagement and collaboration in planning the iterations or deciding priorities. It's a necessary step, but not the most effective for engaging stakeholders in the continuous planning cycle of an agile project.
B) Conduct an iteration planning meeting
- Reasoning: The iteration planning meeting is where the team discusses the upcoming iteration, defines user stories, and establishes the scope of work. However, in agile, iteration planning is primarily a team-focused event. While the product owner (who represents stakeholders) attends this meeting, other stakeholders typically don’t participate directly in iteration planning.
- Why not: Stakeholders outside the development team may not be present at iteration planning meetings, and their perspectives on priorities, deadlines, and features may not be fully considered. This meeting is more about the team aligning on how to execute the next iteration, rather than ensuring broad stakeholder engagement in the overall planning process.
C) Communicate product backlog items to the stakeholders
- Reasoning: Communicating product backlog items (PBIs) to stakeholders is important for transparency, ensuring that they are aware of what is planned for the product. However, just communicating the backlog doesn’t actively engage stakeholders in shaping the plan. Stakeholders ...
Author: Ava · Last updated May 12, 2026
What should an agile practitioner do to ensure that the end product meets business requirements?
To ensure that the end product meets business requirements, the agile practitioner needs to focus on maintaining clear communication, continuous feedback, and alignment between the development team and the business stakeholders. Let’s break down each option and analyze which would best ensure that the product meets business requirements:
A) Invite the team to iteration review meetings
- Reasoning: While iteration review meetings are important for ensuring that the team has a shared understanding of progress and can adapt to changes, simply inviting the team doesn’t guarantee alignment with business requirements. The team needs to understand the why behind the features they are working on, which is often more effectively addressed by involving the product owner and stakeholders.
- Why rejected: This action alone doesn’t directly ensure that the product meets business requirements. It's more about internal team communication rather than alignment with business goals.
- Scenario: Useful for internal team synchronization, but not directly aimed at business requirement validation.
B) Obtain agreement from the product owner on business requirements
- Reasoning: The product owner plays a crucial role in representing the business’s needs. By ensuring that there is explicit agreement between the product owner and the agile practitioner (or the team), it is possible to validate that the business requirements are clear, understood, and agreed upon. This helps in ensuring that the team is building the right product features in line with business goals.
- Why selected: Ensuring agreement from the product owner guarantees that the development efforts are aligned with the business requirements and that any changes in scope are captured early. This reduces the risk of misalignment between the business's goals and the product.
- Scenario: This is particularly useful when there are multiple stakeholders with different interest...
Author: ShadowWolf101 · Last updated May 12, 2026
Based on the backlog metrics in the chart, what can explain the jump in points at the end of iterati...
To analyze the jump in points at the end of iteration 4 based on the backlog metrics, it is essential to understand what factors could lead to a sudden increase in story points. Let's break down each option and evaluate its relevance:
A) The team neglected to account for support and maintenance costs associated with other support products
- Reasoning: If the team overlooked certain support or maintenance costs in earlier iterations, this would not necessarily lead to an increase in the points for completed work. Typically, maintenance and support work are separate items or tasks that are added to the backlog as new stories, not a sudden surge in points for previous work.
- Why rejected: This doesn't explain a sudden jump in points for completed user stories. Maintenance costs wouldn't usually cause a re-estimation of completed work.
- Scenario: This option could be applicable if there was an oversight in backlog refinement for support, but it doesn’t explain the jump in points for already completed iterations.
B) The team discovered that previously accepted work could be greatly improved and added story points associated with that work
- Reasoning: If the team decided to revisit previously accepted stories and identified areas for improvement, they could have added new work and associated story points. However, this would likely result in new stories being added to the backlog, not an immediate increase in points for completed work.
- Why rejected: While this could cause an increase in points over time, it doesn’t explain a sudden jump in points within a single iteration. This would be more gradual rather than a one-time surge.
- Scenario: Useful when discussing scope changes over time but not for a single iteration's jump in points.
C) The team realized that some stories were underestimated relative to other stories and re-estimated as needed
- Reasoning: This is a plausible explanation. Sometimes, when a team gains m...
Author: FrostFalcon88 · Last updated May 12, 2026
A technical problem arises that will likely impact the stories planned for delivery in the current s...
When a technical problem arises that might impact the stories planned for delivery in the current sprint, the Scrum Master needs to address the issue in a way that aligns with the principles of Agile, supports the team, and ensures that the problem is solved in a way that maintains the sprint goals and momentum. Let’s analyze each option:
A) Consider adding a story to the next sprint to seek resolution
- Reasoning: Adding a story to the next sprint to resolve a current issue could delay resolution and might not be the most immediate or effective solution. It's a reactive approach that doesn't prioritize addressing the current sprint's immediate challenges.
- Why rejected: While this may be necessary if the problem persists, it doesn’t focus on resolving the issue in the current sprint. The Scrum Master should encourage problem-solving within the current sprint, not postpone it.
- Scenario: This option could be used if the issue is too complex to resolve in the current sprint and needs more time, but it's not the immediate course of action.
B) Immediately solve the problem on behalf of the team
- Reasoning: While the Scrum Master is there to support the team, it is not their responsibility to solve the technical problems on behalf of the team. The Scrum Master should act as a facilitator and coach, rather than taking over technical challenges themselves.
- Why rejected: Solving the problem directly would undermine the team’s ability to solve their own challenges and build autonomy. The Scrum Master’s role is to help the team find solutions, not to step in and solve problems themselves.
- Scenario: This is not ideal in an Agile environment where the focus is on team collaboration and self-organizing teams.
C) Ask the team to collaboratively work out a solution
- Reasoning: This option aligns with the principles of Agile, wh...
Author: Vivaan · Last updated May 12, 2026
How should an agile project leader interact with the product owner?
An Agile project leader, often called a Scrum Master or Agile Coach, plays a key role in facilitating communication and collaboration between the team and the product owner. The interaction between the Agile project leader and the product owner is crucial for ensuring that the product meets business goals, prioritization is effective, and the team has a clear understanding of what needs to be built. Let’s analyze each option:
A) Conduct regular one-on-one meetings to review development features and trace them back to the product roadmap
- Reasoning: One-on-one meetings are essential for ensuring the alignment of the team’s work with the product owner’s vision. However, the focus of these meetings should be more on understanding the overall product goals, ensuring prioritization, and removing roadblocks, rather than just tracing features back to the roadmap. Product backlog refinement and sprint planning meetings are more effective for tracking specific features and tasks.
- Why rejected: While useful, this option can become too focused on reviewing features without a broader context or allowing the entire team to engage in planning and feedback. It doesn’t foster the collaborative interaction needed for ongoing alignment with the team.
- Scenario: Appropriate for strategic, high-level discussions but not for daily or sprint-level collaboration, which is more needed.
B) Ensure they attend regular sprint meetings to provide product-feature feedback
- Reasoning: The product owner’s role is critical in providing feedback during sprint reviews, ensuring that features align with the business vision, and helping the team understand the priority of tasks. However, the product owner’s presence should be in reviews, backlog refinements, and sprint planning sessions, where feedback can be given on the backlog items and feature direction.
- Why selected: This option ensures that the product owner is actively involved in the iterative process of refining features and providing the necessary feedback during the sprint. It's essential to keep them closely involved with the team’s progress to ensure the product remains aligned with user and business needs.
- Scenario: Ideal for ensuring continuous feedback loops and alignment during sprint reviews and planning, fostering a collaborative environment...
Author: Noah · Last updated May 12, 2026
Midway through a sprint, a team member discovers that the product design fails to adhere to the organization's enterprise architecture standards. Since this required escalation to the architecture team for further analysis and resolution, the team was u...
In this scenario, the team faces a situation where a design fails to adhere to enterprise architecture standards, causing an escalation and ultimately leading to the cancellation of the sprint. To prevent this kind of disruption, it’s important to understand the root cause and apply the best proactive approach. Let’s analyze each option:
A) Escalated the issue to management
- Reasoning: Escalating the issue to management is a reactive approach, and it is typically reserved for resolving organizational-level conflicts or resource allocation issues. While this may be necessary in extreme cases, management intervention is not the ideal first step for solving a technical issue that could have been detected earlier.
- Why rejected: This approach does not align with Agile's principle of self-organizing teams and early identification of problems. The team should aim to resolve such issues before they escalate to the point where the sprint is canceled.
- Scenario: This would be used for issues that cannot be resolved within the team or with key stakeholders, but it should not be the first line of defense in a technical issue like this.
B) Ensured the early engagement of key stakeholders
- Reasoning: Early engagement of key stakeholders, including the architecture team, is critical in Agile to identify and resolve potential roadblocks before they impact the sprint. By involving the architecture team early on, the team would have identified the design issues related to enterprise architecture standards much earlier in the sprint cycle, potentially preventing delays and rework.
- Why selected: Engaging stakeholders early on ensures alignment with broader organizational standards and requirements, helping the team avoid critical design issues midway through the sprint. It fosters collaboration and early identification of potential blockers.
- Scenario: This approach is essential in complex projects where enterprise standards or dependencies are a key factor. It’s a preventive measure that promotes collaboration and helps mitigate risks before they impact the sprint.
C) Provided feedback to the architecture team to change the ent...
Author: CrimsonViperX · Last updated May 12, 2026
A team is transitioning from a predictive approach to an agile approach. Historically, the team has delivered work products that did not meet customer expe...
To address the issue of delivering work products that did not meet customer expectations, the best agile practice for this scenario is B) Clear definition of done and regular demos. Here’s why:
Explanation of the Selected Option:
1. Clear definition of done (DoD):
- A well-defined DoD ensures that the team has a shared understanding of when a task is considered complete. This helps avoid situations where incomplete or substandard work is delivered, as the team knows the specific criteria for completion, ensuring it meets customer expectations before being marked as finished.
2. Regular demos:
- Regularly demoing completed work to the customer provides early and frequent feedback. This ensures that the team can adjust their work based on the customer’s evolving expectations and catch any mismatches early, before too much time has passed. It helps identify misunderstandings or misalignments with customer needs, ensuring the final product is closer to their expectations.
Why Other Options Are Rejected:
1. A) Test-driven development (TDD):
- While TDD helps with writing cleaner, more reliable code and improves the quality of individual components, it doesn't directly address the core issue of customer expectations. TDD focuses on ensuring the correctness of the code but does not provide a mechanism for aligning the team’s work with what the customer wants. It’s a great practice for ensuring techni...
Author: Krishna · Last updated May 12, 2026
A team member on a scrum project previously provided support to another application. Due to this with that application, the team member's former supervisor continues assigning them tasks related to that project. The new project...
In this scenario, the most appropriate action for the Scrum Master to take is C) Ensure that the threats and risks are communicated and addressed. Here’s why:
Explanation of the Selected Option:
1. Communicating and Addressing Risks:
- The situation describes a risk where the team member is being assigned tasks outside of the current Scrum project by their former supervisor. This could lead to divided attention, decreased focus, and potential delays in the current project. By ensuring that this risk is communicated, the Scrum Master can work with the team member, the former supervisor, and possibly other stakeholders to resolve the issue or at least mitigate its impact.
- The Scrum Master should facilitate open discussions about the impact on the team’s performance and help negotiate the prioritization of tasks with the other project, possibly reassigning or shifting responsibilities to ensure that the team member can focus on the Scrum project as required.
2. Proactive Risk Management:
- Identifying and addressing this risk proactively, rather than just observing it, will help prevent potential disruptions in the sprint. Scrum is all about adaptability and addressing impediments early, and this scenario is a clear case where communication and proper risk mitigation are key to maintaining team performance and focus.
Why Other Options Are Rejected:
1. A) Monitor the threats and risks while allowing the team member to multitask on both projects:
- Allowing the team member to multitask on both projects without addressing the root cause of the problem is not advisable. Multitasking between two projects can lead to reduced efficiency, context switching, and lower quality of work. The Scrum Master should not just monitor the risk; it needs to be acti...
Author: RadiantPhoenixX · Last updated May 12, 2026
An organization initiates a pilot project to introduce agile methodology for the successful delivery of projects.
What should the project manager do to share this pro...
The best action for the project manager to take is D) Regularly meet with people across the organization to share the project's lessons learned and best practices. Here’s why:
Explanation of the Selected Option:
1. Sharing Knowledge and Lessons Learned:
- The primary goal is to ensure that the knowledge gained from the pilot project can be shared in a structured way with other business groups within the organization. Regularly meeting with people across the organization provides a dedicated time and space for sharing lessons learned, best practices, and insights gained from the pilot.
- These meetings can be tailored to focus on key takeaways and challenges faced during the pilot, allowing other teams to avoid common pitfalls and adopt successful strategies. It also promotes a culture of continuous improvement, which is central to Agile methodologies.
2. Proactive Communication:
- A meeting format ensures that the communication is two-way and interactive, allowing questions, feedback, and discussions on how to adapt the learning for different contexts. This is more effective than one-off meetings or passive observations.
Why Other Options Are Rejected:
1. A) Invite people from across the organization to attend daily stand-ups:
- Daily stand-ups are designed for the Scrum team to communicate internally about their work and progress. Inviting others from across the organization would disrupt the focus of the team, make the meetings unnecessarily crowded, and possibly slow down the team’s decision-making. It’s also not the right format for sharing broad organizational learning.
2. B) Invite people from across t...
Author: Oscar · Last updated May 12, 2026
A project team identifies a number of technical challenges with features in the next sprint.
What s...
The best course of action is C) Determine who is best qualified to address the challenges. Here’s why:
Explanation of the Selected Option:
1. Leverage Team Expertise:
- The project team should take ownership of the technical challenges and evaluate which team members have the necessary skills and experience to resolve them. By determining who is best qualified to address the challenges, the team ensures that the right person or group of people handles the specific technical issues, leading to faster resolution and more effective problem-solving.
- This approach promotes collaboration and knowledge sharing within the team and helps to build team autonomy, which is key in Agile methodologies. Additionally, addressing the challenges with the most qualified team members minimizes delays and allows the sprint to proceed with minimal disruption.
2. Empower the Team:
- Agile values team self-organization and decision-making. The team, not an external figure like a manager or the product owner, is in the best position to understand the technical details of the challenges and should be empowered to make decisions about who is best suited to tackle them. This fosters ownership and accountability.
Why Other Options Are Rejected:
1. A) Request direction from the technical manager:
- While the technical manager can provide valuable guidance, relying on them for direction could slow down the process. In Agile, the team should be self-sufficient, especially when it comes to technical decisions. Involving the technical manager for each challenge could undermine the team’s autonomy and add unnecessary layers of hierarchy, which contra...
Author: Liam123 · Last updated May 12, 2026
The team is refining user stories during the backlog grooming session and confused on the acceptance criteria and level...
The best approach in this situation is C) Define the user stories with just enough details so the team can collaborate continuously. Here’s why:
Explanation of the Selected Option:
1. Just Enough Detail:
- In Agile, the goal is to ensure that user stories are clear enough for the team to begin work but not so detailed that they become rigid or over-defined. The just enough detail approach encourages collaboration and flexibility, which are key principles in Agile. User stories should provide enough information to understand the requirement and enable further discussion, but they should not be bogged down with excessive detail at the outset. This allows the team to adapt and refine as they work together.
2. Collaboration:
- Agile emphasizes collaboration, and refining user stories during backlog grooming sessions is an ideal opportunity for the team (including developers, testers, product owners, etc.) to collaborate and ask clarifying questions. Defining just enough detail facilitates ongoing conversations, and the team can continuously refine the user story as more information becomes available through development and feedback. This flexibility allows the team to remain agile in the true sense.
Why Other Options Are Rejected:
1. A) Complete the test cases before creating the story in the backlog:
- This approach goes against the Agile principle of "working software over comprehensive documentation". Completing test cases before the story is even created is too much upfront work and contradicts the Agile principle of incremental delivery. The team should not be expected to have complete test cases before defining the story, as these may evolve over time based on development progress and discoveries made during sprint cycles. Test cases can be created as part of the story refinement or just-in-time for developmen...
Author: Elizabeth · Last updated May 12, 2026
When prioritizing features to be delivered in an iteration, on what should an agile team defer work?
When prioritizing features in an agile iteration, the team should consider factors like value, risk, and impact on the overall product goal. Here’s how to evaluate each option:
A) High-risk and high-value
- Why select: This is often the most ideal option to tackle in an iteration because, while it carries risk, the potential return is significant. Addressing high-risk, high-value features early allows the team to mitigate risk while delivering substantial value. Solving high-value items early also creates opportunities for rapid feedback and iteration. The earlier these are resolved, the easier it is to adjust course if needed.
- Why reject other options:
- It’s more effective to get high-value work done as soon as possible, especially if it's a blocker for other parts of the project.
- When to use: When the high-value feature is essential to the overall success of the project, and the team is equipped to manage and reduce the risk through collaboration and testing.
B) High-risk and low-value
- Why reject: This option is often deferred because the risk outweighs the value. High-risk features with low value don’t justify the investment of time and resources, especially if the feature doesn’t significantly move the product forward. It’s better to deal with lower-risk, higher-value tasks.
- Why not select: These tasks can be deferred to a later iteration or even eliminated entirely. Focus should be on features that provide the most value with manageable risk.
- When to use: Rarely, and typically in specific cases where the feature could bec...
Author: Sofia · Last updated May 12, 2026
On an agile project, some of the development team is struggling to understand how the tasks and user stories fit into ...
When development team members struggle to understand how their tasks and user stories fit into the overall product, it is crucial to ensure they have a clear, shared understanding of the product vision, goals, and how their work contributes to the larger objectives. Below is an analysis of each option:
A) Review the iteration goals and have the team each describe the work to create shared understanding
- Why select: This approach is highly effective because it involves team members directly in the process of sharing and understanding. By reviewing the iteration goals together, team members can align on what needs to be done and why. Having each team member describe their tasks ensures that everyone is on the same page and fosters better communication.
- Why reject other options:
- This option is selected over others because it focuses directly on creating a shared understanding within the current iteration, ensuring clarity and fostering collaboration.
- When to use: This is ideal when there is confusion about how tasks and user stories fit within the iteration. It promotes team collaboration, makes sure everyone understands their role in the iteration, and ties work to goals and outcomes.
B) Create a story map for the minimal viable product (MVP) functionality
- Why reject: While creating a story map can be very useful for organizing and visualizing how user stories fit into the larger product, it’s a more long-term solution. If the team is struggling with understanding tasks within the current iteration, this approach might not be the most immediate solution to solve the problem.
- Why not select: This option is more useful for long-term planning and ensuring that the entire product roadmap is understood, rather than addressing immediate confusion about iteration-specific work. A story map is a broader tool.
- When to use: When the team needs a larger view of how stories and features fit together over the entire product life cycle, especially during the early phases of the project when building out the MVP.
C) Capture this as a task in the re...
Author: Zara · Last updated May 12, 2026
The customer needs assistance in determining the efficiency of a set of process activities within th...
When the customer needs assistance in determining the efficiency of a set of process activities within the solution, the focus should be on identifying and improving the flow of value through the system. Here’s an analysis of each option:
A) Discuss the efficiency at the next iteration retrospective
- Why reject: The retrospective is typically used to review the team's processes, performance, and collaboration during the iteration, but it’s more inward-focused. While efficiency improvements could be discussed here, the retrospective is not the best place to address customer-facing process activities directly. It is more useful for team-level improvements than for evaluating or improving the value stream from the customer's perspective.
- Why not select: It would be too late to act on customer needs immediately if the discussion is only held at the retrospective, as this meeting happens after the iteration. It does not specifically focus on efficiency within the solution.
- When to use: Retrospectives are valuable for team improvements, but they are not the best setting for addressing customer concerns about process efficiency.
B) Review the process value stream to determine potential improvements
- Why select: This is the most relevant and effective approach. By reviewing the process value stream, the team can analyze how value flows through the system, identify bottlenecks or inefficiencies, and determine where improvements can be made. It’s a direct method for understanding how process activities impact the overall solution efficiency from both a technical and customer value perspective. Value stream mapping allows the team to visualize each step of the process and ensure that it aligns with the desired outcomes.
- Why reject other options:
- This approach is the most actionable because it directly addresses the efficiency of the processes that the customer cares about. It leads to improvements that can enhance the product’s performance and customer satisfaction.
- When to use: This approach should be used when the customer’s concern is related to the efficiency of process activities, as it focuses on identifying and removing waste, reducing inefficiencies, and optimizing ...
Author: GlowingTiger · Last updated May 12, 2026
A new agile project manager accepts an assignment to manage a well-established team. Many team members have worked together on this product for several years. During a meeting, the project manager notices that team members offer little voca...
The behavior described involves a well-established team where tasks are completed on time but there is little vocal interaction. Let’s analyze each option:
A) Synchronous
- Why reject: Synchronous behavior refers to real-time, live communication where team members actively interact with each other, often in meetings or discussions. In this case, since the team members are offering little vocal interaction, the behavior is not synchronous.
- Why not select: The lack of vocal interaction in the meeting suggests that communication is not happening in real time or through active conversation, making "synchronous" an incorrect choice for this scenario.
- When to use: This term would be appropriate when team members engage in frequent, real-time discussions or updates, which doesn't seem to be happening here.
B) Collaborative
- Why reject: Collaborative behavior involves open, active communication, and teamwork where ideas are exchanged and team members contribute collectively. The fact that the team is not engaging in vocal interaction in the meeting suggests that their communication style may be less collaborative than it could be.
- Why not select: Even though the tasks are completed on time, the absence of vocal interaction in the meeting shows a lack of open collaboration. Collaborative behavior would imply more vocal interaction and sharing of ideas.
- When to use: This term would be applicable if team members were interacting more freely and sharing ideas during meetings, contributing actively to the problem-solving process.
C) Passive-aggressive
- Why select: Passive-aggressive behavior involves indirect, often non-verbal forms of resistance or negativity, where individuals may avoid direct communication or express dissatisfaction in subtle ways. In this scenario, the team is completing the required tasks on time, but ...
Author: John · Last updated May 12, 2026
Following a successful product release, senior management asks an agile team how to improve the value of the produ...
When senior management asks an agile team how to improve the value of the product for the next release, the focus should be on delivering greater customer value, iterating based on feedback, and continuously improving the product. Let’s break down each option:
A) Conduct frequent demos and obtain feedback from users throughout the development of the next release
- Why select: This is the most effective approach for improving the value of the product. Agile methodologies thrive on customer feedback, and conducting frequent demos is an excellent way to gather user input throughout the development process. By showing the product to users early and often, the team can adjust and prioritize features based on real user needs and feedback. This iterative approach ensures that the product evolves in the right direction and provides continuous value.
- Why reject other options:
- This option emphasizes customer collaboration, feedback, and adapting to changes, which are fundamental principles of Agile. It directly aligns with improving product value.
- When to use: This should be used as a standard practice in any Agile environment, particularly when the goal is to increase value through ongoing user feedback, iteration, and delivery of small, incremental improvements.
B) Inform senior management that since the product was successfully released, the project is considered delivered and should be closed
- Why reject: This option takes a traditional "waterfall" or "project-completion" mindset, where once the product is released, the team considers the work done. However, Agile is not about completing a project and moving on; it’s about continuous improvement and delivering value in iterations. Even after a successful release, Agile teams should focus on refining and improving the product based on feedback and emerging customer needs.
- Why not select: This response dismisses the ongoing nature of Agile, where the product is never "closed." The focus should be on constant value delivery and not assuming that a successful release means the end of development.
- When to use: This option is typically appropriate in traditional project management environments, but it contradicts the core principles of Agile.
C) Request additional budget to implement a Scrum of Scrums approach to scale the teams an...
Author: Ryan · Last updated May 12, 2026
A team using Kanban identifies that their cycle time has significant variation. After brainstorming, the team determines that the root cause is ...
To address the issue of significant variation in cycle time caused by varying story sizes and risks, the team needs to focus on improving predictability by managing complexity and risk early in the process. Let’s evaluate the options one by one:
A) Reduce work in progress (WIP) limits to accommodate slack for riskier stories
- Reasoning: Reducing WIP limits helps ensure that work progresses more smoothly and avoids bottlenecks, but it doesn’t directly address the issue of varying story sizes or risks. While reducing WIP can help reduce overburdening the team, it doesn't directly mitigate the variability of story complexity or risk.
- Rejection: This approach doesn’t specifically target the core problem, which is the variation in size and risk of stories. It's more of a general process improvement, not a solution for tackling complexity upfront.
B) Create a triage step on the Kanban board to pre-identify risky stories
- Reasoning: A triage step would allow the team to assess and categorize stories early on, identifying potential risks and complexities before they enter the workflow. This can help ensure that riskier stories are given more attention upfront, possibly by breaking them down or planning for extra time. This could help reduce the variation in cycle time by providing earlier visibility into risk.
- Potential Use: This option is valuable when the team wants to have early visibility and make informed decisions about handling stories with different levels of risk. It allows the team to proactively plan for stories that might cause delays or difficulties.
- Rejection: However, it doesn’t directly address the root cause of variability in story size itself. Triage is useful, but it still leaves the size and complexity issues unaddressed. It’s a workaround, not a root-cause fix.
C) Set a policy to break down stories larger than a specified complexity, then adjust the WIP
- Reasoning: Setting a policy to break down large and complex stories is an excellent way to reduce variabilit...
Author: ShadowWolf101 · Last updated May 12, 2026
Two similar stories, A and B, are estimated at 3 story points. Story C, estimated at 8 points. After an iteration in which A and C were completed, it is found that story...
In this situation, the team has observed a discrepancy where Story A (estimated at 3 story points) took much longer than Story C (estimated at 8 story points), even though both were completed in the same iteration. The Agile practitioner needs to address this discrepancy by improving the accuracy of estimates and ensuring the team better understands the reasons for the variation in completion times.
Let's evaluate each option:
A) Assign story B more than 8 story points so to provide a better estimate
- Reasoning: This option suggests assigning more points to Story B based on the assumption that it will take longer than expected. However, Story B has already been estimated at 3 points. Simply changing the estimate after the fact doesn’t address the root cause of why Story A took longer than expected. It’s important not to inflate estimates as a quick fix, as this might lead to inconsistent or inaccurate future estimates.
- Rejection: This approach might create an artificial inflation of estimates, which is not the ideal way to resolve the problem. Estimating based on outcomes rather than effort or complexity leads to inaccurate planning in the future.
B) Add points to story B's iteration to account for the error but keep story B at 3 points
- Reasoning: This option suggests adjusting the total points for the iteration (to compensate for unexpected delays in Story A), but keeping Story B's original estimate at 3 points. While this helps to adjust for an error or unexpected complexity in the iteration, it doesn't fix the underlying problem of inaccurate estimates. It is essentially a band-aid solution that doesn’t improve the team's ability to estimate future work accurately.
- Rejection: Adjusting the points post-factum doesn’t solve the fundamental issue of estimation accuracy, which is key for continuous improvement in Agile. The goal is to learn from the discrepancy and improve future estimates.
C) Assign more resources to story B to bring it in line with the estimate
- ...
Author: Sophia Clark · Last updated May 12, 2026
The product owner of a team starts the iteration review with a quick walkthrough of the iteration goal, the list of planned stories with status, and a demo of all the stor...
In this scenario, the Product Owner starts the iteration review with a walkthrough of the iteration goal, the list of planned stories with their status, and a demo of all the stories, including work in progress. The Product Owner's approach seems to be well-intended, but there are certain things that could have been done differently to make the review more focused and productive.
Let’s analyze the options:
A) Demonstrated only the completed stories and seek stakeholder feedback
- Reasoning: The primary purpose of an iteration review is to demonstrate the value delivered, which means showing only the completed stories that meet the acceptance criteria. This allows stakeholders to see the value that has been delivered and provide feedback on those specific stories.
- Key Factors: Focusing only on completed work ensures clarity and avoids confusion, as unfinished work may not meet the required quality standards for a demo. It also helps the team focus on areas that are fully ready for feedback, reducing the risk of presenting incomplete or inaccurate information.
- Selection: This is the most appropriate approach because it ensures the Product Owner is presenting high-quality, completed work to stakeholders, ensuring feedback is based on work that has been finalized and can be used in the next iteration.
B) Presented the budget situation and review the cost variance
- Reasoning: While the budget situation and cost variance are important aspects of product delivery, they are typically not the focus of an iteration review. The iteration review is mainly about showing completed work and gathering feedback on product increments, not financial matters. Budget reviews might be appropriate for different meetings, like financial or sprint retrospectives, but not for this type of review.
- Rejection: Bringing up cost variance or budget concerns during the iteration review can distract from the core purpose of showcasing and getting feedback on the work completed during the iteration. This is more about tracki...
Author: Ishaan · Last updated May 12, 2026
The risk profile of a project has increased beyond the upper threshold of tolerance. The product owner and project leader meet to discuss an a...
When the risk profile of a project increases beyond the upper threshold of tolerance, it indicates that there are significant risks that need to be actively managed to prevent them from becoming issues that could jeopardize the project's success. The Product Owner and Project Leader need to take steps to address and mitigate those risks in a timely and efficient manner.
Let's evaluate each option:
A) Add risk mitigation tasks to the backlog, then prioritize in current and upcoming sprints
- Reasoning: Adding risk mitigation tasks to the backlog ensures that risks are actively managed, and they are given visibility in the sprint planning process. By prioritizing these tasks in the current and upcoming sprints, the team can address risks in a structured manner and ensure they don’t turn into problems later. The key here is ensuring that the mitigation efforts are actively planned and worked on, rather than being ignored.
- Selection: This is the most suitable option because it allows the team to actively address risks within the project’s planned work. Adding them to the backlog ensures that risk mitigation becomes part of the team’s regular work cycle, while prioritizing them ensures they are dealt with promptly. This approach also aligns with Agile practices by allowing flexibility in managing risks during sprint planning.
B) Add risk mitigation time to each requirement
- Reasoning: This approach suggests allocating specific time for risk mitigation as part of each requirement. While it’s important to address risks at the requirement level, simply adding time for mitigation doesn’t address the actual risk directly. The mitigation work needs to be focused on specific risk-related tasks, not just allocating extra time to requirements, which may lead to wasted effort if the risks are not clearly defined and managed.
- Rejection: This option is less effective because it could lead to an inefficient allocation of resources, without explicitly targeting the risks. The risk mitigation needs to be more focused and proactive, rather than just padding time across all requirements.
C) Apply the 80/20 rule, reserving 20 percent of each sprint's capacity for risk mitigation
- Reasoning: The 80/20 rule (...
Author: Ethan Smith · Last updated May 12, 2026
What should a team do when they complete all sprint goals earlier than expected?
When a team completes all sprint goals earlier than expected, they have time available in the sprint that can be used to further contribute to the project. The key is to make the most of this time by ensuring that the work they choose to take on is aligned with the overall product goals and priorities.
Let's evaluate the options:
A) Begin working on an item in the backlog
- Reasoning: This approach suggests that the team should independently select an item from the backlog to start working on. While this seems proactive, it is not necessarily aligned with the priorities set by the Product Owner. It could lead to the team working on something that isn’t the most important or doesn’t add the most value to the product at that moment.
- Rejection: Without consulting the Product Owner or considering priority, the team may end up choosing work that isn’t a priority or could potentially change as priorities evolve. The backlog may contain many items, but the team should focus on the most valuable ones.
B) Ask the scrum master to select an item from the backlog on which to work
- Reasoning: The Scrum Master’s role is to ensure that the team is working effectively within the Scrum framework. However, the Scrum Master is not responsible for prioritizing work; that is the role of the Product Owner. Asking the Scrum Master to select an item from the backlog might lead to confusion regarding roles and responsibilities, and the team may end up working on items that don’t directly align with the highest-value priorities.
- Rejection: This is not the best approach because the Scrum Master doesn’t have visibility into the product priorities in the same way the Product Owner does. Their role is to facilitate the process, not to make product-related decisions.
C) Ask the product owner to select an item from the backlog on which to work
- Reasoning: The Product Owner is responsible for prioritizing the backlog based on business value and overall project goals. Asking the Product Owner to select an item ensures that the t...
Author: CrimsonViperX · Last updated May 12, 2026
A product owner asks a newly formed scrum team how many story points will be completed in a sprint.
...
The situation involves a Product Owner asking the Scrum Team how many story points will be completed in the upcoming sprint. The Scrum Master's role is to guide the team to adopt the right mindset, process, and framework. Let's evaluate the options based on key factors like team maturity, sprint predictability, agile principles, and the need for empirical decision-making.
Option A: Engage the team to determine the sprint velocity based on previous agile projects
- Reasoning: This option would involve using the team's past velocity from previous agile projects to estimate how many story points they can complete in the current sprint. While this may seem practical, it doesn’t consider that each team and project is unique. Velocity can vary depending on the team's experience with the current project, the complexity of work, and various environmental factors.
- Rejected: This approach can be misleading because it assumes the velocity from other teams or projects will directly correlate with the current team's capacity, which is not always true. It also doesn’t foster the team’s involvement in determining their own pace.
Option B: Average the sprint velocity based on input from team members
- Reasoning: This option is based on subjective estimates from individual team members. While it may provide some input, it's not grounded in empirical evidence. Averaging velocities is not an effective way to predict the future performance of the team because the team has not yet worked together in the context of the new sprint's work.
- Rejected: It can lead to inaccurate expectations and a lack of alignment with actual team capacity, especially if the t...
Author: Julian · Last updated May 12, 2026
A development team for a small company experiences long delays between product completion and release for validation and testing. The company is concerned that this will impact its ability to compl...
The problem at hand is that there are long delays between product completion and release for validation and testing. The company is concerned that this delay could negatively impact the speed at which it delivers to the market. To address this issue, the team needs to identify the root causes of the delays and improve the overall process. Let's analyze the options to see which one is most suitable for this scenario.
Option A: Risk management
- Reasoning: Risk management is an essential part of project management and helps identify, assess, and mitigate risks that could hinder progress. While it is crucial to identify risks in the development and testing phases, this approach doesn't directly focus on the process inefficiencies causing the delays between completion and release. Risk management could address issues like resource constraints or technical obstacles but doesn’t necessarily identify systemic process issues that are causing delays.
- Rejected: Risk management is proactive and preventive, but it isn't the best tool for diagnosing process delays or inefficiencies. It’s more about predicting and addressing uncertainties, not about finding the root cause of a delay.
Option B: Variance and trend analysis
- Reasoning: Variance and trend analysis is a technique used to compare planned versus actual progress over time, helping teams detect deviations from their expected performance. It can reveal patterns or trends in delays between product completion and release, providing insights into whether the process is improving or deteriorating. By analyzing data over multiple sprints, the team can track whether delays are getting longer, and which stages of the process are contributing the most to the delays.
- Selected: This method is ideal because it helps identify patterns of delays over time, highlighting areas where the team is consistently behind schedule. It also provides concrete data, which can help the team focus on the exact phases or activities causing the bottleneck, such as testing or validation. The team can use this data to mak...
Author: Victoria · Last updated May 12, 2026
Toward the end of a project, the product owner discovers that the project has a high probability of failure due to a critical feature not...
The scenario described involves the Product Owner discovering that a critical feature is not functioning as expected toward the end of a project, leading to a high probability of failure. The key challenge here is to decide the next course of action based on the situation's context: the business value, the impact of the failing feature, and the remaining time/resources to fix the issue. Let's evaluate the options:
Option A: Terminate the project to cut losses
- Reasoning: This option involves cutting the project short to prevent further losses. While this could seem like a quick way to stop wasting resources, it’s a drastic decision that could ignore the potential value the project could still deliver. If the project has already delivered significant value or could still deliver partial value (even without the failing feature), terminating it might not be the best option. The decision to terminate should be based on whether the remaining work is worth the investment.
- Rejected: This option doesn’t consider the possibility of still deriving business value from the parts of the project that are functioning or could be delivered. Termination is usually a last resort after evaluating other options.
Option B: Review possible options and make an informed decision to cut losses based on delivered business value
- Reasoning: This is a balanced approach, where the Product Owner reviews the current status of the project, evaluates the business value that has been delivered, and assesses whether fixing the issue is viable. If the feature is crucial to the project’s success, it might be necessary to cut losses. If the project can still deliver value without the feature or with a workaround, it may be worth continuing. This approach considers both the cost of failure and the potential value of what has already been delivered.
- Selected: This is the best option because it focuses on making an informed, pragmatic decision. It acknowledges that not all is lost just because one feature is failing and looks for ways to salvage value, such as delivering what work...
Author: MysticJaguar44 · Last updated May 12, 2026
An agile coach is assigned to help a project team that was recently co-located close to a very popular business. Many team members visit this business during working hours which aff...
In this scenario, an agile coach is tasked with addressing a performance issue caused by team members frequently visiting a nearby popular business during working hours, which is affecting team productivity. The agile coach must address this issue in a way that encourages collaboration, self-organization, and mutual respect, while also being mindful of team morale and autonomy.
Let’s evaluate each option:
Option A: Speak with the functional managers and come to an agreement that will resolve the issue
- Reasoning: This option focuses on involving the functional managers to resolve the issue, which may seem like a way to enforce a solution. While the involvement of managers could help address organizational or systemic factors, it doesn’t directly engage the team in solving the problem. It may also create a top-down solution rather than allowing the team to take responsibility for their own behavior and performance.
- Rejected: This approach goes against the self-organizing principle in agile. Agile teams are expected to identify and solve problems themselves. Relying on managers to enforce solutions could undermine team ownership and accountability. It's important to foster team-led problem-solving instead of creating dependency on management intervention.
Option B: Explain to functional managers that too much control will inversely impact team morale
- Reasoning: While this is a valid concern (too much external control can impact team morale), this option focuses on explaining to functional managers rather than actively addressing the issue with the team. While managing morale is important, it doesn’t directly solve the problem of team members visiting the business during work hours.
- Rejected: This option places the focus on justifying a lack of external intervention rather than addressing the underlying issue with the team itself. It doesn’t provide a practical solution to help the team improve its performance or behavior directly.
Option C: Meet with the team to discuss the issue and identify specific actions to reduce or eliminate the issue...
Author: Elizabeth · Last updated May 12, 2026
After completing the release plan, the team realizes that the project is very likely to have a negat...
When the team realizes that the project is likely to have a negative ROI (Return on Investment) after completing the release plan, it's important to take immediate action to address the situation in order to mitigate the risk. The team needs to balance value delivery and cost-efficiency, while aligning with agile principles such as transparency, collaboration, and continuous improvement. Let’s evaluate each option:
Option A: Prioritize the backlog, and remove low-priority stories from the release plan to ensure a positive ROI
- Reasoning: This approach is a valid tactic for adjusting the scope of the project to maximize ROI. By focusing on high-priority features that deliver the most value, the team can help minimize waste and ensure that they’re working on the most important aspects of the project. However, this is only a partial solution. Removing low-priority stories might reduce scope, but it doesn’t directly address the underlying causes of a negative ROI (such as inefficiencies in the delivery process or a misalignment between the project’s goals and its expected value).
- Selected: This is a pragmatic approach to reduce the negative impact on ROI by ensuring that only high-value work is included. It can be part of the solution but should be complemented by other actions to fully address the root causes of the issue.
Option B: Replace some team members to reduce the release costs and minimize a negative ROI
- Reasoning: Replacing team members to reduce costs might seem like an easy way to cut expenses, but it is a short-term solution with potential negative side effects. Replacing team members could lead to a loss of knowledge, team cohesion, and productivity, which might actually hurt the project in the long run. Additionally, it doesn’t address the fundamental issue of how to improve ROI, such as improving process efficiencies or revisiting the value of the product being developed.
- Rejected: This approach is not aligned with agile principles of empowerment and sustainable development. Cutting team members to save costs can lead to decreased morale and decreased performance, which is counterproductive.
Option C: Perform a root-cause analysis to remove waste from the delivery pro...
Author: Noah · Last updated May 12, 2026
During planning for the next iteration, an agile team identifies most of the story points that are expected to be delivered.
How should an agile practitioner...
When planning for the next iteration, an agile practitioner works with the team to ensure that the scope is properly defined and that all necessary work is identified for delivery. The goal is to balance the team’s capacity and avoid overcommitting. Let’s break down each option in relation to helping identify the iteration's remaining scope:
A) Convince the team to stop planning and keep the size small
- Reasoning: While it's important to avoid overloading the team, telling the team to "stop planning" isn't ideal. The goal of iteration planning is to align on what will be delivered and ensure everyone is clear on the scope. Stopping the planning process can leave important aspects of the work unclear, creating unnecessary uncertainty.
- Why Rejected: This approach undermines the collaborative nature of iteration planning and may lead to poor decision-making. It doesn’t help identify the remaining scope; instead, it halts the planning process.
B) Identify the technically minimal and achievable tasks
- Reasoning: This approach focuses on ensuring that the team delivers working software in a minimal, technically achievable way. By identifying small, achievable tasks, the team can focus on delivering the most important features while managing risk. However, while this is a good practice for making progress, it doesn’t necessarily ensure that all necessary work is identified for the iteration, as it may lead to the team choosing only "easy wins."
- Why Rejected: While it helps avoid complexity, this approach alone may leave out important, more complex tasks or fail to align with the highest-priority backlog items.
C) Refer to the remaining prioritized backlog items
- Reasoning: The prioritized backlog is a key artif...
Author: Aarav2020 · Last updated May 12, 2026
During a project meeting, a team is faced with a difficult decision. After discussion and deliberation, the project leader makes the final decision and ends the discussion. This causes a team member t...
The scenario describes a situation in which a team member withdraws from future collaboration after a project leader makes a final decision without fully involving the team. This situation highlights a breakdown in team collaboration and engagement, which can negatively affect morale and team dynamics. The project leader needs to address how to facilitate decisions in a way that fosters collaboration and empowerment while aligning with agile principles of self-organization and shared ownership.
Let's evaluate each option:
Option A: Led by example by encouraging the team to engage in consensus-driven decision making
- Reasoning: This approach is aligned with agile principles, particularly around collaborative decision-making and shared ownership. Encouraging consensus-based decision-making helps ensure that all team members feel heard and involved, which can prevent withdrawal and foster a more engaged and motivated team. By leading by example, the project leader would be creating an environment of mutual respect and inclusivity.
- Selected: This is the best approach. Encouraging consensus-driven decision-making ensures that team members feel empowered and involved in important decisions. It avoids the scenario where one person feels excluded, fostering collaboration and ownership, which are core agile values. This approach also aligns with the self-organizing nature of agile teams.
Option B: Iterated the need for agile teams to make quick decisions, then followed up with that team member
- Reasoning: This option focuses on the need for quick decisions, which is an important principle in agile for maintaining momentum. However, reiterating the need for speed could be counterproductive if it leads to rushed decisions that exclude team members' input. While following up with the team member is helpful for addressing any issues, it doesn't prevent the initial disengagement during the decision-making process. The issue lies more in how the decision was made and the lack of inclusivity.
- Rejected: This option may prioritize speed at the cost of collaboration and engagement. It doesn't directly address the team collaboration issue or create a culture of involvement. Speed is important, but it should not come at the expense of ...
Author: Maya2022 · Last updated May 12, 2026
During sprint planning the product owner wants the team to prioritize and deliver a number of features which have the highest business value. Due to technical dependencies, the te...
In this scenario, the Product Owner wants the team to prioritize features with the highest business value, but the team disagrees due to technical dependencies. This situation highlights the need to balance business value with technical feasibility and dependencies while maintaining an agile environment where both the product owner’s needs and the team's expertise are considered.
Let’s break down each option to see which one best addresses the issue:
Option A: Encourage the product owner and team to reprioritize the features and select ones which can be delivered without any dependencies
- Reasoning: This approach encourages collaboration between the product owner and the team to reprioritize the features based on both business value and technical dependencies. The team can focus on delivering features that are high in value and can be delivered without dependencies. This solution aligns with agile principles like collaboration, flexibility, and delivering incremental value. By reprioritizing, both the product owner and the team are actively involved in finding a feasible and valuable solution.
- Selected: This is the most suitable approach because it balances the business value (as the product owner wants) with technical feasibility (as the team needs). It fosters collaborative problem-solving and ensures that features are prioritized in a way that makes them possible to deliver, avoiding delays caused by technical dependencies.
Option B: Encourage the team to continue with the current plan, do what they can, and carry forward the work not done to the next iteration
- Reasoning: This option suggests that the team should continue with the current plan even though there are technical dependencies preventing full delivery. This might lead to the team working on low-value or incomplete work, which can affect the progress and quality of the product. Carrying over work to the next sprint can lead to delays, scope creep, and diminished focus on high-value tasks. The team might not be working on the most impactful features first, and the problem of technical dependencies remains unresolved.
- Rejected: This option doesn’t address the underlying issue of technical dependencies and does not prioritize features that can be fully delivered within the sprint. It risks extending work to future iterations without addressing the core problem, which is inefficient and not aligned with agile principles of delivering in...
Author: Layla · Last updated May 12, 2026
During a project review, the team discovers customer feedback that would add scope. The project leader is concerned that the team will be unable to incorporate this feedback ...
In this scenario, the team has received customer feedback that would add scope to the project, but the project leader is concerned about the ability to incorporate this feedback while still meeting the product launch date. The project leader needs to balance the customer's needs with the team's ability to deliver within the constraints of the timeline.
Let’s evaluate each option to determine the best course of action:
Option A: Finalize the feedback in the form of a change request
- Reasoning: Finalizing the feedback as a change request formalizes the change, which could be useful for tracking and documenting scope changes. However, formalizing the feedback into a change request might slow down the process and may not be the most agile approach to handling new feedback. Agile methodologies emphasize flexibility and prioritization rather than a formalized, bureaucratic approach to change requests. This option also doesn't address the immediate need to incorporate the feedback and adjust the plan effectively.
- Rejected: This option is too formal for an agile environment, where quick adjustments and iterative changes are more appropriate. It could lead to delays and excessive process overhead.
Option B: Limit the scope of the feedback to only those changes that the team can feasibly accommodate
- Reasoning: This option focuses on limiting the scope of the feedback to the most feasible changes that the team can realistically implement within the current timeline. This approach allows for some flexibility in accommodating customer feedback without overwhelming the team or derailing the product launch. By prioritizing feasible changes, the team can focus on delivering the most important updates while still meeting the deadline.
- Selected: This is a balanced approach that aligns well with agile principles. It emphasizes prioritization and pragmatism, ensuring that only the most critical and manageable feedback is included, allowing the team to maintain their focus on the product launch date. This option also helps avoid scope creep while still addressing customer needs.
Option C: Encourage all feedback, then work with the customer to prioritize ...
Author: Sofia · Last updated May 12, 2026
An agile team is preparing a release plan for a project.
What information will the team need to com...
When an agile team is preparing a release plan, the primary goal is to estimate how much work can be delivered in a specific timeframe, ensuring that the product is delivered incrementally and that the team can manage its capacity effectively. In order to complete this release plan, the team must have the information necessary to estimate work capacity and ensure that they can meet their release goals while maintaining a sustainable pace.
Let’s evaluate each option:
Option A: Amount of work needed to complete a single user story
- Reasoning: While knowing how much work is needed to complete a single user story is important, it is only one piece of the puzzle. This detail helps with estimating story points or effort for individual stories, but it doesn’t provide the broader context needed to plan the overall release. The release plan needs a holistic view of the team's capacity, not just the effort required for one user story.
- Rejected: This option is too granular for planning a release, as it focuses only on the individual user story level, which doesn’t provide the necessary context for overall iteration or release planning.
Option B: Amount of work that can be accomplished by each team member
- Reasoning: Estimating the amount of work each team member can accomplish might seem useful, but it is not the best way to approach agile planning. Agile teams are generally self-organizing and should focus on the collective capacity of the team, not individual contributions. This approach can lead to siloed thinking or assumptions that the team’s success depends on individual effort rather than collaboration and team cohesion.
- Rejected: This option focuses on individual capacity, which is not in line with the agile principle of focusing on the team’s collective capacity and collaboration. Agile planning should focus on the team as a whole, not on individual contributions.
Option C: Amount of work that can be accomplished in an iteration
- Reasoning...
Author: RadiantPhoenixX · Last updated May 12, 2026
