PMI Practice Questions, Discussions & Exam Topics by our Authors
Early in a project, stakeholder analysis is performed; however, an organizational restructure redefines...
When an organizational restructure redefines key roles, the project team must adjust the stakeholder analysis to reflect the changes. This is essential for ensuring that communication, expectations, and project activities are aligned with the updated organizational structure. Below is the analysis of the options provided:
A) Note the changes to the restructure and roles that affect team activities
- This is a partial solution, as it only acknowledges the changes without taking proactive steps to engage or communicate with the affected stakeholders. While it’s necessary to note the changes, it doesn't fully address the need for updating the stakeholder analysis or engaging the stakeholders. This option alone does not ensure that the project team is fully aligned with the new roles.
B) Use direct engagement and two-way conversation to update the stakeholder analysis for any new stakeholder requirements
- This is the most proactive and comprehensive option. Engaging directly with stakeholders in a two-way conversation allows for a deeper understanding of their current needs, expectations, and potential influence on the project. By updating the stakeholder analysis through these conversations, the project team can ensure that all new or redefined roles are accurately captured, and any additional requirements are incorporated. This approach fosters collaboration, improves communication, and ensures that no critical stakeholders are overlooked.
C) Email a copy of the project vision to those redefined for key roles and ask if they need to be involved in the project
- While this approach involves communication, it is relatively passive and could lead to missing important stakeholder feedback. Simply emailing the proj...
Author: Ella · Last updated May 12, 2026
A team member has spent 5 days on a spike and the first set of experiments has not been successful. The issue is the development team member has determined a short-te...
In this situation, the project leader faces a team member who has spent 5 days on a spike but is focused on a short-term solution instead of addressing the long-term needs. The project leader needs to guide the team to either refocus on the long-term solution or redirect efforts in a way that benefits the project.
Analysis of the options:
A) Assign the spike to another resource to continue research for the long-term solution
- Why it’s rejected: While this option addresses the issue of focusing on the long-term solution, simply reassigning the task to another person without proper collaboration or understanding of the current work may not be the best approach. The current team member has already spent significant time on the spike, and passing the task to another resource may lead to the same mistakes, as they may not have sufficient context. Additionally, it doesn't foster collaboration or problem-solving within the existing team. The project leader should consider whether the current team member can adjust their approach first before making any drastic changes.
B) Re-estimate the spike, encourage experimentation, and collaborate with the team
- Why it’s selected: This option offers the best chance for addressing both the immediate problem and future success. By re-estimating the spike, the project leader allows the team to recalibrate expectations and explore a more effective path toward a long-term solution. Encouraging experimentation fosters a growth mindset, enabling team members to learn from the failure of the first set of experiments. Collaboration with the team ensures that the entire team can align on the objectives and share insights that might lead to a better solution. This approach promotes ownership, accountability, and a learning culture, which are key factors for long-term success.
C) Stop experimentation and negotiate the short-term solution with the customer
- Why it’s rejected: This option risks undermining the project’s long-term goals and would likely lead to a suboptimal solution. While negotiating a short-term solution with the customer could provide an immediate fix, it doesn’t address the root issue of the sp...
Author: Ahmed · Last updated May 12, 2026
An agile team notices that the same problems continue to occur during multiple iterations. Several team members have suggestions to fix the...
When the same problems keep reoccurring during multiple iterations, it's a clear indication that the team needs to address those issues in a structured, collaborative way. The goal is to find a sustainable solution and prevent the problem from repeating in future sprints. Below is an analysis of each option:
A) Hold frequent retrospectives and share the responsibility for making changes
- Why it’s selected: This is the most appropriate agile approach. Retrospectives are key in identifying and addressing recurring issues. In agile, retrospectives are a core practice for continuous improvement. The team should regularly reflect on the challenges they face and collaborate on solutions. Sharing responsibility for making changes ensures that the team takes ownership of the problems and solutions, fostering a culture of accountability and collective problem-solving. This aligns well with the agile principles of collaboration, transparency, and continuous improvement.
- Why it’s effective: Retrospectives create a structured space where team members can openly discuss problems, brainstorm solutions, and prioritize actions. Frequent retrospectives help teams stay aligned and ensure that necessary adjustments are made promptly. By sharing responsibility, the entire team is invested in improving the process, making it more likely that they will take the steps needed to eliminate the recurring problems.
B) Understand that this is the nature of innovative business and strive to work harder
- Why it’s rejected: While innovation often involves challenges, this mindset could prevent the team from addressing root causes of recurring problems. Simply accepting issues as part of the nature of business doesn’t align with the agile philosophy of continuous improvement. Agile encourages teams to identify problems and fix them iteratively rather than tolerating recurring issues without addressing them. Working harder is not always the answer—working smarter and making improvements is key to progress in agile.
C) Collect team member feedback and discuss them privately with the product...
Author: Arjun · Last updated May 12, 2026
An experienced product owner presents the epics and corresponding stories during a release planning session with the established team. The executive sponsor asks the t...
In this scenario, the executive sponsor is seeking a clear answer regarding the delivery timeline for the features, which is a crucial aspect of managing expectations and planning the release. The team, however, needs to make sure they provide an accurate and feasible response while adhering to agile principles. Let’s break down the options:
A) Evaluate how much can be delivered based on the Scrum Master's estimation
- Why it’s rejected: While the Scrum Master plays a critical role in facilitating the process, they typically do not provide direct estimates for the work. The Scrum Master’s role is to ensure the team is functioning well and following agile practices, not to make decisions or estimates on behalf of the team. Estimation should be a team activity, as it is the team that understands the scope and complexity of the work. Relying solely on the Scrum Master for estimates does not foster the collaboration or ownership that agile requires.
B) Identify a set of user stories based on the team's velocity
- Why it’s rejected: This option could be somewhat useful, as knowing the team's velocity (the amount of work the team typically completes per sprint) helps inform delivery estimates. However, identifying only a set of user stories based on velocity without proper estimation doesn’t account for the complexity of the work. It’s important to engage in a more detailed estimation session to accurately determine what can be delivered within the timeframe, as velocity alone might not offer enough clarity, especially if the team has not worked with similar epics before.
C) Initiate an estimation session
- Why it’s selected: This is the best approach because it allows the team to collaboratively assess the scope of the work, break it down into manageable pieces, and provide a well-informed estimate. Estimation sessions, such as planning poker or relative sizing, involve the whole team and allow them to discuss the complexity of user stories. This collaborative approach ensures that the estimates are more accurate, reflecting the expertise and experience of the entire team. It aligns with agile pri...
Author: Lucas Carter · Last updated May 12, 2026
An agile team is planning the next iteration for a product release that has accumulated technical de...
When an agile team is planning for the next iteration of a product release that has accumulated technical debt, it is essential to address the debt while ensuring that the team delivers value to the customer. The decision on how to manage this technical debt involves balancing the immediate needs of the product with long-term stability and maintainability.
A) Add code cleanup activities to the product backlog and request prioritization by the product owner
- Why it’s rejected: While adding code cleanup activities to the product backlog is a valid approach, this option might not be the best choice in the context of an iteration planning session. The backlog prioritization by the product owner is important, but waiting for the product owner to prioritize the technical debt means it may not be addressed in the upcoming iteration. Code cleanup should not be delayed if it directly impacts the quality of the product. Also, waiting for prioritization can lead to the technical debt accumulating further, which could worsen in the future.
B) Add code cleanup activities to the next iteration and request clarification from the product owner
- Why it’s selected: This is the most appropriate option because it balances the need to address technical debt while aligning with the upcoming iteration’s objectives. By adding code cleanup activities directly to the next iteration, the team ensures that they are addressing the technical debt as part of the current work. Requesting clarification from the product owner can help ensure that the cleanup activities align with the broader goals of the product and do not impede the delivery of value. This approach keeps the team focused on delivering high-quality, sustainable software while still working on customer-facing features.
- Why it’s effective: Including code cleanup in the iteration allows the team to address technical debt sooner rather than later. It ensures the team doesn’t keep pushing the problem forward, which could lead to larger, more complex issues down the line. This approach promotes a continuous focus on improving both the product and the process, which is a core principle of agile.
C) Add code cleanup activities to the next iteration and ask the product owner to end the current iteration...
Author: Ella · Last updated May 12, 2026
An agile project manager is planning the initial scope, schedule, and cost range estimates on a new project. The team will be using Kanban to control...
When an Agile project manager is planning the initial scope, schedule, and cost range estimates using Kanban, the team focuses on flow-based metrics rather than iterative metrics typically associated with Scrum or other Agile frameworks. Let's go through the options one by one to determine the most suitable metrics for Kanban.
A) Lead time, throughput, and due date performance
- Lead time: This is the time it takes for a work item to move from the "to do" state to the "done" state. It is a critical Kanban metric because it gives insights into how long work takes to complete. This helps in estimating how long similar tasks might take in the future.
- Throughput: This measures the number of items completed in a given time period. Throughput is key in Kanban because it provides insights into the team's delivery capacity over time.
- Due date performance: This is a measure of how often work is completed on or before its due date. In Kanban, this helps the team evaluate how well they are meeting deadlines.
These metrics are highly relevant to Kanban, which is focused on optimizing flow and delivery. The combination of lead time and throughput gives a clear picture of how efficiently the team is working, while due date performance provides insight into predictability.
B) Work in progress limits, Kanban board, and time boxes
- Work in progress (WIP) limits: WIP limits are a core component of Kanban, designed to prevent overloading the team by restricting the number of items in progress at any given time. However, WIP limits alone don’t provide direct insight into performance metrics like throughput or lead time.
- Kanban board: The Kanban board is a tool used to visualize the flow of work, but by itself, it doesn't measure performance. It helps in understanding the work state, but it doesn't offer quantitative data.
- Time boxes: Timeboxes are typically associated with Scrum or other time-boxed Agile approaches like sprints. Kanban, however, focuses more on continuous flow and doesn’t rely on timeboxes to manage performance.
Although these elements are key to Kanban, they do not directly me...
Author: Olivia Johnson · Last updated May 12, 2026
During project inception, an agile practitioner engages the stakeholder to ensure alignment on the project's strategy and vision. The stakeholder asks for detailed require...
When an agile practitioner engages stakeholders during the project inception phase, the focus should be on setting the right expectations and ensuring alignment on the project's vision, strategy, and high-level goals, rather than providing all detailed documentation upfront. Let’s analyze the options to determine the most appropriate approach.
A) Provide all information requested by the stakeholder
- Why this is not ideal: In Agile, detailed requirements, design specifications, and delivery plans are typically not created at the start of a project because the approach values flexibility, collaboration, and iterative development. By providing all the information upfront, the agile practitioner risks overloading the stakeholder with unnecessary detail at a stage where the project is still evolving and where change and adaptation are expected. This contradicts the agile principle of "embracing change" and delivering value in small, iterative chunks.
- Scenario where this might be used: This could be appropriate in a traditional Waterfall or predictive environment where a full upfront plan is expected. However, Agile’s adaptability contradicts the need for such detailed documentation early on.
B) Set expectations regarding the appropriate level of details requested during this stage
- Why this is ideal: In Agile, it’s crucial to set the right expectations early on. The agile practitioner should explain to the stakeholder that detailed requirements, designs, and delivery plans will evolve as the project progresses. Agile projects often begin with high-level goals, vision, and strategy, and only gather more specific details as iterations (or sprints) unfold. This helps the team remain flexible and responsive to change, while also aligning with the stakeholder's needs in a more manageable and adaptive way.
- Scenario where this should be used: This approach works well when the project is starting in an Agile environment, where both the team and stakeholders need to understand that the project will be planned and executed incrementally. Setting expectations ensures that the stakeholder is aligned with Agile principles of delivering value in small, frequent increments, and focusing on early feedback rather than over-specifying everything at the outset.
C) Inform the stakeholder that no detailed documents are provided using agile practices
- Why t...
Author: Lina Zhang · Last updated May 12, 2026
A product owner feels that the last sprint failed to sufficiently deliver what was valuable to their organization's overall project goals.
Wh...
In the situation where a Product Owner feels that the last sprint failed to sufficiently deliver value to the organization's overall project goals, the Scrum Master’s role during the retrospective is to facilitate a constructive discussion about what went wrong, what could be improved, and how to make the next sprint more effective. Let’s break down each of the options to identify the most appropriate course of action.
A) Solutions to project problems that were built into the last sprint
- Why this is not ideal: In a retrospective, the focus should not be on discussing solutions that were implemented in the last sprint, especially if those solutions failed to deliver the desired value. Solutions are important, but the retrospective is more about identifying what went wrong or what could have been done better in the previous sprint. The focus should be on process improvement, not just the application of solutions that may or may not have worked.
- Scenario where this might be used: This option could be relevant when reflecting on specific interventions that were tried in previous sprints and whether they were effective. However, in this case, the sprint didn't deliver the expected value, so it's not the right time to focus solely on what was done to solve problems in that sprint.
B) Problems that arose
- Why this is ideal: The retrospective should focus on identifying the problems that arose during the sprint and the reasons why those problems occurred. This helps the team understand what went wrong and why the sprint failed to deliver the expected value. Discussing the root causes of the problems allows the team to adapt their processes and make the necessary improvements for the future. This is the most appropriate course of action for facilitating a productive retrospective discussion.
- Scenario where this should be used: This option is ideal for this situation, where the sprint did not deliver the value expected. By addressing the problems that arose during the sprint—whether it be misalignment with goals, issues in the workflow, or other obstacles—the team can learn from the experience and make targeted improvements in future sprints.
C) Solutions that saved...
Author: VioletCheetah55 · Last updated May 12, 2026
A new product owner needs to manage the backlog of a high-visibility, fast-moving project that is consuming a considerabl...
In a fast-moving, high-visibility project, the Product Owner (PO) must focus on ensuring that the backlog is well-managed, aligned with project goals, and regularly updated based on stakeholder input. Let’s examine the options and determine the best approach for managing the backlog effectively.
A) Schedule regular meetings with the scrum team to write, groom, and size user stories
- Why this is not ideal: While regular meetings to groom and size user stories are important, this option overemphasizes the tactical aspect of backlog management. Writing and grooming stories are ongoing tasks, but the Product Owner’s primary responsibility is to ensure the backlog is aligned with business goals and stakeholder needs. Spending too much time on this task could result in missing out on strategic feedback and important priorities from stakeholders.
- Scenario where this might be used: This approach is appropriate when the team is new, and there’s a need to establish a consistent cadence of backlog refinement. However, for high-visibility projects with considerable stakeholder attention, strategic alignment should take precedence over the granularity of individual stories.
B) Focus on stories based on the highest number of story points to first address those items with the highest value
- Why this is not ideal: Focusing solely on the highest number of story points is not an effective way to prioritize backlog items. The value of a feature or user story is not directly tied to its size (or number of story points). Instead, value should be based on business goals, customer needs, and project objectives. Prioritizing based on story points could result in tackling larger, more complex stories that may not deliver the most value to the business.
- Scenario where this might be used: This could be relevant when looking to complete large chunks of work, but it's not an optimal approach for a high-visibility, fast-moving project where delivering the most valuable features as quickly as possible should be the priority.
C) Seek regular input from project stakeholders, and reflect this input in the backlog's pri...
Author: MoonlitPantherX · Last updated May 12, 2026
A team identifies the number of threats and lists them in the order in which they were identified. After analyzing a cause-and effect diagram, the ownership of the threats and their treatment is assigned, and a number of r...
To manage the identified threats effectively, the team needs to ensure that there is a structured and actionable process in place to address the risks, track their progress, and keep everyone aligned. Let's go through each of the options to determine the best approach.
A) Create a risk register detailing the threats, their causes, and their treatment strategies, and complete ownership to provide together risk control and a stakeholder
- Why this is not ideal: While creating a risk register can be a useful tool for documenting and tracking risks, in Agile, especially with Kanban and fast-moving projects, the emphasis is typically on action and visibility over documentation. A risk register might be too heavy-handed for this scenario, as it could distract from ongoing risk management activities. Additionally, risk registers can often become static and aren’t updated as frequently as the project needs them to be, particularly in a dynamic environment like this one.
- Scenario where this might be used: This approach is useful in more traditional project management approaches where risks need to be meticulously documented for stakeholders and long-term tracking. However, it’s less fitting for Agile, where flexibility and continuous improvement are key.
B) Focus on the threats during the daily stand-up and ensure they are visible to the entire team and other interested parties
- Why this is not ideal: While daily stand-ups are important for maintaining communication and visibility in Agile teams, focusing on all the threats during the daily stand-up could lead to excessive detail, slowing down the flow of the meeting. The stand-up is best used for discussing progress, blockers, and immediate issues, not for deep dives into risk management. However, it’s crucial that the risks remain visible to the team and stakeholders to ensure awareness.
- Scenario where this might be used: This could work in cases where a particular threat is critical and needs immediate team-wide attention. However, it’s not the most scalable or sustainable approach for managing risks systematically.
C) Prioritize the risks based...
Author: Vivaan · Last updated May 12, 2026
During product development, changes in technology and regulations require the team to reassess product architect...
Capturing technical debt during product development is critical for maintaining the long-term health of a product and enabling the team to make informed decisions as technology and regulations change. Below is a breakdown of the options, their reasoning, and scenarios where each can be used:
A) Include it in the product backlog and use a new indicator to annotate that it is technical debt
- Reasoning: This is the most suitable approach. Including technical debt in the product backlog allows the team to prioritize and track it, just like any other product-related issue. By using a distinct indicator or label (e.g., “Technical Debt”), the team can easily identify which backlog items are related to maintaining or refactoring code. This approach ensures visibility and prioritization, making it easier for the team to deal with technical debt in future sprints.
- Scenario: This option is ideal when the team is following agile principles and needs to actively manage both feature development and technical debt. It helps ensure that technical debt is acknowledged in the development cycle and doesn't get neglected.
B) Include it in the product backlog as a low-priority issue
- Reasoning: While including technical debt in the backlog is good, classifying it automatically as a low-priority issue is not ideal. Technical debt often has a compounding effect over time and can eventually lead to more significant problems (e.g., slower development, bugs, difficult maintenance). Prioritizing it as low can lead to a situation where it is perpetually deferred, accumulating and becoming harder to resolve later on.
- Scenario: This approach might be used when technical debt is relatively minor and not likely to impede development in the short term, but it should still be addressed regularly to prevent it from growing....
Author: Noah · Last updated May 12, 2026
The agile team disagrees with the business stakeholders on completing some epics.
What could help e...
When there is a disagreement between the agile team and business stakeholders about completing some epics, it’s essential to address the misunderstanding by improving communication and alignment. Let’s look at each option and its reasoning:
A) Agree on requirements with all stakeholders
- Reasoning: This is the most effective approach to eliminating misunderstandings. Having clear, shared, and agreed-upon requirements with all stakeholders ensures that there is a mutual understanding of the project's goals, priorities, and deliverables. It involves both the agile team and the business stakeholders in the decision-making process, ensuring that there is no ambiguity around expectations. Regular collaboration and feedback loops can also help avoid scope creep or misaligned goals.
- Scenario: This approach works best when the misunderstanding arises from a misalignment on requirements or objectives. It’s vital at the start of a project or when significant changes are being made to existing work.
B) Begin planning every four iterations
- Reasoning: While planning regularly is essential in agile methodologies, planning every four iterations (or longer cycles) could create a gap in responsiveness. Agile is built around frequent feedback, and planning over extended cycles may reduce flexibility, making it harder to adjust to changing business priorities or emerging issues. If misunderstandings occur due to a lack of regular communication, this solution may exacerbate the issue by delaying resolutions.
- Scenario: This might be used in cases where teams have worked together for a long time and need less frequent check-ins, but it's generally less effective when there’s ongoing disagreement or misalignment that needs to be resolved immediately.
C) Consider previous sprint demo feedback when planning the next sprint
- Reasoning: This is a good practice in agile, as the demo feedback from stakeholders provides valuable insight into whether the team is meeting expecta...
Author: David · Last updated May 12, 2026
A customer and a product delivery team meet to discuss a product's attributes, goals, expectations, hypothesis, and hi...
When a customer and a product delivery team meet to discuss the product's attributes, goals, expectations, hypothesis, and high-level needs, the goal is to establish a shared understanding that guides development. Let’s analyze each option and identify which one best reflects the benefit of this type of meeting.
A) The team will learn how its contribution will create product value
- Reasoning: This is a significant benefit of the meeting. Understanding how the team's work ties directly into delivering value for the customer helps the team stay motivated, focused, and aligned with the business goals. The meeting provides context on how each feature or component the team develops contributes to achieving the overall product goals, which can lead to better decision-making and higher-quality outputs.
- Scenario: This option is ideal for teams that are looking to understand the bigger picture and the end value of their work. It ensures that every decision the team makes is oriented toward creating value for the customer and aligning with the product’s vision.
B) It will enable team acceptance of client priorities
- Reasoning: While this could be a positive outcome, the meeting is more about gathering information and establishing alignment rather than simply "accepting" client priorities. Acceptance of priorities happens when the team understands and agrees on what the business or customer values most. However, this is not the primary goal of the meeting — the focus should be on understanding the goals, attributes, and needs of the product, and then aligning on priorities after further discussions.
- Scenario: This could apply when the team has conflicting views on priorities and the meeting helps smooth over those differences. However, it is secondary to the more holistic benefit of gaining a shared understanding of the product's objectives.
C) It will enable the team to see the entire project in one glance
-...
Author: Madison · Last updated May 12, 2026
When introducing agile processes to a company, a quality assurance (QA) manager resists and believes that the switch to agile will remove quality controls and...
When introducing agile processes to a company, resistance from stakeholders like a quality assurance (QA) manager is not uncommon, especially if there are concerns about maintaining quality controls and documentation. The key here is to address the manager’s concerns effectively, while demonstrating that agile does not eliminate the importance of quality but rather integrates it into the entire process. Let’s examine each option to determine the best way to address the concern.
A) Educate the QA manager that in agile, quality is integrated from the beginning to end of the project
- Reasoning: This is the most effective approach. Agile practices emphasize continuous quality assurance throughout the development process, not as a separate phase or afterthought. In agile, quality is integrated into every part of the cycle—starting from the planning phase, through development, and during every sprint iteration. Practices such as automated testing, continuous integration, and regular feedback loops ensure that quality is maintained, not removed. Educating the QA manager helps them understand that agile promotes collaboration between developers, testers, and other stakeholders to maintain high-quality standards.
- Scenario: This is the best option when the QA manager is concerned about losing control over quality and documentation. The goal is to reassure them that agile will not eliminate their role but will redefine it to fit into a more collaborative, iterative process.
B) Write backlog items that include QA as part of the description
- Reasoning: While including QA in the backlog items is a good practice in agile, this doesn't directly address the QA manager’s concern about the loss of quality controls and documents. Writing QA-related items in the backlog ensures that testing is considered for each feature, but it may not fully demonstrate how agile integrates quality across the process. It is more of a tactical solution rather than addressing the strategic concern about how agile practices will affect quality management as a whole.
- Scenario: This approach is useful for ensuring QA tasks are visible and actionable but won't address the larger concern of how quality practices are embedded in agile processes overall.
C) ...
Author: Sofia · Last updated May 12, 2026
While struggling to take ownership of delivery, an agile team fails to keep up with its sprint commi...
When an agile team struggles to take ownership of delivery and fails to meet its sprint commitments, the root cause could be a lack of alignment, accountability, or communication. The agile coach must address this concern by focusing on improving team ownership, ensuring clear expectations, and fostering better communication within the team and with stakeholders. Let's analyze each option to determine which is the best course of action.
A) Work with the sponsor to develop team expectations
- Reasoning: This is a proactive and highly effective option. Working with the sponsor to develop clear team expectations can help set a foundation of accountability and ensure that both the team and stakeholders understand the scope, priorities, and goals. By clarifying what is expected from the team, the agile coach can help them set realistic and achievable sprint commitments. Moreover, aligning with the sponsor ensures that the team is working toward shared, agreed-upon outcomes.
- Scenario: This works well when the team lacks clarity about what is expected of them or when there's a disconnect between the business sponsor’s expectations and the team’s ability to deliver. It helps align both sides on a common understanding of priorities and delivery capacity.
B) Provide the customer with a list of deliverables and obtain agreement
- Reasoning: While this may seem helpful, providing a list of deliverables upfront and obtaining agreement doesn’t align with agile principles, which focus on adaptability, flexibility, and ongoing collaboration. In agile, the team commits to deliverables at the start of each sprint, and the emphasis is on delivering value iteratively. Rigidly providing a list of deliverables can create a false sense of certainty and undermine the iterative nature of the process. It may also cause issues when requirements change during the sprint or when unexpected challenges arise.
- Scenario: This could be used in more traditional or waterfall environments, but it's counterproductive in agile, where change is expected, and flexibility is key.
C) Encourage the team to more frequently interact with all stakeholders
- Reason...
Author: Emma · Last updated May 12, 2026
During a team meeting, members who are subject matter experts (SMEs) mention that they are continuously working on repetitive tasks, which ha...
In the scenario where subject matter experts (SMEs) are feeling demotivated due to repetitive tasks, the agile practitioner should focus on addressing the root cause of the demotivation — the repetitive nature of the work and its impact on engagement and motivation. Let's analyze each option:
A) Organize a team-building activity to improve team morale
- Reasoning: Team-building activities can indeed improve morale temporarily, but they don't address the root cause of the problem, which is the repetitive nature of the work. While team-building might provide a short-term boost, it won't solve the issue of repetitive tasks, and SMEs will likely return to the same frustrations.
- Rejection Reasoning: This option might be useful for a general morale boost but will not help alleviate the specific issue of demotivation caused by repetitive tasks.
- Scenario: Useful in situations where the team’s emotional engagement needs a boost, but not effective for addressing specific task-related demotivation.
B) Have team members work in pairs to learn from each other and develop new skills
- Reasoning: This option fosters collaboration and knowledge sharing, which could potentially alleviate some of the monotony by allowing SMEs to learn from each other. However, if the work itself is repetitive, this does not fundamentally solve the problem. The team members may still feel demotivated due to the nature of the tasks.
- Rejection Reasoning: While collaboration can increase learning and might improve motivation to some degree, it doesn't tackle the core issue of repetitive tasks.
- Scenario: Good for fostering collaboration and skill development, but not a long-term solution to demotivation caused by repetition.
C) Ask team members to perform a value stream analysis of their activities
- Reasoning: This option is highly effective in addressing the core issue. By conducting a value stream analysis, the team can identify ...
Author: ElectricLionX · Last updated May 12, 2026
An agile team is working on a new product. To ensure that all unknown issues are clarified before committing to the scope, the team plans to work only on spike user stories fo...
In the scenario where the agile team plans to focus on spike user stories for the next three sprints to clarify unknown issues before committing to the scope, the agile coach’s role is to ensure that the approach is balanced, practical, and conducive to successful delivery while minimizing unnecessary risks or delays. Let's break down each option:
A) Ensure that the spikes identify the risks early in the project to increase the chances of success
- Reasoning: This is a highly sensible approach. By focusing on spikes, the team aims to gather more information and clarify uncertainties, which is valuable in identifying risks early. However, it is important that the spikes actually focus on uncovering the critical unknowns that could impact the project, such as technical feasibility, dependencies, or external factors. The agile coach should ensure that the team isn't just conducting spikes for the sake of clarity but is focused on the issues that are most likely to impact project success.
- Selected Reasoning: This option aligns with the objective of identifying risks and improving the chances of success. Conducting spikes will provide valuable insights that will reduce uncertainty and allow for better-informed decisions, but only if they are properly focused on the highest-priority unknowns.
- Scenario: This approach is best when a project has significant uncertainty, and the team needs to reduce risk by clarifying critical aspects before committing to scope.
B) Ensure that the business sponsor accepts the proposal and agrees to fund the additional spike sprints
- Reasoning: This is a valid consideration because conducting three full sprints of spikes will likely require additional resources and funding, and the business sponsor needs to approve the decision. However, this step doesn’t directly help with how the team should proceed in the immediate term. If the business sponsor doesn't agree, the team may need to adjust the plan. While this is important for alignment, it’s a logistical and strategic issue that’s more about securing buy-in rather than addressing the immediate action the coach should take.
- Rejection Reasoning: While this is important to secure alignment with stakeholders, it doesn’t address the quality or focus of the spikes, which is the more urgent matter in this context.
- Scenario: Relevant when there are funding constraints or when the sponsor is hesitant to allocate resources for non-delivery tasks, but not immediately applicable to the coach’s guidance on how to execute the work.
...
Author: Victoria · Last updated May 12, 2026
How can an agile team working on a new product ensure alignment with external stakeholders?
Ensuring alignment between the agile team and external stakeholders is crucial for a successful product development process. In an agile environment, alignment should be achieved through continuous collaboration, clear communication, and flexibility rather than relying on rigid documentation or one-time events. Let's examine each option:
A) Ask the product owner to provide a detailed product specification document
- Reasoning: While having clear product specifications can be useful, asking the product owner to provide a detailed product specification document goes against agile principles, which prioritize working software over comprehensive documentation. In agile, detailed documents can quickly become outdated, and the emphasis should be on iterative, ongoing collaboration instead of relying on a single point of truth document.
- Rejection Reasoning: This approach might seem like a way to align on the product, but it is counterproductive in agile, where adaptability and flexibility are key. Detailed documentation often becomes cumbersome and less useful in a fast-changing development environment.
- Scenario: This option might be used in traditional project management approaches where documentation is the primary mode of communication, but not in agile.
B) Conduct story-mapping exercises to clarify deliverables and release priorities
- Reasoning: Story-mapping exercises are a highly effective way to ensure alignment between the agile team and external stakeholders. This technique allows both the development team and stakeholders to visualize the entire product journey, identify high-value features, and prioritize deliverables. By creating a shared understanding of what needs to be delivered, stakeholders can directly influence priorities, and the team can ensure that they're focused on what matters most. Story mapping also helps clarify the flow of work and sets clear expectations for what will be delivered in each release.
- Selected Reasoning: This option directly addresses the need for alignment through collaborative prioritization, ensuring that both the team and external stakeholders share a clear vision of the product. It's iterative, adaptable, and provides a real-time view of progress, making it ideal for ensuring alignment throughout the development process.
- Scenario: This approach is perfect when working with external stakeholders who need to stay informed of release priorities and help s...
Author: Noah · Last updated May 12, 2026
What can an agile team use to prioritize stories?
When an agile team needs to prioritize user stories, they should use a technique that allows them to balance value, risk, and effort to ensure the most important features are delivered first. Let's examine each option and its suitability for prioritization:
A) Planning poker technique
- Reasoning: The Planning Poker technique is used primarily for estimating effort or complexity of user stories. Team members discuss and then assign story points or time estimates using a deck of cards with values. It is an excellent tool for estimating work but not for prioritization. It helps the team understand how long something might take, but it doesn’t inherently prioritize which features or stories should be tackled first based on business value or urgency.
- Rejection Reasoning: While valuable for estimation, Planning Poker does not help prioritize the stories based on business goals, risk, or value. It’s a tool for understanding effort, not prioritization.
- Scenario: This technique is useful when teams need to estimate how much effort is required to complete a user story but is not a prioritization tool.
B) Weighted average calculation
- Reasoning: The Weighted Average Calculation technique can be used for prioritization if you assign weights to different factors like business value, effort, risk, and urgency. This method helps quantify the value of each story by considering these different parameters. While this can work in some cases, it’s often more complex than other prioritization techniques and may require a lot of upfront analysis to assign appropriate weights. It can be a bit too rigid for fast-moving agile teams who need to adapt quickly.
- Rejection Reasoning: The Weighted Average Calculation could be an over-complicated and less flexible method for day-to-day agile prioritization. It also requires detailed input and may not be as simple or visual as other options.
- Scenario: This might be useful in large-scale projects where many factors need to be considered, but is less suited for fast, iterative prioritization in smaller agile teams.
C) Risk-value quadrant
- Reasoning: The Risk-Value Quadrant is a great method for prioritization, where stories are plotted on a 2x2 grid based on their ...
Author: RadiantJaguar56 · Last updated May 12, 2026
During a daily stand up, the tester engages the developer in a discussion about what will be tested during unit testing versu...
In this situation, the tester and developer are engaging in a technical discussion during the daily stand-up, which is meant to be a quick synchronization meeting to update the team on progress, plans, and blockers. It's important that the scrum master facilitates effective communication while ensuring that the daily stand-up remains focused on its primary purpose. Let's analyze each option:
A) Ask the tester and developer to discuss it after the meeting, since it is not a part of the daily stand-up
- Reasoning: The daily stand-up is designed to be brief and focused on progress, plans, and blockers. A detailed discussion on unit testing versus regression testing is not part of the daily stand-up agenda. The scrum master should redirect the conversation to ensure the meeting stays on track.
- Selected Reasoning: This option maintains the focus of the daily stand-up and ensures that the team doesn't spend too much time on technical details that can be handled later. The scrum master should gently guide the team to hold discussions after the meeting to avoid derailing the stand-up.
- Scenario: This approach works well when a team is discussing technical details or problem-solving during the stand-up, which is not the purpose of the meeting.
B) Encourage the discussion to resolve impediments
- Reasoning: The scrum master should encourage team members to address impediments quickly, but the issue of testing types (unit vs. regression) doesn't necessarily qualify as an immediate impediment. If the discussion is not blocking progress or causing delays, it doesn't need to happen in the stand-up.
- Rejection Reasoning: While it's important to address impediments, in this case, the discussion seems to be technical in nature rather than resolving an immediate obstacle. Encouraging the discussion during the stand-up could cause it to become too long and detract from the purpose of the meeting.
- Scenario: This option is useful when an actual blocker or issue needs to be resolved urgently during the stand-up, but not for routine technical discussions.
C) After the meeting, escalate this issue to the tester's superviso...
Author: SilverBear · Last updated May 12, 2026
A team is delivering work as per the sprint plan, and team velocity is stabilized. However, at the end of the release, the customer is dissatisfied with project qu...
In this situation, the primary issue is customer dissatisfaction with the project's quality at the end of the release, despite the team's velocity being stabilized and work being delivered according to the sprint plan. To prevent such issues, it is critical that quality is continuously monitored and refined, and that the customer is engaged throughout the development process to ensure their expectations are being met.
Let's evaluate each option:
A) Invited end customers to attend the stand-ups
- Reasoning: Inviting customers to daily stand-ups could have provided transparency in the development process. However, stand-ups are usually meant for the internal team to discuss progress, impediments, and coordination. Customers might not need to be involved in this daily, technical level of detail. Their engagement in stand-ups might also lead to confusion, as they would likely not be concerned with specific sprint activities or blockers, which could distract from the team’s focus on technical tasks.
- Rejected: Although it could enhance communication, this doesn't directly address quality or continuous customer feedback, which would have been a more effective focus. Also, involving customers in this way may not align with agile best practices for keeping the stand-up focused.
B) Organized design review sessions with the customer to obtain sign-off
- Reasoning: Organizing design reviews is a good practice, but it's usually a one-time activity during the early stages of a project. Requiring sign-off from the customer on a design early on might set expectations, but it doesn't guarantee that feedback loops are continuous or that the customer's evolving needs will be addressed throughout the project. The final product might diverge from what the customer truly wants or needs if ongoing collaboration is lacking.
- Rejected: While important, relying solely on one-time design reviews does not address the ongoing quality assessment or the need for...
Author: Ella · Last updated May 12, 2026
A company president is concerned about the impact of a natural disaster on the company.
How should management identify areas...
In this scenario, the company president is concerned about the impact of a natural disaster, and the key goal is to ensure that the company can mitigate the risks and apply resources effectively to minimize any potential damage. To address this, management must identify critical areas, prioritize potential impacts, and establish practical mitigation strategies. Let's analyze each option:
A) Establish and keep an active risk register that includes mitigation strategies and a cost-benefit analysis
- Reasoning: This is a comprehensive approach. A risk register is a core tool in risk management, allowing the company to identify, assess, and track potential risks. Including mitigation strategies ensures proactive measures are in place, and adding cost-benefit analysis enables decision-makers to prioritize resources effectively based on the potential impact and the cost of mitigation. This option considers the financial feasibility of each mitigation measure and ensures that resources are allocated where they will have the most significant effect.
- Selected: This approach is the most effective for identifying and addressing potential impacts. It balances proactive risk identification with a strategic approach to allocating resources based on both severity and cost-effectiveness.
B) Establish and keep an active risk register based on qualitative risk analysis and expected losses
- Reasoning: A qualitative risk analysis assesses the probability and impact of risks using subjective criteria (like high/medium/low), while expected losses provide insight into the financial consequences of a risk event. While this method is valuable for understanding risks and prioritizing them, it lacks the additional layer of cost-benefit analysis found in Option A. Without a cost-benefit analysis, the company might miss opportunities to apply resourc...
Author: Lucas · Last updated May 12, 2026
An event management team is following an agile approach to prepare for an upcoming conference. The regional sales manager, from where the conference is to be held, contacts the team ...
In this scenario, the event management team is working in an agile environment to prepare for a conference. The regional sales manager has contacted the team with a number of questions regarding the company's booth. The team must respond appropriately while balancing agile principles of flexibility, collaboration, and focus on iteration goals.
Let’s evaluate each option:
A) Inform the sponsor about the regional sales manager's disruptiveness and ask that all questions be diverted to the weekly meetings
- Reasoning: This option positions the regional sales manager as a disruptor and suggests pushing all communication through formal meetings. While it may sound like a way to maintain structure, it could undermine collaboration and transparency. In an agile environment, collaboration and flexibility are key, and completely restricting communication to formal meetings might hinder timely feedback or cause unnecessary delays.
- Rejected: This approach lacks the spirit of agility, which emphasizes direct communication and addressing concerns promptly. It could create a sense of barriers or siloed communication between different stakeholders, which is counterproductive in an agile setting.
B) Stay focused on the current iteration and let the project manager deal with the regional sales manager's questions
- Reasoning: Staying focused on the iteration’s goals is crucial in agile, but the issue here is that the regional sales manager’s questions could indicate emerging requirements or issues that may affect the booth’s setup or the conference's success. Simply deflecting these questions to the project manager could create a communication bottleneck, delay decision-making, and cause important details to be overlooked.
- Rejected: While staying focused on the current iteration is important, this option doesn’t address the potential need for quick collaboration a...
Author: Matthew · Last updated May 12, 2026
What should a team consider when calculating the effort needed to complete a product backlog?
When calculating the effort needed to complete a product backlog, the team needs to carefully consider various factors to ensure accurate planning and forecasting. Agile teams generally estimate effort in terms of story points, complexity, and uncertainty, which help determine the workload required for a backlog. Let’s evaluate each option:
A) The increase in velocity and cost
- Reasoning: Velocity is a key factor in determining how much work a team can complete in a sprint. It reflects the average amount of story points completed per sprint, which helps in forecasting how long it will take to complete a backlog. However, velocity is a historical metric, and its increase does not necessarily correlate directly with calculating the effort required for the current backlog. Cost, while important for budget management, is not directly tied to calculating effort in terms of story points or complexity.
- Rejected: While velocity is useful in forecasting future sprints, focusing solely on increased velocity and cost doesn't fully capture the necessary considerations for calculating the total effort. Velocity needs to be stable and should be based on past sprints, not on expected increases. Therefore, this option doesn’t address the actual effort calculation comprehensively.
B) A buffer in the sprint to mitigate unexpected risks
- Reasoning: Including a buffer in the sprint is a good practice in agile for mitigating uncertainties or risks. Agile teams often deal with changing requirements, unexpected issues, or unknowns. However, buffers are typically used for managing risks in a sprint rather than directly estimating the effort needed for the backlog. The effort calculation should focus on the complexity of the tasks themselves, and the buffer is more of a contingency factor to account for uncertainties rather than an essential component of effort estimation.
- Rejected: While the buffer is useful in sprint planning, it doesn’t directly help in estimating the effort required for completing the entire product backlog. Th...
Author: Krishna · Last updated May 12, 2026
Two teams have received project requirements and completed estimates. Team A estimates 420 story points for scope and 30 story points for velocity per sprint.
Team B estimates 280 story points for scope and 20 story points for velocity per sprint. Both teams have same number of team member...
When analyzing the estimates of Team A and Team B, we need to look at their scope estimates and velocity to draw conclusions about their respective approaches to completing the project. Let's break down each option to determine what can be concluded.
A) Team B has underestimated scope compared to Team A
- Reasoning: Team A has estimated 420 story points for scope, while Team B has estimated 280 story points. Based on this information alone, Team B’s scope estimate is lower than Team A's, but this doesn't necessarily mean that Team B has underestimated the scope. Team B might have different assumptions, methods, or perspectives on how to break down and scope the project. It's also possible that the teams are estimating in different ways, or that Team B has different priorities or clarity on scope.
- Rejected: We cannot definitively conclude that Team B has underestimated the scope simply because their scope estimate is lower. It's possible that both teams are estimating the same project size, but simply using different methods or assumptions in their estimates.
B) Team A is more confident in delivering velocity than Team B
- Reasoning: Team A estimates 30 story points per sprint for velocity, while Team B estimates 20 story points per sprint. The difference in velocity estimates could indicate that Team A feels confident in delivering a higher volume of work per sprint compared to Team B. However, confidence might not be the sole factor—Team A may have a higher velocity due to differences in team capacity, experience, or maturity. It’s possible that Team B's velocity is more conservative due to potential risks or the nature of their tasks.
- Selected: This option makes sense because Team A's velocity is higher, which can be interpreted as them being more confident in completing more work per spri...
Author: Ming88 · Last updated May 12, 2026
Throughout the project, an agile practitioner notices that one team member is becoming an emergent le...
In an Agile environment, team dynamics and collaboration are vital for success, so it’s essential for an Agile practitioner to handle an emergent leader situation with care and foresight. Let’s evaluate the options in this context:
A) Present opportunities in order to be supportive and grow that team member's talents
- Reasoning: Agile values collaboration and self-organizing teams. If a team member is showing leadership qualities, the Agile practitioner should support and encourage their development, not suppress it. This option aligns with the Agile principle of fostering growth and self-improvement within the team. By giving the emerging leader more responsibility or visibility, the practitioner helps them continue to develop and share their leadership skills while still supporting the team’s overall goals.
- When it works best: This is most suitable in an environment where growth is encouraged and where new leadership can help build team cohesion, drive initiatives, or guide other members without disrupting the team balance.
B) Encourage the team member to fit in more with the established team norms
- Reasoning: While it’s important for the team to have a sense of cohesion, discouraging an emergent leader or trying to force them to "fit in" can hinder natural leadership development. In Agile, team roles are fluid and adaptable. An emergent leader may actually be helping push the team toward better processes or higher performance. This option seems more like an attempt to suppress growth rather than nurture it.
- When it works best: This would apply only if the emergent leader is exhibiting behavior that disrupts the team, such as dominating conversations or disregarding others. However, this approach should be handled delicately to avoid stifling positive leadership potential.
C) Bring this to management's attention so they don't disrupt the team
- Reasoning: While it’s important to monitor team dyn...
Author: Aria · Last updated May 12, 2026
A product's scope and acceptance criteria have been detailed, and the product is planned for release at the end of the ...
When planning for the release of a product at the end of the next quarter, the project team should focus on breaking down and planning how the work will be executed incrementally. Let’s evaluate the available options:
A) Estimate the project team's capacity
- Reasoning: While understanding the team’s capacity is an important step in resource planning, it comes after clarifying what work needs to be done. Estimating the team's capacity is more relevant after the team has a clear understanding of the scope, and how many resources they can allocate to each task. This step is necessary, but it’s premature at this stage.
- When it works best: This option is useful in early stages when planning long-term sprints or iterations. It helps in defining the overall team availability, but it's not the first step once the scope and acceptance criteria are defined.
B) Determine how much work can be delivered
- Reasoning: This is a logical next step after understanding the product scope and acceptance criteria. By determining how much work can be delivered, the team can assess their ability to meet the release deadline. This includes identifying what can be done in each iteration, which is vital for planning incremental deliveries. It is a planning task where the team defines achievable objectives based on the defined scope.
- When it works best: This works well once the team has a clear understanding of the project’s scope and its priorities. It helps set realistic expectations for stakeholders and guides the breakdown of work into manageable iterations.
C) Calculate how much work will fit into the next iteration
- Reasoning: This o...
Author: Rahul · Last updated May 12, 2026
At the retrospective, the burndown chart shows that the project is slightly behind schedule. The project team identifies an inexperienced software engineer as the sour...
When the project team identifies an inexperienced software engineer as the source of reduced velocity, the focus should be on helping the team member improve and supporting them to contribute more effectively, rather than re-prioritizing tasks or changing estimates in ways that may not address the root cause. Let's evaluate the options:
A) Suggest pair programming during the retrospective
- Reasoning: Pair programming is an excellent way to help less experienced engineers quickly improve their skills. By pairing the inexperienced engineer with a more experienced team member, they can learn best practices, gain insights into the codebase, and improve their overall productivity. This option directly addresses the issue of reduced velocity by improving the skills of the engineer while also maintaining team collaboration.
- When it works best: This is an effective approach when the team wants to help the less experienced member grow while also ensuring that the work continues at an acceptable pace. Pair programming is also in line with Agile's emphasis on collaboration and knowledge sharing.
B) Ask the product owner to re-prioritize the user stories at the next retrospective
- Reasoning: While re-prioritizing user stories could help manage the workload, it does not directly address the issue of the inexperienced software engineer. Re-prioritizing could shift the team's focus to easier tasks, but this will likely only delay addressing the root cause of the reduced velocity (the engineer’s inexperience). It might not lead to long-term improvement or growth for the engineer.
- When it works best: Re-prioritizing user stories may be useful if the team is facing an external pressure to meet deadlines or if the current tasks are too complex for the team's capabilities. However, in this scenario, it's a less effective long-term solution compared to helping the engineer develop their skills.
C) Re-estimate the sto...
Author: Ravi Patel · Last updated May 12, 2026
How should a project leader manage stakeholder expectations in an agile project?
Managing stakeholder expectations is crucial in an Agile project to ensure alignment, maintain trust, and keep the project moving toward a successful outcome. Let’s evaluate each of the options based on key factors like collaboration, transparency, and realistic expectations.
A) Establish a common vision and success criteria and involve all the stakeholders in the iteration reviews
- Reasoning: This is the most effective approach. Agile emphasizes collaboration, transparency, and continuous feedback. By establishing a common vision and clear success criteria from the start, the project leader ensures that stakeholders share a mutual understanding of what success looks like. Regular involvement in iteration reviews keeps stakeholders aligned with the project’s progress and allows them to provide timely feedback. This also helps in managing expectations by providing stakeholders with a clear view of what is being delivered, and it allows the team to adjust expectations if necessary.
- When it works best: This approach is ideal for projects with multiple stakeholders and when a shared understanding of success is critical. It ensures ongoing engagement, transparency, and alignment, making it easier to manage expectations over time.
B) Invite stakeholders for the iteration reviews but do not include new stakeholders which may limit project success
- Reasoning: While it’s important to have a stable group of stakeholders, this approach could be overly restrictive. If new stakeholders need to be involved (e.g., executives, end users, or new department representatives), excluding them could limit the project’s ability to meet broader expectations or respond to changing needs. It’s more beneficial to be inclusive of all relevant stakeholders as the project progresses, ensuring that their expectations are understood and incorporated.
- When it works best: This approach is suitable if the project has already undergone significant scope changes or the original stakeholder group is well-defined and stable. However, it’s generally more beneficial to maintain flexibility and involve all stakeholders as needed.
C) Involve all the stakeholders in iteration reviews but do not entertain all expectations of all stakeholders
- Reasoning: W...
Author: FlamePhoenix2025 · Last updated May 12, 2026
A scrum master would like to provide information to key stakeholders on the daily resource and project activities.
Which too...
The Scrum Master is responsible for facilitating communication and ensuring that stakeholders have clear visibility into project progress and activities. In this context, the goal is to provide information to stakeholders about daily resource and project activities, which includes progress tracking and resource utilization. Let’s evaluate the options:
A) Shared vision statement and sprint goal
- Reasoning: While a shared vision statement and sprint goal are fundamental to setting direction and providing high-level focus, they are not suitable tools for providing ongoing updates on daily resource and project activities. These tools are more about aligning the team and stakeholders at the start of a project or sprint, rather than offering continuous updates.
- When it works best: This is useful at the beginning of a project or sprint to ensure alignment, but it does not provide daily or ongoing insights into specific resource usage or progress.
B) Release burnup chart
- Reasoning: A release burnup chart tracks the amount of work completed over time and shows how much work remains to meet the release goal. It is particularly useful for understanding progress toward the overall release milestone, which can be useful for stakeholders to see how the project is advancing. However, it is not specifically focused on daily resource activities, and it doesn’t provide granular information on day-to-day activities or resource allocation.
- When it works best: This chart is helpful when discussing long-term progress and release goals, especially when the focus is on tracking the completion of the overall product or release. It is not as effective for providing detailed daily updates on resource or project activity.
C) Velocity metrics
- Reasoning: Velocity metrics are useful for u...
Author: Oliver · Last updated May 12, 2026
After a successful product deployment, a key stakeholder informs an agile team member that an implemented feature is failing to deliver its expected business value. The team member replies that the requirement was provided by the customer, and that the scope was clearly met.
If the ...
In an agile environment, ensuring that requirements are accurately understood and meet the business value expected by stakeholders is crucial. If the problem lies in requirement elicitation rather than delivery, the team should have focused on methods that ensure continuous feedback and alignment with the stakeholders' needs. Here's an analysis of each option:
Option A: Stakeholders should have regularly been engaged to obtain feedback and reduce the functionality risk
- Why this is relevant: Regular engagement with stakeholders ensures that the team is not building features in isolation. Frequent feedback helps to confirm whether the feature aligns with the expected business value, allowing for early adjustments before significant issues arise. Agile emphasizes iterative development, where customer feedback is gathered continuously. If this step was skipped, the feature might have been developed based on incorrect assumptions or misunderstood expectations.
- Why other options are rejected:
- Option B (delaying for facts) is useful for assumptions, but it doesn’t directly focus on obtaining timely feedback. Stakeholder engagement is still critical for confirming assumptions early.
- Option C (interdependent teams) is valuable in complex projects, but it does not directly address the core issue of aligning with stakeholder needs. Engaging stakeholders directly is more crucial in this case.
- Option D (identifying an owner) is good for accountability but doesn't address the need for ongoing feedback from stakeholders.
Option B: The team should have used the lean principle of delay, so that actual facts could be considered rather than assumptions and predictions
- Why this is relevant: The lean principle of "delay" emphasizes waiting to make decisions until there is enough information. While this can reduce risk by avoiding premature commitments, it is less practical for avoiding requirement misalignment. Waiting for more facts might delay the feature delivery or create a lack of clarity on requirements, which could still result in misalignment wit...
Author: CrystalWolfX · Last updated May 12, 2026
During a project's last few sprints, an agile practitioner notices an increase in defects. A rootcause analysis indicates that a poor understanding of the requirements was caused by the inability ...
In this scenario, the issue is that the product owner is unable to clearly communicate the requirements, leading to an increase in defects. The agile practitioner needs to address this communication gap in a way that promotes collaboration and improvement, while maintaining respect for the roles and responsibilities of all parties involved. Here's an analysis of each option:
Option A: Inform the product owner's manager so that corrective action may be taken
- Why this is not ideal: While escalating the issue to the product owner’s manager may seem like a way to resolve the problem, it is not the most constructive approach in an agile environment. Agile principles emphasize collaboration and direct communication within the team. Going over the product owner's head can lead to a breakdown in trust and collaboration, and it may cause the product owner to feel undermined rather than supported.
- Why other options are better: The issue lies in the product owner's ability to communicate, and addressing this directly through collaboration or coaching would be more effective in fostering long-term improvement.
Option B: Communicate this to the product owner, and offer to help facilitate discussion with the team
- Why this is ideal: This option addresses the root cause directly by fostering communication between the practitioner and the product owner. The agile practitioner can offer support in improving communication methods and facilitate discussions with the team. This approach encourages collaboration, respect, and a constructive improvement process, which aligns with agile values. Helping the product owner improve their communication skills is more likely to result in sustained change and better outcomes for the team.
- Why other options are rejected:
- Option A involves an indirect approach through escalation, which could harm team morale and trust.
- Option C is reactive, relying on a team member to bring it up during a retrospective, which might delay addressing the issue o...
Author: Michael · Last updated May 12, 2026
An agile team lead is assigned to a project that must ensure data security.
What should the team lead do to guarantee that security, as a ...
In an agile project, ensuring data security as a non-functional requirement requires that it is not treated as a one-off task but as an ongoing, integrated aspect of the project. Here’s an analysis of each option:
Option A: Include security concerns on the agenda for every meeting
- Why this is relevant: This option emphasizes making security an ongoing conversation throughout the project. Regularly discussing security in meetings keeps it on the radar and ensures that the team continuously considers it in every phase of development. While it fosters awareness, simply adding security to the meeting agenda doesn’t directly integrate security practices into the development process or ensure it is acted upon appropriately. It risks becoming a checkbox rather than a structured approach to managing security concerns.
- Why other options are better: While valuable for keeping security top-of-mind, it does not provide enough structure for actively managing and addressing security requirements.
Option B: Request that a security expert be added to the team
- Why this is relevant: Including a security expert can bring specialized knowledge and ensure that security requirements are correctly interpreted and implemented. However, this is not the most comprehensive solution for managing security as a non-functional requirement because:
- It may create dependency on a single expert rather than embedding security into the broader team’s processes.
- It doesn’t ensure that security is considered early and continuously during the planning and development phases.
- Why other options are better: Option D (planning and prioritizing security) ensures that security is integrated into the planning process and that it is prioritized alongside other requirements, providing a more holistic and sustainable approach.
Option C: Add security as a non-functional requirement to the risk register, and review regularly
- Why this is relevant: Adding security to the risk register is a proactive approach that acknowledges its importance in the project's overall ...
Author: Emma Brown · Last updated May 12, 2026
During a backlog refinement meeting, a senior team member raises a concern about an epic sizing that requires the use of a new interface for a vendor product.
The product...
When a new risk arises during backlog refinement, such as the uncertainty around using a new interface for a vendor product, the product owner needs to take action to better understand and mitigate that risk so the team can continue working with the necessary information. Here's an analysis of each option:
Option A: Log the risk in the risk register, and share the information with impacted stakeholders at the next monthly review meeting
- Why this is not ideal: While logging the risk in the risk register is useful for tracking, waiting until the next monthly review meeting to share the information with stakeholders could delay decision-making. The risk needs to be addressed immediately so that the team can move forward with enough knowledge to estimate the epic or handle the interface uncertainty. Waiting for a monthly review may not provide the necessary agility for resolving this risk within the iteration.
- Why other options are better: This is a more passive approach to managing risk. The situation requires a more proactive, immediate resolution to clarify the uncertainty.
Option B: Create a spike story to determine what needs to be done to use the new interface
- Why this is ideal: A spike story is specifically used to research or explore uncertainties or unknowns—like this new interface—before committing to full implementation. It allows the team to explore the new interface, clarify what needs to be done, and reduce risk by providing clarity and knowledge. This approach fits perfectly with agile principles, which emphasize continuous learning and managing uncertainty incrementally. Once the spike is completed, the team can adjust their estimations and approach based on the findings, ensuring that the epic can be completed successfully with the required knowledge.
- Why other options are rejected:
- Option A (logging in the risk register) doesn't provide an immediate, actionable solution to address the uncertainty.
- Option C (lowering the epic's priority) defers the problem and doesn't tackle the issue. By doing this, the team might encounter the same uncertainty later, and the risk ...
Author: Ravi Patel · Last updated May 12, 2026
A project sponsor is upset that an enhancement will be unavailable until next year.
What should the...
When a project sponsor expresses dissatisfaction with a delay, the product owner needs to manage expectations while ensuring that the right priorities are set in the backlog. Here’s an analysis of each option:
Option A: Accept responsibility for the product's delay
- Why this is not ideal: While taking responsibility is a good practice for accountability, this option doesn't address the underlying issue, which is likely a misalignment of priorities between the sponsor and the product team. Simply accepting responsibility doesn’t resolve the situation or offer a constructive solution. The product owner should instead focus on aligning priorities and managing expectations.
- Why other options are better: The product owner’s role is to manage the backlog and ensure that the right work is prioritized. Accepting blame without offering a solution doesn’t contribute to solving the problem or improving the situation.
Option B: Ensure that the project sponsor's priorities are in the product backlog
- Why this is ideal: This option allows the product owner to align the project sponsor's expectations with the team's work. By ensuring that the sponsor’s priorities are reflected in the product backlog, the product owner can make sure the sponsor understands how the work is being prioritized and when the requested enhancements will realistically be delivered. This provides visibility and transparency, allowing for better expectation management and potential trade-offs or compromises. It also emphasizes the importance of maintaining a collaborative relationship with the sponsor.
- Why other options are rejected:
- Option A (accepting responsibility) doesn’t address the need to clarify priorities and manage expectations.
- Option C (negotiating for more funding) may be necessary in some cases but doesn’t directly address the issue of timing and priorities.
- Option D (empowering the sponsor to manage the backlog) isn’t ideal because it undermines the product ow...
Author: Layla · Last updated May 12, 2026
An agile practitioner notices that team members are disengaged. As a result, the team's velocity has decreased.
What should t...
In this scenario, the agile practitioner faces a disengaged team, which is leading to a decrease in velocity. To resolve this, it is important to identify the root causes of disengagement and take actions that address them effectively.
Analyzing Each Option:
A) Escalate the issue to the project sponsor
- Reason for rejection: While escalation to the sponsor may be necessary in some cases (e.g., resource issues or major organizational roadblocks), it does not directly address the root cause of disengagement within the team. The issue appears to be internal, related to team dynamics, and engagement, so addressing it at the team level would be more effective than escalating to the sponsor.
- When to use this option: If there are organizational or resource issues affecting the team’s performance, this could be a valid course of action, but not for disengagement within the team itself.
B) Remove stories to increase velocity
- Reason for rejection: Reducing the scope or removing stories could give a temporary boost to velocity, but it does not solve the underlying problem of disengagement. Velocity is not just a measure of completed work; it reflects the team's engagement, morale, and productivity. Focusing solely on increasing velocity without addressing the team’s engagement will likely lead to further problems down the road, such as lower morale and increased frustration.
- When to use this option: This might be a short-term strategy if the team is overwhelmed and needs to focus on fewer tasks. However, it doesn’t address the deeper issue of disengagement.
C) Hold a standup to address the issue
- Reason for rejection: While a standup is a regular ceremony meant to improve commu...
Author: CrimsonViperX · Last updated May 12, 2026
During sprint retrospectives, some team members are very vocal and tend to dominate the conversation, while others are more reserved and l...
When certain team members dominate the conversation in sprint retrospectives and others remain reserved or disengaged, it's important for the Scrum Master to create an inclusive environment that encourages balanced participation from everyone. Let's analyze each option and consider which one best addresses this issue:
Analyzing Each Option:
A) Encourage all team members to participate, and have them type their retrospective feedback into the agile lifecycle management tool
- Reason for rejection: While encouraging participation is good, asking team members to input feedback into an agile lifecycle management tool might not immediately resolve the issue of unequal participation in the retrospective itself. It may also make the process more transactional rather than interactive. The tool is a way to capture feedback, but it doesn't foster open communication or collaborative problem-solving in real-time during the retrospective.
- When to use this option: This could be useful if feedback collection needs to be formalized or documented, but it doesn’t tackle the issue of vocal members dominating the discussion.
B) Ask more specific questions during the retrospectives
- Reason for rejection: Asking specific questions can certainly help guide the conversation and keep the retrospective focused. However, this doesn’t directly address the issue of participation inequality. If the retrospective is still dominated by a few vocal members, specific questions alone may not encourage the more reserved team members to speak up.
- When to use this option: This could be useful as a part of the broader approach but alone might not resolve the problem of unequal participation.
C) Use retrospective techniques, such as silent writing, clustering, and dot voting to field feedback prior to discussion by the team
- Reason for selection: This option is ideal because it provides structured techniques to ensure all te...
Author: Alexander · Last updated May 12, 2026
An agile team provides feedback that user stories include insufficient details to understand the requirem...
In this scenario, the agile team is providing feedback that user stories lack sufficient details to understand the requirements. This feedback suggests there’s a gap in the way user stories are being written or understood. Let's analyze each option to determine the most effective course of action.
Analyzing Each Option:
A) Coach the product owner to update only the acceptance criteria
- Reason for rejection: While the acceptance criteria are crucial, focusing solely on them may not address the root issue of insufficient details in the user stories as a whole. The lack of clarity could be broader, affecting the entire user story—such as unclear goals, insufficient context, or lack of necessary information. Simply updating acceptance criteria might not solve the overall problem if other aspects of the user stories (like description, context, or assumptions) are unclear.
- When to use this option: If the issue is solely about unclear acceptance criteria (which is a part of the user story), this could be helpful. However, it doesn't fully resolve broader issues with story clarity.
B) Instruct the agile team to fix the user stories during the next retrospective
- Reason for rejection: A retrospective is a valuable meeting to discuss process improvements, but it’s not an effective place to directly fix the user stories. The retrospective should focus on team improvement and reflections on how to work better, not necessarily on detailed item fixes. Having the team "fix" user stories during this meeting could derail the retrospective’s focus and also delay the resolution of the immediate issue.
- When to use this option: If the team wants to reflect on why the stories are being written this way or to discuss the root cause of unclear user stories, it could be mentioned in the retrospective, but it shouldn’t be where the fixing happens.
C) Facilitate a user story workshop with the agile team
- Reason for selection: A user story workshop is the most direct and effective w...
Author: StarryEagle42 · Last updated May 12, 2026
Following an upgrade, a software support team is overwhelmed by the number of tickets being submitted by end users. The team's manager is pushing the team to `work smart` by focusing on activitie...
When a software support team is overwhelmed with a large number of tickets following an upgrade, the key challenge is managing resources and prioritizing work effectively to minimize time and effort while maximizing value. Let's break down each of the options to find the most appropriate solution.
Analyzing Each Option:
A) Work longer hours to complete more of the support backlog
- Reason for rejection: While working longer hours may seem like a quick way to address the backlog, it is a temporary and unsustainable solution. Extended hours can lead to burnout, decreased productivity over time, and lower morale. Furthermore, simply working more hours doesn't necessarily address the root cause of the backlog or improve the quality of the support process. It doesn't align with working smarter, as it focuses on effort rather than efficiency or value.
- When to use this option: This could be considered a last resort in cases of acute urgency, but it shouldn't be the first choice for addressing a systemic problem.
B) Work support tickets in the order in which they were received
- Reason for rejection: While working tickets in the order they are received is fair in a traditional support setup, it doesn't prioritize based on the importance or impact of the tickets. Some tickets may be critical (e.g., affecting many users or core functionality), while others may be minor or isolated issues. This approach ignores the principle of working smart by focusing on the highest-value activities first.
- When to use this option: This approach may be suitable for small, low-impact environments with equal urgency across all tickets. However, in a high-priority support context, it doesn't optimize for value.
C) Place tickets on hold until the team completes an analysis of the backlog to identify and resolve systematic issues
- Reason for selection: This option focuses on addressing the root cause of the problem by analyzing the backlog and identifying recurring issues or patterns. By resolving systematic issues, the team...
Author: ShadowWolf101 · Last updated May 12, 2026
What should the agile practitioner know about tracking velocity?
When tracking velocity in an Agile environment, it's important to understand that velocity is a measure of how much work a team is completing during a sprint. However, this metric alone does not provide a direct measure of efficiency or performance in the way one might think. Let’s break down the options to identify which one best reflects the reality of tracking velocity.
Analyzing Each Option:
A) A team with an average velocity of 50 is twice as efficient as a team with an average velocity of 25
- Reason for rejection: This option incorrectly assumes that velocity directly equates to efficiency. Velocity measures the amount of work completed in a given sprint (usually in story points), but it doesn't tell you how "efficient" a team is. A team with a velocity of 50 may be doing more work, but this does not mean they are working "twice as efficiently" as a team with a velocity of 25. Efficiency can be impacted by factors like quality of work, collaboration, and team cohesion, none of which are captured by velocity alone.
- When to use this option: This option is generally not applicable because velocity alone does not indicate efficiency in the way it is presented here.
B) A team with an average velocity of 50 is equally as efficient as a team with an average velocity of 25
- Reason for rejection: This option also misses the mark. It suggests that velocity alone, without understanding context or work quality, is a reliable indicator of efficiency. While a team with a higher velocity might be completing more work, that does not mean they are just as efficient if they are overworking or burning out, or if the lower-velocity team is focusing on higher-quality work. Efficiency is not only about completing tasks, but about doing so effectively and sustainably.
- When to use this option: This approach would be used in a very narrow context where all other factors (such as complexity and quality of work) are equal, but in most practical scenarios, it's an oversimplification.
C) A team that consistently meets its planned velocity is more efficient than a team that consistently exceeds its planned velocity
- Reason for rejection: While consistency in meeting planned velocity can indicate that a...
Author: Manish · Last updated May 12, 2026
During a Kanban team's daily stand-up, an agile coach observes that the team seems disinterested in the work status. While it appears that there are no issues with flow, there is a marked lack of attention to ream effort. When the agile coach queries the team for r...
In this scenario, the team’s disinterest and lack of engagement stem from a feeling of perpetual work without a clear endpoint. This could indicate a problem with the way work is being managed or visualized in the system. Let's go through the options to determine the most appropriate one.
Option A: Work with the team to determine points at which to celebrate its work.
- Why it might be a good choice: Celebrating small milestones or completing certain types of work can provide a sense of progress and recognition. Recognizing and celebrating incremental achievements can reenergize the team, boost morale, and reinforce the sense of accomplishment, which may be lacking here.
- Why it's not a perfect fit: While celebration is important, it doesn’t address the root cause of the team’s issue, which is a perceived "endless" flow of work without breaks or a clear stopping point. Celebrating the work might be seen as an attempt to provide temporary relief, but it may not be enough to restore the team’s motivation in the long term.
- When this option would be useful: It could be useful once the team has a sense of closure in their work or after solving other underlying flow issues.
Option B: Provide the team with a break by scheduling a team event.
- Why it might be a good choice: Taking a break or a team-building event can help rejuvenate the team, especially if they're feeling mentally fatigued. Sometimes, a small time away from the regular flow of work can allow people to reset and come back with fresh energy.
- Why it's not a perfect fit: The problem seems more systemic (endless work, lack of visible progress) rather than just fatigue. Taking a break without addressing the flow issue could create a temporary distraction, but it wouldn't solve the fundamental problem of work being unscheduled or not properly segmented.
- When this option would be useful: This could work well if the team is experiencing burnout or if they’ve been working intensely without downtime. However, it’s a secondary solution after addressing the flow issues.
...
Author: Madison · Last updated May 12, 2026
At the end of a product development phase, an agile project team confirms that all tests have passed. The product is released, but the customer complains that it is def...
In this scenario, the customer is complaining that the product is deficient despite tests being passed and the product being released. This suggests that while the team may have focused on meeting technical specifications (e.g., passing tests), they might not have aligned the product with customer expectations or business requirements. The team missed a crucial check or validation step before the product was released. Let’s evaluate the options.
Option A: Requested approval from the project sponsor.
- Why it might seem like a good choice: Getting approval from the project sponsor could be seen as a way to ensure that all stakeholders are aligned and satisfied with the product. This might involve verifying that the product meets business objectives.
- Why it’s not a perfect fit: The project sponsor may not have the specific technical or user-centric knowledge to determine whether the product meets the customer’s needs. The focus on project sponsor approval may overlook finer details, such as actual customer satisfaction or whether the product truly addresses the user requirements.
- When this option would be useful: It’s important when seeking confirmation from key business stakeholders (like the sponsor) that the project goals align with business priorities. However, it doesn’t guarantee that the product will meet customer expectations or that end-user testing has been done.
Option B: Undertaken a review of all requirements.
- Why it might be a good choice: A thorough review of all requirements would ensure that the team understands the product’s goals, user needs, and business priorities. This review would involve validating that the product features and functionality align with what was originally envisioned, both from a business and technical perspective.
- Why it’s not a perfect fit: While reviewing requirements is important, it doesn’t specifically address the validation of the product’s final form against those requirements or customer expectations. Simply reviewing requirements doesn’t guarantee that the product is functioning as expected from the user perspective.
- When this option would be useful: This option is useful early in the project or after changes to the scope. However, if the project has already reached the development phase with tests completed, reviewing requirements may not have been sufficient to prevent deficiencies.
Option C: Conducted an end-of-phas...
Author: Emily · Last updated May 12, 2026
A product owner obtains customer confirmation on product requirements and provides them to the team. After explaining the user stories, the product owner receives ...
In this scenario, the team has received confirmation from the product owner on the product requirements and the user stories have been agreed upon by the team. Now, the next logical step is to move forward with a clear plan for how to develop and complete the user stories. Let's evaluate the options:
Option A: Use agile estimation techniques to create a shared understanding of when the user stories will be completed.
- Why it might seem like a good choice: Estimation is critical to understanding how much effort is required for each user story and to create a shared understanding of timelines. This can help set expectations for the team and the stakeholders about when the work will be delivered.
- Why it’s not a perfect fit: While estimation is important, the team has already agreed on the user stories, and they likely need to focus on the next step—development. Estimation should have ideally been done during sprint planning or as part of backlog refinement, not after the team has already agreed on the user stories. Estimating at this stage could delay the start of the actual work.
- When this option would be useful: This option is useful during backlog grooming or sprint planning to help the team understand the effort involved in completing the stories, but it is not the immediate next step after story agreement.
Option B: Agree upon development and testing activities for the user stories.
- Why it’s the best choice: Once the user stories are agreed upon, the next logical step is to ensure the team is aligned on how they will be developed and tested. This ensures that everyone understands what needs to be done, including coding, unit testing, integration, and any other activities required. It establishes clarity and makes sure that no activities are overlooked.
- Why it’s the best fit: This step ensures that the team has a shared understanding of the work that needs to be done to complete the user stories. It also makes sure that the team’s workflow is clear, reducing ambiguity and potential for misunderstandings. It also establishes the foundation for a quality product, as development and testing are aligned from the outset.
- When this option would be useful...
Author: StarryEagle42 · Last updated May 12, 2026
An agile team has been in place for five years and the customer is satisfied with the team's performance and deliverables. Now that the product is built and delivered, the customer is...
The scenario involves a long-standing agile team with satisfied customer feedback, and the customer is now evaluating the future role of the Scrum Master after the product has been built and delivered. The Scrum Master’s role is crucial in supporting agile processes, team dynamics, and continuous improvement. Let's evaluate the options.
Option A: Expand the Scrum Master’s role to other projects, while allowing them to support the current project.
- Why it might seem like a good choice: If the Scrum Master is experienced and has been successful in supporting the team, it could be beneficial to expand their influence to other projects, especially if those projects are in the same organization or within a similar domain. The Scrum Master can bring best practices and agile expertise to other teams.
- Why it's not a perfect fit: However, the current project has been completed, and the team is already proficient in agile practices. The team may not need the level of support that the Scrum Master was providing during active development, especially once the product is delivered and the need for constant facilitation is reduced. This could lead to underutilization of the Scrum Master if their focus is spread too thin across other projects.
- When this option would be useful: This would be appropriate in a scenario where the Scrum Master has consistently driven improvement across teams and there are other projects that could benefit from their leadership. However, in the context of a completed project, the team might no longer require a full-time Scrum Master.
Option B: Release the Scrum Master, since the team is adequately skilled with agile practices.
- Why it’s the best choice: Given that the team has been in place for five years and the customer is satisfied with the team’s performance and deliverables, it’s likely that the team is now self-sufficient in agile practices. The Scrum Master’s primary role is to facilitate the team’s growth, remove impediments, and ensure the agile process runs smoothly. Once the team is mature and capable of working independently, it might be appropriate to scale back or release the Scrum Master, as their intervention may no longer be necessary for day-to-day operations.
- Why it’s the best fit: With a skilled team, the Scrum Master’s role can shift from being a full-time facilitator to an occasional resource. The team can continue to function effectively without direct support from a Scrum Master, which could free up resources for other areas.
- When this option would be useful: This is ideal when the team has matured enough to take ownership of their processes, and the product is complete or in a maintenance phase where continuous improvem...
Author: Manish · Last updated May 12, 2026
A product owner with experience in a predictive approach wants the team to develop very detailed schedules and cost estimates fo...
In this scenario, the product owner, coming from a predictive (waterfall) background, is seeking detailed schedules and cost estimates for the next 10 sprints. This reflects a desire for control and predictability, which contrasts with the flexible and iterative nature of Scrum and agile methodologies. The Scrum Master’s role here is to guide the product owner toward a better understanding of agile principles and practices. Let’s evaluate each option in light of this context.
Option A: Suggest the product owner start by focusing on the next 2 sprints instead of 10.
- Why it might seem like a good choice: Focusing on the short term (the next 2 sprints) aligns with the agile principle of iterative development, where planning is done incrementally and adjusted based on feedback. This would allow the product owner to see the value of more flexible planning.
- Why it’s not the best fit: While this suggestion brings the product owner closer to agile practices, it might still feel like a compromise between predictive and agile methods. The product owner may still feel uncomfortable with the lack of long-term predictability. A broader explanation of agile practices would be needed to shift the mindset away from traditional project management techniques.
- When this option would be useful: It could be useful as a step towards gradual adoption of agile principles, but it doesn’t fully address the underlying mindset that the Scrum Master needs to address.
Option B: Spend the first few sprints to develop detailed schedules and budgets.
- Why it might seem like a good choice: This would meet the product owner’s request for detailed schedules and budgets, which would likely be seen as a way to align with their previous experience. It might seem like a way to keep them comfortable in the initial stages.
- Why it’s not the best fit: This contradicts agile principles, where detailed long-term schedules and budgets are not considered useful. In agile, the team works with adaptive planning, and the focus is on delivering value and adapting to change. Spending time on detailed schedules and budgets would slow the team down and undermine the agile process, leading to inefficiency and potentially reduced responsiveness to change.
- When this option might be useful: This might be applicable in a scenario where a transition to agile is happening slowly, but it should not be done at the expense of core agile values. This approach would not be a sustainable or effective long-term solution.
Option C: Invite the product owner to the retrospective to explain the team's approach to schedule and budget.
- Why it might seem like a good choice: The retrospective is a meeting focused on reflect...
Author: Krishna · Last updated May 12, 2026
An agile team identifies that their velocity is lower than predicted, and that their previous forecasts in the product roadmap are wrong. The team is worried that they will be unable to ...
In this scenario, the team is facing challenges with velocity and the forecasted delivery timelines. Let’s break down each option to understand its effectiveness and why some are more suitable than others:
A) Collaborate with the product owner to reprioritize the product backlog, thus ensuring that more features will be completed.
- Reasoning: Reprioritizing the backlog might help the team focus on the most critical and high-value features first. However, this doesn't directly address the issue of velocity or forecasts being incorrect. It may improve the delivery of key features, but it does not solve the underlying problem of meeting the original release date or understanding the true capacity of the team.
- Scenario: This would be useful if the team feels overwhelmed with too many features or if there are items in the backlog that can be deprioritized. But, it doesn't necessarily help with understanding why velocity is low or how to correct it in the short term.
- Rejected Reasoning: While it's useful for prioritization, it doesn't solve the immediate problem of inaccurate forecasts or the need for corrective action.
B) Ask the team lead to calculate the team's target velocity according to the project plan, and assign additional resources to increase the capacity.
- Reasoning: Increasing velocity by adding resources might seem like a quick fix, but this approach ignores the fact that velocity is often tied to the team’s current working dynamics and processes. Simply adding people (especially at a late stage in the project) can lead to inefficiencies and may not necessarily boost performance. The project’s true velocity is better understood by evaluating the team's current process and adjusting from there.
- Scenario: This approach could be useful if the issue were resource constraints, but if the velocity is low due to other reasons (e.g., team process inefficiencies, external dependencies), adding more people is unlikely to improve things in the short term.
- Rejected Reasoning: This option could result in short-term inefficiency and doesn't address the root cause of why the team’s velocity is low.
C) Focus on velocity and schedule concerns...
Author: CrystalWolfX · Last updated May 12, 2026
A product owner adds a 21-point, high-priority story to a sprint backlog. The team is concerned that it cannot be completed...
In this scenario, the team faces a situation where a high-priority, 21-point story has been added to the sprint backlog, but the team is concerned about their ability to complete it within the current sprint. Let’s examine each option:
A) Advise the product owner that the story will have to wait until the next sprint.
- Reasoning: This option reflects the Agile principle of maintaining a sustainable pace. It’s important for the team to set realistic expectations and ensure that they are not overwhelmed with too much work. However, simply pushing the story to the next sprint without considering alternatives may not fully utilize the sprint or satisfy the customer's needs in the short term. If this story is critical, just delaying it may not be the best choice.
- Scenario: This option is useful if the story can genuinely wait, and if the sprint backlog already has enough work for the team to handle without introducing overcommitment. However, it may not always align with the customer’s expectations or urgency for this high-priority item.
- Rejected Reasoning: It’s not the most collaborative or flexible approach; it also ignores the potential for adjustment within the current sprint.
B) Work extra hours to complete the story and satisfy the customer's requirements.
- Reasoning: Working extra hours is usually a short-term solution and goes against Agile principles, which emphasize maintaining a sustainable work pace and avoiding burnout. Consistently requiring extra hours can reduce the team's long-term productivity, morale, and engagement. Additionally, it's not always possible to guarantee that extra work will lead to successfully completing the story.
- Scenario: This might be considered in cases of urgent need, but it's generally unsustainable and should be avoided if possible. Agile encourages optimizing processes and collaboration over increasing individual effort.
- Rejected Reasoning: This option is n...
Author: Chloe · Last updated May 12, 2026
A senior team member feels underutilized.
What should the agile practitioner do?
In this situation, a senior team member feels underutilized, which may indicate a potential issue with team dynamics, workload distribution, or role clarity. It’s important to consider options that address both the individual's needs and the team's performance while adhering to Agile principles. Let's break down the options:
A) Transfer the senior member to another team that will more fully utilize their skill set.
- Reasoning: This option might be useful if the senior team member’s skill set is indeed misaligned with the current team’s needs. However, in Agile, team members are generally encouraged to cross-collaborate and learn new skills, rather than be isolated in a role that is too narrow. Moving the senior member to another team might seem like a quick fix but could disrupt the team’s current dynamics or lead to a mismatch in expectations.
- Scenario: This would be appropriate if the team is consistently unable to utilize the senior member's skills and if that is due to the member not being able to contribute in other areas (e.g., if the team needs specialized knowledge that the current setup doesn’t allow). However, it might create unnecessary changes and churn within the organization.
- Rejected Reasoning: While it could solve the underutilization issue, it doesn't prioritize team growth or the idea of improving collaboration and knowledge-sharing, which is core to Agile.
B) Conduct a performance evaluation to determine whether or not this member is a team player.
- Reasoning: In Agile, performance evaluations are not typically done in a top-down, formal way. Instead, self-reflection, team feedback, and continuous improvement are prioritized. Conducting a formal evaluation could create unnecessary pressure, make the senior member feel singled out, and detract from team collaboration. It doesn’t address the immediate issue of how to better engage the member in the team's work.
- Scenario: Performance evaluations might be appropriate in traditional environments, but Agile practices emphasize peer feedback and continuous improvement...
Author: StarlightBear · Last updated May 12, 2026
A product that recently went to market is receiving a great deal of attention from upper management who expresses interest by directly emailing and calling the developer team. The ...
In this scenario, the Scrum Master needs to manage the situation where upper management is reaching out directly to the developer team, leading to frustration and disruption. It's important to address this in a way that respects the team’s focus and maintains the integrity of the Scrum process. Let’s break down each option:
A) Ask the product owner how upper management's comments can be redirected.
- Reasoning: The product owner is responsible for managing communication with stakeholders, including upper management. The Scrum Master can help facilitate this by guiding the product owner on how to handle management's comments and concerns without disrupting the team's workflow. This could involve setting up a structured communication process where upper management’s feedback is collected and filtered through the product owner before reaching the team.
- Scenario: This is an ideal approach because it empowers the product owner to manage stakeholder expectations and provides a clear process for communication. It also respects the Scrum roles and keeps the team shielded from unnecessary distractions.
- Rejected Reasoning: This option is not rejected because it promotes the proper flow of communication and helps balance stakeholder engagement with the team's focus.
B) Direct the developer team to ignore the phone calls and emails.
- Reasoning: Ignoring calls and emails from upper management might be tempting to avoid disruptions, but it can lead to poor communication and potentially damage relationships. Additionally, it could create a perception that the team is disengaged from the stakeholders, which could create frustration and confusion for management. Effective communication is key to managing relationships in Agile, and this approach risks ignoring important feedback.
- Scenario: This might be appropriate if management is being overly intrusive, but it’s generally better to manage the communication flow than to ignore it entirely. Ignoring calls could result in unresolved concerns or missed opportunities for...
Author: VenomousSerpent42 · Last updated May 12, 2026
What estimation technique is an agile team using when collectively estimating the relative size of i...
In this scenario, the team is using story points to estimate the relative size of their stories. Let's break down the options and understand which one is being used:
A) Parametric
- Reasoning: Parametric estimation involves using historical data or statistical models to calculate estimates based on variables or known parameters. It’s not typically used in Agile for estimating story points because it relies on more detailed data and specific metrics.
- Scenario: This method is better suited for traditional project management or environments where detailed historical data is available, rather than for Agile teams using relative estimations.
- Rejected Reasoning: Parametric estimation is too formal and data-intensive for the Agile process of relative estimation using story points.
B) One-to-one comparison
- Reasoning: A one-to-one comparison method might involve comparing a new user story to a previously completed one with the same or similar scope. However, this method is too simplistic and doesn't capture the iterative, collaborative approach used in Agile estimation. It doesn’t reflect the broader discussions and collective team assessment that Agile estimations typically involve.
- Scenario: This approach could be used in some cases but isn’t very common in Agile environments, where the goal is to consider multiple perspectives from the team to establish a shared understanding.
- Rejected Reasoning: This method lacks the collaborative team interaction that is a hallmark of Agile estimation techniques.
C) Affinity
- Reasoning: Affinity estimation involves grouping stories based on relative size (small, medium, large) without assigning explicit point values upfr...
