PMI Practice Questions, Discussions & Exam Topics by our Authors
Why should a project team reduce the work in progress?
Reducing work in progress (WIP) is important for improving the efficiency and effectiveness of a project team. Let’s analyze each option to understand why one might be selected over others:
Option A: It indicates poor project quality
While high WIP might sometimes correlate with lower quality due to overloading team members, it is not the primary reason for reducing WIP. The main problem with high WIP is not directly related to poor quality but to inefficiencies in the process. If too many tasks are left unfinished or overburdened on team members, it may indirectly lead to quality issues, but this is more of a secondary concern. Hence, this is not the best reason for reducing WIP.
Option B: It represents team member's utilization
This could be true in some contexts, but it’s a bit of a misleading justification. The concept of work in progress is often tied to the efficiency of a team's workflow, not just the "utilization" of individuals. Simply having a high number of tasks in progress doesn’t necessarily mean people are effectively utilized—it could indicate that tasks are stalled or incomplete. Focusing only on utilization could encourage the team to start more tasks without completing them, leading to inefficiency. Therefore, this is not a key reason for reducing WIP.
Option C: It represents unrealized value
This is one of the strongest arguments for reducing WIP. When tasks remain in pr...
Author: Matthew · Last updated May 12, 2026
During a review session, a customer representative is concerned that a story fails to satisfy the scope of work. However, the product owner declares that t...
When a discrepancy arises between a customer representative and the product owner regarding the completion of the scope of work, it’s essential to address both the objective and subjective elements of the issue in order to reach the most practical solution. Let’s go through each option:
Option A: Mark it as incomplete and prioritize it for the next sprint
This option suggests treating the story as incomplete, even if the product owner believes the scope is finished. However, this could cause confusion and delay, as it doesn't address the root cause of the disagreement (i.e., differing perceptions of "completion"). It's important to clarify whether the initial scope was truly met, or if there were misunderstandings. If the story isn't actually incomplete but the customer’s expectations were misunderstood, prioritizing it again without resolving the issue may lead to inefficiency. This option could be useful only if there is clear evidence that significant parts of the scope were overlooked, and the remaining work is minor.
Option B: Mark it as complete, since the product owner has the final say
While the product owner typically has the final say on the scope of the story, it is crucial to recognize that their perspective doesn’t necessarily align with the customer’s perspective, especially in agile environments where customer feedback is integral. If the customer feels the scope was not met, simply deferring to the product owner may damage the relationship or result in unmet needs. In this case, the product owner might not have fully captured the customer's expectations. This option ignores the value of customer feedback, which can lead to a disconnect between what the team believes is complete and what the customer believes is necessary.
Option C: Discard it and create a new story for the remaining scope of work
Discarding the...
Author: Amira · Last updated May 12, 2026
Senior management is frustrated at the lack of a detailed implementation plan that shows exactly when the project will end and when all requirements will be met.
The team has been using a rolling wave planning approach so far on the p...
The rolling wave planning approach is a fundamental principle of agile methodologies, designed to provide flexibility and adaptability throughout the project lifecycle. It contrasts with traditional planning techniques, where the full project schedule and scope are predefined and set in stone early on. Let’s evaluate each option to explain why rolling wave planning is beneficial for agile projects and why some options are not suitable in this context.
Option A: It ensures a consistent level of detail is available in the project schedule
This option suggests that rolling wave planning ensures consistent detail in the project schedule. While rolling wave planning does provide increasing levels of detail as the project progresses, this isn’t the most significant benefit when explaining the value to senior management. The key aspect of rolling wave planning is that it focuses on planning in incremental waves, with more detail available only when it's needed, rather than locking everything down upfront. This allows for flexibility, but it doesn’t directly address the concern of having a detailed, fixed plan from the outset. Therefore, this option does not fully capture the essence of the rolling wave approach.
Option B: It prevents a wasteful build-up of requirements inventory that may never be processed
This option highlights a key benefit of rolling wave planning, which is the avoidance of prematurely committing to requirements that might never be necessary. In traditional project planning, there can be a tendency to define all requirements upfront, leading to unnecessary work and a build-up of requirements that may not ultimately be valuable. Rolling wave planning allows the team to prioritize and plan only the work that is immediately needed or understood, avoiding the waste associated with overplanning. This is a strong argument, especially in agile environments where flexibility and continuous learning are essential. It shows that the team is working on the most importan...
Author: Sofia2021 · Last updated May 12, 2026
A team member is stressed due to a heavy workload, while other team members have some slack in their sche...
When a team member is experiencing stress due to a heavy workload, it's important to address the issue in a way that’s both supportive and effective, keeping in mind the overall health of the team and the project’s needs. Let’s explore each option to determine which is the best approach:
Option A: Inform management, and suggest that additional resources may be required
While informing management and suggesting additional resources might seem like a solution, it’s not the most immediate or effective way to address a team member's stress. Before escalating the issue to management, it’s important to assess whether there are ways to manage the workload within the team first. Adding additional resources might not always be the best answer, as it could lead to inefficiency or unnecessary complexity in the project. Also, it could delay addressing the actual issue, which is the uneven distribution of work. This option might be used if the workload issue is truly beyond what the current team can handle, but it’s not the first step to take.
Option B: Discuss the issue with the team in the daily stand-up meetings
While daily stand-ups are a good opportunity to share updates, discussing workload distribution in this setting may not be the most effective approach. Stand-ups are designed for brief, focused updates rather than deep discussions on interpersonal or workload issues. If the team lead were to bring up a team member’s stress during the stand-up, it might make the individual uncomfortable or highlight personal struggles in front of the entire team. This could also disrupt the flow of the meeting and may not lead to a constructive solution. Instead, a more private and thoughtful approach is typically better suited to this type of issue.
Option C: Meet personally with the stressed team member to brainstorm ways to better manage their time
This option is highly effectiv...
Author: RadiantJaguar56 · Last updated May 12, 2026
A product owner for two highly visible projects spends a great deal of time meeting with and reporting to senior stakeholders. The product owner is overwhelmed because both project teams request clarification ...
When a product owner is overwhelmed due to conflicting priorities and continuous requests for clarification, the agile project manager needs to ensure that both the product owner and the teams can manage their workloads effectively while ensuring alignment and clarity on priorities. Let's explore each option in detail:
Option A: Provide both project teams with the highest priority needs
This option addresses the issue by ensuring that the teams know which tasks or features should be prioritized. However, simply giving teams the highest priority needs without context or clarification of the broader requirements might lead to misunderstandings. While this provides direction, it doesn't solve the root problem of why the teams are continuously asking for clarification. Providing priority needs without addressing the underlying communication breakdown could lead to frustration or confusion later, especially if the teams don't fully understand the context or the “why” behind the priorities.
Option B: Request the project team's questions in writing prior to the next meeting
While asking for questions in writing can help streamline communication and give the product owner time to prepare detailed responses, this approach may not be the most effective in a dynamic, agile environment. Agile teams often rely on real-time, open communication to clarify issues and adjust rapidly to changing requirements. Requesting written questions might delay the process and create an artificial barrier between the teams and the product owner. It also doesn’t solve the issue of the product owner being overwhelmed by constant reporting and meetings, nor does it facilitate collaborative problem-solving between the product owner and the teams.
Option C: Facilitate a meeting with each team and the product owner to find a solution
This option is the most proactive and collaborative. Facilitating a meeting between the product ow...
Author: Nathan · Last updated May 12, 2026
A seven-member agile team's composition varies considerably in age, gender, culture, personality type, and professional background.
When planning a team-building ...
When planning a team-building event for a diverse seven-member agile team, the project leader should focus on social awareness as the most crucial interpersonal skill. Here's why:
Key factors to consider:
1. Diversity of the team: The team has considerable variation in age, gender, culture, personality type, and professional background. This means each individual might have different communication styles, values, and perspectives.
2. Creating an inclusive environment: The project leader needs to be sensitive to the diverse needs and preferences of each team member. Social awareness involves understanding the emotions, motivations, and concerns of others, especially in a diverse setting. It allows the leader to guide the team-building event in a way that respects everyone's background and promotes inclusivity, empathy, and mutual respect.
3. Managing potential conflicts: Diverse teams are more likely to experience misunderstandings or cultural clashes. Social awareness helps the leader to detect subtle cues, identify issues early, and address them in a manner that fosters harmony and cooperation within the team.
4. Engagement and participation: Social awareness also helps ensure that all team members feel valued and included, which is crucial for engagement during the team-building event. It enables the leader to identify when someone feels uncomfortable or left out and take steps to encourage their participation.
Why other options are less suitable:
- A) Networking: While networking is important for building connections, it's more about professional relationships outside the immediate team or organization. In a team-building context, it's le...
Author: Vikram · Last updated May 12, 2026
Due to its complexity, a new team member struggles with developing a concise user story.
What advice should the agile pr...
To assist a new team member in developing a concise user story, the agile practitioner should recommend B) Break the story up and focus on the most valuable parts. Here’s why this option is the most effective:
Key Factors:
1. Overcoming complexity: If a user story is too complex for a new team member, it can be difficult for them to understand and articulate it clearly. Breaking the story down into smaller, more manageable pieces allows the team member to focus on one part at a time. This method helps avoid overwhelm and increases clarity.
2. Prioritization: Focusing on the most valuable parts of the story helps the team prioritize work. By addressing the most important or high-impact aspects first, the team can ensure they’re delivering value early, even if the entire story is not yet fully developed or understood.
3. Collaboration and learning: Breaking the story into smaller parts provides an opportunity for collaboration. The new team member can discuss these smaller, more manageable chunks with others, allowing them to learn and build confidence as they develop the story. This is an excellent teaching moment where the new member gains experience in refining user stories over time.
4. Agile principles: One of the core principles of Agile is delivering work in small, incremental pieces that add value. This practice aligns directly with that principle and makes it easier for the new member to develop and deliver parts of the story that can be refined later.
Why Other Options Are Less Suitable:
- A) Hand the story over to a more experienced team member: This option may seem like an easy way out, but it doesn’t help the new team member grow or learn. Agile emphasizes team collaboration and self-sufficiency, and simply passing off the story to someone else reduces the o...
Author: Lucas Carter · Last updated May 12, 2026
Trend analysis shows that velocity is significantly higher than predicted and the release can be completed one month ahead of schedule. The team recommends changin...
The agile practitioner should select option A: Jointly meet with the team and product owner to discuss options and determine the end date.
Reasoning:
1. Collaboration and alignment: The key value of Agile is collaboration between the team, the product owner, and other stakeholders. Rather than simply announcing a new end date or making decisions in isolation, it’s essential to involve the team and product owner in the decision-making process. This ensures that all stakeholders are aligned on the next steps, whether the focus should be on completing the product earlier, improving quality, or adding more features.
2. Flexibility in Agile: While it's great that the team is delivering faster than predicted, the decision to change the end date depends on more than just velocity. The product owner may want to review whether there are additional features that could be added, or whether reducing the time frame should be balanced with improving the product’s quality or addressing technical debt. This collaborative decision-making allows for a more balanced, thoughtful approach.
3. Transparency and communication: Agile thrives on transparency, and having a joint discussion ensures that everyone has a clear understanding of why the change is happening and what it means for the project. This also fosters a sense of ownership and alignment among team members and stakeholders, ensuring that the decision aligns with the overall goals of the product and business.
Why Other Options Are Less Suitable:
- B) Announce that the team has exceeded the predicted velocity, and that the end date will be earlier than planned: While this may seem like a positive move, it bypasses crucial collaboration with the product owner. The product owner may want to ensure that the focus on velocity doesn't result in cutting corners on quality or missing key features. Simply announcing a new end date can lead to misalignment with the broader business strategy and team goals.
- C) Ask the product owner to include additional features in the product backlog, then re-plan subsequent iterations: While adding features could be a good idea if...
Author: Ava · Last updated May 12, 2026
A team's technical lead believes that manual testing tasks should be conducted by junior team members below their level. The junior team members think it...
The Scrum Master should select option B: Facilitate an open and focused team discussion that reinforces team agreements.
Reasoning:
1. Encouraging Collaboration: The Scrum Master’s role is to facilitate communication and collaboration among team members. In this situation, there’s a conflict between the technical lead and the junior team members. Rather than solving the problem by taking a directive approach, the Scrum Master should foster an environment where the team can openly discuss their concerns and come to a mutual understanding. A team discussion will allow the junior team members to express why they feel it’s unfair, and the technical lead to clarify their reasoning.
2. Reinforcing Team Agreements: Teams often have shared agreements or principles (e.g., task ownership, cross-functional collaboration, and mutual respect). Facilitating this discussion will help the team revisit and reinforce these agreements. It is critical that the team collectively agrees on how work should be distributed, ensuring fairness and a shared understanding of roles and responsibilities.
3. Empowering the Team: This approach aligns with the Agile principle of empowering the team to manage their own work. By facilitating a discussion rather than giving orders, the Scrum Master is helping the team take ownership of the issue and find a resolution that works for everyone. This fosters a sense of accountability and trust within the team.
Why Other Options Are Less Suitable:
- A) Tell the technical lead to do the testing: This approach would not resolve the underlying issue and could undermine team dynamics. By assigning the testing tasks to the technical lead, the Scrum Master is bypassing the conflict without addressing the concerns of the junior team members. This could also cause resentment and a lack of trust within the team, as it avoids collaboration and mutual agreement.
- C) Ask the team manager to advise the technical lead that all tasks are ...
Author: Emma · Last updated May 12, 2026
Midway through a project, the product owner learns from the sponsor that a major component, which is already 20 percent complete, is unimportant to users. The component was part of the approved sc...
The product owner should select option C: Ask the team to discontinue developing the component.
Reasoning:
1. Value Delivery and Lean Thinking: One of the core principles in Agile is delivering the most valuable features to users. Since the product owner has learned that the component is unimportant to users, continuing its development would be wasteful. By discontinuing work on this component, the team can redirect their efforts to higher-priority features that offer more value. This approach aligns with the Lean principle of eliminating waste, which is a key part of Agile.
2. Continuous Feedback Loop: Agile promotes responding to change quickly and iterating based on feedback. The feedback from the sponsor, that the component is unimportant to users, is critical and should prompt an immediate course correction. Delaying or ignoring this feedback would go against the Agile mindset of adapting based on new information.
3. Focus on Priorities: As the product owner, the responsibility is to ensure that the team is working on the most important items in the backlog. Since the component no longer aligns with user needs or the project's value proposition, it should be removed from the scope to allow the team to focus on more valuable work.
4. Avoiding Wasted Effort: If the team continues developing the component, 80% of the work still needs to be completed, and that work would contribute to delivering an unimportant feature. Discontinuing the development now saves time, resources, and effort, preventing a potentially costly investment in a feature with low user value.
Why Other Options Are Less Suitable:
- A) Obtain approval from the change control board to discontinue the component: While formal approval processes like the change control board may be appropriate for some types of changes, Agile emphasizes responsiveness and quick decision-making. Waiting for approval from a change control board could delay the decision and lead to additional wasted e...
Author: Emily · Last updated May 12, 2026
A project team meets to estimate user stories for a sprint. While an important non-functional requirement must be delivered in the sprint, th...
In this situation, the project team is faced with a non-functional requirement that is important but causes the total estimate to exceed the sprint capacity. To address this, the team has several options. Here's a breakdown of the reasoning behind each one:
Option A: Estimate only functional requirements that will impact product quality
- Reasoning: This option would allow the team to focus only on the functional requirements that impact product quality, but it risks ignoring the non-functional requirements. Non-functional requirements, even though they might not be immediately visible to the user, are crucial to the overall system performance, security, scalability, etc. Ignoring or deprioritizing them could result in poor system quality or failures later.
- Rejection Reason: This option is rejected because non-functional requirements, although not always visible in user stories, are essential to product performance and reliability. Ignoring them could lead to long-term issues.
Option B: Add team resources
- Reasoning: Adding resources could, in theory, help complete the work within the sprint capacity. However, this could lead to diminishing returns due to factors like team dynamics, onboarding new members, or the time required to coordinate efforts. In agile, it’s generally advised to avoid adding resources mid-sprint unless absolutely necessary.
- Rejection Reason: This option is rejected because it might not be effective in the short term and could disrupt the team’s established workflow. Additionally, introducing new resources late in the sprint does not always result in quicker delivery.
Option C: Refer the issue to the product owner
- Reasoning: Referring the issue to the product owner (PO) can be a valid approach, as the PO might need to decide whether the non-functional requirement can be deferred to a future sprint or whether additional priority should be given to it. The PO can help prio...
Author: Sofia2021 · Last updated May 12, 2026
A development team and product owner disagrees on a user story in the product backlog.
What should ...
When a development team and a product owner disagree on a user story, the agile practitioner (typically the Scrum Master or Agile Coach) should guide the team and product owner to a resolution. The key role of the practitioner is to facilitate collaboration, communication, and understanding, ensuring that both parties can come to a shared agreement on how best to proceed. Let’s examine the different options:
Option A: Have the development team follow the product owner's direction
- Reasoning: In agile, the product owner does have final authority on the prioritization of the product backlog, but this does not mean the development team should simply follow orders without discussion. The development team’s expertise and input are critical to delivering high-quality work. Simply following the product owner’s direction may result in misunderstandings, poor quality, or missed technical considerations.
- Rejection Reason: This option is rejected because it ignores the collaborative nature of agile. Both the development team and product owner need to have open discussions to resolve disagreements. The product owner should not impose a decision without considering the technical input of the team.
Option B: Openly challenge the product owner in the effort to poke holes in their approach
- Reasoning: While it’s important to bring up valid concerns or ask for clarification, openly challenging the product owner in a combative way is not aligned with agile values of collaboration and respect. The goal of any disagreement should be to resolve the issue together, not to undermine or "poke holes" in the other party’s perspective.
- Rejection Reason: This option is rejected because it fosters a confrontational attitude, which is counterproductive in a team environment. Disagreements should be addressed respectfully and collaboratively, with the aim of reaching a mutual understanding.
Option C: Facilitate a conversation about the user story between the development team and the product owner
- Reasoning: This is a core responsibility of an agile practitioner. Facilitating ...
Author: Liam · Last updated May 12, 2026
During a planning session, four out of five team members vote to include eight story points in a particular story, while the fifth membe...
When team members disagree on the number of story points to assign to a user story, it’s essential to use a collaborative, transparent process to reach an agreement. This situation highlights a common challenge in agile planning: differing opinions on complexity, effort, or understanding of the story. Let’s analyze the different options:
Option A: The story should be assigned eight story points as per the majority vote
- Reasoning: While the majority vote could be seen as a way to reach a quick decision, agile principles emphasize collaboration, consensus, and shared understanding. Assigning points based solely on the majority vote could overlook valid concerns from the dissenting team member, which could lead to inaccurate estimates and misalignment on the story’s scope or complexity.
- Rejection Reason: This option is rejected because it doesn’t address the root cause of the disagreement. Agile values collaboration and transparency, so simply deferring to the majority doesn’t encourage dialogue or shared understanding, which could lead to inefficiencies or issues later in the sprint.
Option B: The story should be added to the backlog and reassessed later
- Reasoning: Reassessing the story later may seem like a good way to defer a decision, but it could result in delays and missed opportunities for team alignment. Agile teams benefit from having estimates early in the sprint planning session to ensure proper prioritization and a shared understanding of the work involved.
- Rejection Reason: This option is rejected because postponing the decision can lead to unclear priorities, and delays in planning can affect the sprint’s execution. The team needs clarity on story points to move forward effectively.
Option C: The story should be assigned points after a discussion with the fifth team member to see if a consensus can be reached
- Reasoning: This is the most agile-friendly option. It fosters collaboration, allowing the team to engage in a discussion about the complexity of the story. The team can listen to the co...
Author: Nathan · Last updated May 12, 2026
A project is starting and the type of work is complex and suitable for agile. In assessing the team members, it appears that co-location w...
When dealing with a complex project that is suitable for agile, co-location of team members is often considered ideal because it promotes direct communication, fast feedback, and easier collaboration. However, if co-location is a challenge due to geographical distribution or other factors, the agile practitioner needs to consider ways to foster collaboration and ensure the team can work effectively across locations. Let’s break down the different options:
Option A: Select and implement collaboration tools to augment team interactions
- Reasoning: Given that co-location is challenging, the use of collaboration tools (e.g., Slack, Zoom, Jira, Miro, etc.) can bridge the gap between geographically dispersed teams. These tools facilitate communication, make it easier to track work, and enable real-time collaboration despite the physical distance. Tools can be especially effective in agile environments where communication and iteration are key.
- Selected Scenario: This is a practical solution that leverages technology to foster collaboration, which is essential for remote or distributed teams. Using tools effectively can simulate the benefits of co-location and ensure that the team remains engaged and aligned.
- Rejection Reason: This option is not rejected. It is a commonly adopted strategy in modern agile practices where team members are distributed geographically. Tools provide the infrastructure needed for successful remote work.
Option B: Provide each geographical area with their own product owner and divide the work between the teams
- Reasoning: While having a product owner in each geographical area might seem like a good way to manage distributed teams, it could lead to fragmentation and a lack of alignment across the product vision. Each product owner might have a slightly different interpretation of priorities or scope, which could result in confusion, duplicated efforts, or conflicting priorities.
- Rejection Reason: This option is rejected because it creates the risk of siloed work, conflicting priorities, and diluted focus on the overall product vision. A single product owner ensures a unified product vision and alignment across all teams.
Option C: Increase the number of requiremen...
Author: ShadowWolf101 · Last updated May 12, 2026
Team A is working on the second sprint of a product release. Team B, which is an interdependent team located on the same floor, requires exclusive and frequent in...
When teams are interdependent and need to frequently share information, the way that information is managed and shared can significantly impact their ability to meet their sprint goals. Since Team A and Team B are on the same floor and there is a need for frequent information exchange, it’s important to choose a method that supports fast, effective communication without creating bottlenecks. Let’s examine each option:
Option A: Create a central repository for information, and provide access to Team B
- Reasoning: A central repository (e.g., a shared drive or a tool like Confluence, Jira, or a wiki) is a great way to store and organize information that is critical for both teams. It allows Team B to access the information they need in real-time without having to wait for Team A to manually share it each time. This approach promotes transparency, ease of access, and the ability for Team B to independently retrieve information as necessary.
- Selected Scenario: This option works well when information is stable, reusable, and needs to be accessed frequently by different teams. A central repository ensures that everyone has the same access to up-to-date information without interrupting the work of Team A.
- Rejection Reason: This is the best option and isn’t rejected. It fosters long-term efficiency by ensuring that Team B can access the required information without depending on Team A each time.
Option B: Use an information board that will be visible to all passing through the workspace
- Reasoning: An information board can be helpful for providing quick, visible updates, but it is not ideal for frequent, detailed, or dynamic information exchanges. Team B needs exclusive and frequent information, which may be too complex or specific for an information board. Additionally, an information board doesn’t allow for interactive or detailed communication, which can limit its usefulness for addressing dependencies.
- Rejection Reason: While useful for certain kinds of high-level updates, this option is rejected becaus...
Author: Olivia · Last updated May 12, 2026
Chart Base on the burn down chart, what is the iteration's status?
To evaluate the iteration's status based on a burn-down chart, we would need to analyze the following:
1. Scheduled vs. Actual Progress: A burn-down chart typically shows the amount of work remaining over time. It compares the planned work against the actual progress.
2. Progress Trend:
- If the line on the chart shows that work was completed earlier than planned, this would indicate a faster-than-expected completion.
- If the line is above the ideal burn-down line and does not meet the expected pace, it shows that progress is behind schedule.
- A chart where the actual progress is in line with or very close to the ideal line indicates that the work was completed on schedule.
Now, let's evaluate the options:
- Option A: "It trended ahead of schedule and completed everything on time"
- This is the case when the burn-down line is steeper than the ideal line, showing that tasks were completed faster than planned. This suggests that the team was efficient and likely had some spare capacity or completed some tasks early.
- Key factors: Steeper progress line, all tasks completed.
- Option B: "It took more time than expected and had to be lengthened"
- If the burn-down line is flat or above the ideal line for a longer period, this could indicate that the team encountered delays or difficulties. This suggests that the iteration needed more time to finish the tasks than initially planned.
- Key factors: Delayed progre...
Author: Ava · Last updated May 12, 2026
During planning sessions, an agile practitioner notices that some team members do not share common id...
When team members in an Agile planning session do not share common ideas or are facing conflicts, it’s important to address the issue promptly to ensure effective collaboration and progress. Let’s evaluate each option and understand the best approach:
Option A: Ask the team if they would like to adopt alternative techniques
- Pros: This approach encourages open communication and allows the team to explore new ways of collaboration that could help resolve misunderstandings. It could foster innovation and fresh thinking.
- Cons: However, simply asking the team to consider alternative techniques might not directly address the core issue of differing ideas. It’s a more indirect approach and may not provide immediate resolution or clarity for team members who are struggling to align their ideas during the current planning session.
- Key Factors: Useful when the team is open to exploring new methods or approaches, but may not immediately solve conflicts around specific ideas during a planning session.
Option B: Create a team norms document to set particular guidelines
- Pros: This option is proactive. It provides structure and sets clear expectations for communication, decision-making, and how to handle disagreements. A norms document can prevent misunderstandings in future sessions by establishing clear rules for collaboration.
- Cons: While useful in the long run, it doesn’t directly solve the issue at hand. The team might still face conflicts or a lack of common ideas in the current session before the norms document is created and implemented.
- Key Factors: Helpful for future sessions, but does not provide a quick resolution for the current issue. It is a preventive measure for long-term collaboration improvement.
Option C: Ask the scrum master to resolve the issue at the stand-up meeting
- Pros: The Sc...
Author: BlazingPhoenix22 · Last updated May 12, 2026
More details for a story are required before the upcoming sprint planning meeting.
What should the ...
In this situation, the Scrum Master’s role is to ensure that the team is well-prepared for the upcoming sprint planning meeting. The issue at hand is that more details are required for a user story to effectively plan for the sprint. Let’s evaluate each option to determine the best course of action:
Option A: Email the product owner requesting detailed story specifications and wait for a response
- Pros: Sending an email might seem like a quick way to ask for more details. It’s an easy, low-effort action.
- Cons: This approach can lead to delays, as waiting for a response from the Product Owner may not provide timely information. The email could get missed or take longer to respond to than expected, potentially leaving the team underprepared for the sprint planning. Furthermore, waiting for a response doesn’t guarantee the team can continue their preparations if details are still unclear.
- Key Factors: Not ideal for a time-sensitive issue. It doesn’t engage with the team directly, and there’s a risk of bottlenecking if the product owner’s response is delayed.
Option B: Gather the details from the team members before sprint planning
- Pros: The team might have useful insights into the story and could clarify technical requirements or implementation details. This approach encourages collaboration and may fill in some gaps if the Product Owner isn’t available immediately.
- Cons: The team may not have all the necessary context or may lack the product vision that the Product Owner provides. This could result in incomplete or misinterpreted details, leading to the wrong assumptions being made. It’s crucial to get input from the Product Owner to ensure alignment with the product vision and business goals.
- Key Factors: Helpful for technical details or feasibility discussions, but not a comprehensive solution. The team might not have all the context required for accurate story details.
Option C: Schedule a story grooming session with the product owner before sprint planning
- Pros: Story grooming (or backlog ref...
Author: Leah · Last updated May 12, 2026
Prior to a retrospective, discussions among team members indicate conflict. An agile practitioner wants to ensure an open and safe environment du...
In a situation where there is conflict among team members before a retrospective, it’s essential to ensure that the retrospective environment remains open, safe, and constructive. The goal is to create a space where all team members feel comfortable sharing their thoughts, acknowledging issues, and discussing potential solutions. Let’s evaluate the options:
Option A: Review established ground rules with the team
- Pros: Reviewing the established ground rules is a proactive approach to creating a safe environment. Ground rules typically emphasize respect, openness, and constructive feedback, which can help diffuse tension. It can also set expectations for how team members should behave during the retrospective, reducing the chances of escalation.
- Cons: While reviewing the ground rules is important, this alone might not directly address the underlying issues causing the conflict. It’s a preventative measure that helps set the tone but doesn’t actively resolve the conflict itself.
- Key Factors: This is a great first step before the retrospective begins, but it might not fully resolve the conflict, especially if it’s more personal or deeper-rooted.
Option B: Ask team members specific questions to identify the cause
- Pros: This approach actively engages the team in identifying the root cause of the conflict, which can be useful for addressing underlying issues directly. By asking specific questions, the agile practitioner can surface and address the conflict in a safe and structured way.
- Cons: Directly asking team members about the conflict could potentially make the situation more tense, especially if they feel uncomfortable or unwilling to openly share. It’s also possible that team members might not be ready to address the conflict in the retrospective itself.
- Key Factors: Useful when the conflict can be resolved through open discussion, but potentially risky if the team isn’t yet ready for that level of confrontation. It requires a very sensitive and safe environment to ensure it doesn’t escalate the issue further.
Option C: Encourage the team to continue w...
Author: Layla · Last updated May 12, 2026
A company is considering developing a new, complex application that will require a large initial investment. However, if successful, the profit potential is high.
When preparing an analysis, what should be used to enco...
When preparing an analysis to encourage stakeholders to authorize a large initial investment for a new, complex application, it’s crucial to mitigate concerns about project failure while emphasizing potential return on investment. Let's evaluate each option to determine the most appropriate approach:
Option A: Calculated planned percent complete (PPC)
- Pros: Planned Percent Complete (PPC) measures how much of the planned work has been completed by a certain point in time, often used in project management to track progress against the plan.
- Cons: While PPC gives an idea of how much of the work is planned versus completed, it does not directly address the risk of project failure, nor does it emphasize the potential profitability of the project. PPC is more of a tracking metric rather than a risk mitigation or motivational tool for stakeholders.
- Key Factors: Not ideal for encouraging stakeholders in this case, as it focuses on progress rather than on managing investment risks or showing the project’s value proposition.
Option B: Many small minimally marketable features (MMFs)
- Pros: This option promotes breaking the project down into smaller, manageable, and valuable increments (MMFs). By focusing on delivering small, minimally viable parts of the application, the team can demonstrate progress early, provide value to customers quickly, and validate the market before fully committing large resources. It also reduces the risk of project failure by allowing stakeholders to assess progress incrementally.
- Cons: While MMFs help with reducing risk by allowing for incremental delivery, it does not inherently emphasize the potential high return on investment (ROI) if the project succeeds. It’s more about managing risk during the development process rather than making a compelling case to stakeholders regarding the high-profit potential.
- Key Factors: Excellent for reducing project risk and ensuring early feedback, but not focused enough on directly convincing stakeholders to approve the large initial investment.
Option C: Story points rather than cost estimates
- Pros: Story points are commonly used in Agile to estimate the complexity or effort of work, which could provide some insight into the project’s scale and expected duration. This approach ...
Author: Ethan · Last updated May 12, 2026
While reviewing the sprint burn down during a stand up, the scrum team identifies that they have fallen behind. Upon further discussion, they discover that some quality assurance (QA) team members were unable to ...
In this situation, the scrum team has identified a bottleneck caused by some QA members not being able to use the new automation framework. The team needs to resolve the issue to ensure that the bottleneck does not impede progress in future sprints. Let's go through each option and analyze it:
Option A: "For upcoming sprints, have QA team members ensure that their respective skill sets are considered when accepting stories."
- Analysis: This option suggests that during sprint planning, the team should take into account the skill levels of the QA team when selecting stories. While this approach might help avoid overloading QA with stories they can’t handle due to skill gaps, it doesn't directly address the current bottleneck. It’s more about future prevention than an immediate fix.
- Why it’s rejected: It’s a preventative measure, but it doesn't solve the existing issue of training or enabling the QA team to use the automation framework now.
Option B: "Have QA team members with the appropriate skill sets spend extra time to help the team succeed."
- Analysis: This option suggests that the more experienced QA members should step in and help their colleagues who are struggling with the automation framework. While this may help in the short term, it could lead to burnout or a reduction in the team's velocity. The experienced QA members may not have the bandwidth to assist while also fulfilling their primary responsibilities.
- Why it’s rejected: The core issue isn't just about helping each other out; it’s about ensuring that all team members are equipped to handle the framework. Overloading experienced team members can cause other probl...
Author: VenomousSerpent42 · Last updated May 12, 2026
An organization highly values security. However, a team member on a project has found a way to save time and money with less rob...
In this scenario, the team member has found a way to save time and money by reducing the robustness of security features. However, the organization highly values security, which implies that any decision impacting security needs to be handled carefully, ensuring that it doesn’t compromise the organization's principles. Let's analyze the options:
Option A: "Influence the customer."
- Analysis: Trying to influence the customer to accept less robust security for cost or time savings may not be ideal, especially if security is a priority for the organization. The customer might not have full knowledge of the security risks or might not prioritize security in the same way the organization does. Even if the customer agrees, it can cause long-term risks to both the project and the organization’s reputation.
- Why it’s rejected: This approach could lead to unethical decisions or create a dangerous precedent where the organization’s values are compromised. It’s not a good idea to push the customer toward less security just for savings, especially if security is a core value.
Option B: "Mention the idea at the next retrospective."
- Analysis: Retrospectives are typically focused on reflecting on how the team can improve their processes, not on making major decisions about product features or security policies. While it’s important to discuss challenges, retrospective meetings aren't the right place for debating key decisions regarding the project's security, as they tend to focus more on internal processes, team dynamics, or workflow.
- Why it’s rejected: While retrospectives provide valuable insights for process improvement, they aren't the best forum for presenting security concerns or product feature decisions, especially those with major implic...
Author: Stella · Last updated May 12, 2026
During its first sprint, a new scrum team realizes that it has insufficient team members with test automation skills to effic...
In this scenario, the new scrum team realizes that they have insufficient members with test automation skills, which is hindering their ability to efficiently complete their stories. The team needs to figure out the best course of action to address the skills gap while keeping within the scope and goals of the sprint. Let's evaluate each option:
Option A: "Cross-train some members in the automation framework to broaden their capacity with that skill."
- Analysis: Cross-training some members in the automation framework is a practical approach. It allows the team to expand its skill set without needing to add new team members or invest in lengthy training programs. Cross-training can be done iteratively and quickly, potentially helping the team to overcome the skills gap within the sprint. It aligns well with the Scrum principle of self-organizing teams, where team members take responsibility for their own growth and the success of the sprint.
- Why it’s selected: This option is effective because it is a proactive, internal solution that empowers the team to become more self-sufficient. It balances both short-term and long-term needs and can be integrated smoothly into the team’s existing workflow. It’s a flexible, sustainable approach that strengthens the team’s capabilities.
Option B: "Ask the product owner to add team members to boost this particular skill set."
- Analysis: Adding new team members during the first sprint may sound like a quick fix, but it isn’t an optimal solution for the current situation. Not only could this disrupt the team’s dynamics, but it might also take time to onboard new members, which could delay progress in the sprint. Additionally, adding resources is a strategic decision that should be made carefully to ensure it aligns with the team's needs, the sprint’s goals, and the overall project’s...
Author: Kai99 · Last updated May 12, 2026
During sprint planning, team members have differing opinions on a feature that delivers business value but fails to provide a long-term s...
In this situation, the team is facing differing opinions during sprint planning about a feature that delivers short-term business value but may not provide a long-term solution for the customer. To resolve this, the team needs to align on how to proceed in a way that balances both the immediate needs of the customer and the long-term goals of the product. Let’s examine each option in detail:
Option A: "Refer to the values of the agile framework and the team."
- Analysis: The values of the Agile framework emphasize delivering high-quality, sustainable solutions that meet customer needs, while maintaining a focus on collaboration, customer feedback, and continuous improvement. Referring to the agile values can help the team reflect on whether the short-term feature is in alignment with these values, particularly customer satisfaction, and long-term viability.
- Why it’s selected: This option aligns the team’s decision with Agile principles, encouraging them to prioritize the long-term value for the customer while considering the short-term benefit. It also promotes collaboration and self-organizing teams to work through differences and come to a consensus about what will provide the most value in the long run.
- Key factor in favor: It ensures that the decision is made with the long-term sustainability and customer needs in mind, aligning with Agile’s value of delivering working software that meets customer needs.
Option B: "Review the signed customer contract."
- Analysis: While reviewing the customer contract may provide clarity on contractual obligations, it doesn’t address the broader question of what’s in the best interest of the customer in the long run. Contracts typically outline agreed-upon features and deliverables, but they may not always focus on the long-term value or sustainability of the solution. A contract can be useful for defining scope, but it doesn't necessarily guide decision-making when prioritizing business value or product direction.
- Why it’s rej...
Author: Siddharth · Last updated May 12, 2026
A project team realizes that an important task on the iteration backlog will take more time than originall...
When a project team realizes that an important task on the iteration backlog will take more time than originally estimated, they must decide how to manage the situation in order to keep the project on track. Let’s evaluate each option and determine which one aligns best with Scrum principles and effective project management.
Option A: "Continue working on the task until it is completed."
- Analysis: Continuing to work on the task indefinitely may lead to the team missing other important tasks or overall sprint goals. It could cause delays in the iteration, and the team may end up spending more time on a task than it’s worth, potentially affecting the team's focus on delivering value.
- Why it’s rejected: While persistence is important, continuing to work on a task without considering the broader goals of the sprint is not an efficient approach. This option might lead to diminishing returns and affect the team's ability to complete other high-priority items in the iteration.
Option B: "Remove the task owner from the project team."
- Analysis: Removing the task owner from the team is an extreme response and is unlikely to solve the problem. The issue at hand is that the task is taking longer than expected, not necessarily that the task owner is performing poorly. The problem could be related to task complexity or unforeseen challenges, rather than the individual's capability.
- Why it’s rejected: This approach could demoralize the team member and is not a constructive way to address task delays. It’s also not aligned with Scrum values, which encourage team collaboration and accountability rather than punishing individual performance.
Option C: "Add resources to reduce time to task completion."
...
Author: Rohan · Last updated May 12, 2026
An executive sponsor of a new scrum team actively attends scrum ceremonies.
How does this benefit t...
In a Scrum environment, an executive sponsor who actively attends Scrum ceremonies can significantly benefit the team. Let's break down the different options and understand which one aligns best with the key objectives of Scrum.
Option A: It helps the team to focus on and meet sprint goals
While it’s important that the team stays focused on their sprint goals, the role of an executive sponsor doesn't directly influence daily tasks or help with the execution of specific sprint goals. The team's focus should primarily be guided by the Scrum Master, Product Owner, and the team itself. While an executive sponsor can provide guidance and direction, it’s not their primary responsibility to ensure that the team meets sprint goals.
Rejection rationale: This option is less about direct involvement in the team's day-to-day work and more about strategic oversight.
Option B: It reminds the team about who sponsors the project
This option is more about visibility and recognition. Having the executive sponsor present can serve as a reminder of the person responsible for funding or supporting the project. However, this benefit is somewhat passive and doesn’t actively contribute to the team’s progress or problem-solving.
Rejection rationale: While recognition of the sponsor's role can be valuable, it’s not the most impactful benefit that arises from active participation in Scrum ceremonies.
Option C: It provides high-level project updates to the sponsor
Pr...
Author: StarlightBear · Last updated May 12, 2026
A legal department representative contacts the scrum master because, while the project's budget has been maintained, it has exceeded its origina...
When a legal department representative contacts the Scrum Master regarding a project that has exceeded its original contracted time and scope, the Scrum Master must address the situation delicately. This involves balancing the legal concerns around the contract with the team's ability to deliver value and manage expectations. Let's evaluate each option to determine the best course of action.
A) Meet with the team to gain alignment with the legal department's need to stay within the contracted time and scope
- Reasoning: While aligning with the team is important, this option assumes that the team has the authority or ability to resolve the legal concerns, which they likely do not. The legal and contractual issues typically need to be addressed by the appropriate stakeholders, like the product owner or legal department, not the development team.
- Why Rejected: This approach does not directly address the legal department’s concerns and may misplace responsibility. The Scrum Master’s role is to support the team and facilitate collaboration, not to directly manage legal compliance.
B) Work with the customer to narrow the scope
- Reasoning: Narrowing the scope might be a reasonable approach if the customer is asking for too much, but this assumes that the customer’s demands are a major factor in exceeding the scope and timeline. While scope management is important, the issue seems more related to the contractual agreement than the customer’s direct needs.
- Why Rejected: While this is a good option for general scope management, it might not be directly aligned with resolving the issue of exceeding contracted time and scope as laid out by the legal department. Narrowing scope is an important consideration but is likely only part of the solution.
C) Share the project's trajectory with the legal department
- Reasoning: This approach focuses on transparency. Sharing the project's trajectory with the legal department helps ensure they understand the current situation, including the ...
Author: Benjamin · Last updated May 12, 2026
An agile project leader notices that the team's velocity has decreased. In examining data provided by team members, the project leader discovers that one team memb...
When an agile project leader notices a decrease in team velocity and discovers that one team member is slow to enter story statuses, this can have various impacts on the project. Let's evaluate each option based on the key implications:
Option A: The team will be unable to understand the iteration's status
This is a likely consequence. In Scrum and other agile frameworks, the team’s ability to track the current status of the iteration is vital to understanding their progress. If one team member is slow to update story statuses (e.g., moving stories from "In Progress" to "Done"), the entire team's understanding of the iteration's status could become delayed or inaccurate. This affects the team’s ability to make decisions based on the most current data, and potentially derails their ability to adapt quickly to new information.
Rejection rationale: This option seems quite plausible because the team needs real-time updates to track progress effectively. However, let's examine the other options to see if they offer more specific impacts.
Option B: The team will be unable to judge the project design's validity
While entering story statuses can help track progress, it’s not directly related to judging the project's design or its validity. The team typically assesses the design of the project through other activities such as backlog refinement, reviews, and retrospectives, rather than through story status updates. Therefore, a delay in status updates is unlikely to have a direct impact on the team's ability to assess the design.
Rejection rationale: This scenario is less likely because judging the project design is based on different factors than tracking story sta...
Author: MysticJaguar44 · Last updated May 12, 2026
A product owner complains that some of the requirements identified several iterations ago have not been implemented. The product owner wants to know why the status of t...
When a Product Owner complains about unimplemented requirements that were identified in earlier iterations and asks why their status wasn't communicated, it’s important to address the issue in a way that facilitates transparency and collaboration. Let's examine each option in detail and see which one best addresses the issue:
Option A: Point out that the team chose to work on other requirements to speed up the project
This option focuses on providing a justification for why the requirements were not implemented. While it’s true that priorities can change, this explanation alone might come across as blaming the team’s decision-making, rather than addressing the underlying communication or process issue. Moreover, the lack of communication to the Product Owner about this change in priorities could have led to the misunderstanding in the first place.
Rejection rationale: While this might be an explanation, it doesn’t directly address the communication breakdown, nor does it help resolve the situation in a constructive manner. The Scrum Master's role should focus on improving communication and transparency.
Option B: Ensure that the product owner reviews the contents of the information radiator
This option is a good approach. The information radiator (such as a Scrum board, burndown chart, or task board) is an important tool for maintaining transparency in agile teams. If the product owner regularly reviews the information radiator, they would have been able to see the status of all requirements, including the ones not yet implemented. By encouraging the Product Owner to use these tools, the Scrum Master can foster better communication and visibility of progress.
Selected rationale: This option encourages the Product Owner to engage with the visual artifacts that provide an up-to-date view of the project’s progress, which is key in ensuring transparency. The Scrum Master should make sure the Product Owner is using these tools to stay informed and...
Author: Olivia Johnson · Last updated May 12, 2026
During an iteration review, the agile team asserts that a product is complete because development and review were finished. The product owner disagrees, since th...
In this scenario, there is a disagreement between the agile team and the Product Owner about whether the product is complete. The team believes the product is finished because development and review were completed, but the Product Owner disagrees because testing has not been performed yet. Let's analyze the options:
Option A: Work with the agile team and product owner to agree on the definition of done
This option is the most effective course of action. The definition of done (DoD) is a shared understanding between the team and the Product Owner of what "complete" means for any item. If the team has different expectations of "done" than the Product Owner, this can lead to misunderstandings and inefficiencies. Working with the team and the Product Owner to align on the DoD ensures that both parties are on the same page about what needs to be completed (including testing) for an item to be considered truly finished. This alignment will prevent similar disagreements in the future.
Selected rationale: This option addresses the root cause of the disagreement, which is the lack of clarity around the DoD. It promotes collaboration and sets a clear standard for what constitutes completion.
Option B: Ask the sponsor to determine whether the product is completed
Asking the sponsor to determine whether the product is complete is not an appropriate solution. The sponsor can provide high-level direction, but decisions about the product’s completeness should be made by the team and Product Owner, who are closer to the work. In Agile, the Product Owner has the final say on product readiness based on the team’s delivery and agreed-upon criteria, including testing.
Rejection rationale: This option defers the responsibility from the Product Owner and the team, and it undermines the collaborative nature of the Scrum process. The sponsor should not be the one making day-to-day decisions about whether the product is "done."
Option C: Plan anoth...
Author: Victoria · Last updated May 12, 2026
During a sprint review, the product owner identifies a required improvement for a feature's user interface (UI) delivered dur...
When a product owner identifies a required improvement for a feature’s UI during a sprint review, they need to take action in a way that aligns with Agile principles and ensures proper prioritization and validation. Here's an analysis of each option:
A) Create a user story for this new improvement and put it in the product backlog for prioritization and validation by the customer.
- Rationale: This is the most flexible and Agile-friendly approach. It allows the product owner to add the improvement as a new item in the backlog, where it can be prioritized alongside other items. The customer can then validate the need for this improvement, ensuring that it aligns with the product's goals. Prioritization ensures that the most important tasks are addressed in the future sprints based on customer value.
- Why this is preferred: It respects the Agile principle of continuous improvement, ensures that customer feedback is prioritized, and provides flexibility in planning. The backlog allows the product owner to reevaluate and reprioritize the improvement based on customer needs and team capacity.
B) Create a user story for this new improvement and prioritize it for the next sprint.
- Rationale: While this option seems proactive, it could lead to "sprint overload" or interrupt the team's focus on the current sprint goal. Prioritizing it immediately for the next sprint can undermine the flexibility of the backlog and may bypass necessary customer validation or re-prioritization.
- Why this is less ideal: Without proper validation by the customer or re-assessment of its importance, pushing the improvement into the next sprint could lead to inefficiencies or even waste if the improvement turns out to be less urgent or valuable than anticipated.
C) Document it as a requirement creep.
- Rationale: "Requirement creep" refers to the situation where new requirements continuously emerge without being properly managed. This can be seen as an anti-pattern in Agile because it assumes that the improvement is an unmanageable or excessive ad...
Author: Carlos Garcia · Last updated May 12, 2026
A company is moving into a new space and is determining the best configuration for offices. The management team is also considering ...
When a company is moving into a new space and considering adopting an Agile process, the configuration of the office should support the principles and practices of Agile to foster collaboration, communication, and efficiency. Here’s a breakdown of each option:
A) Arrange the office space to allow co-location of development teams and centrally located information radiators.
- Rationale: This option is in line with Agile principles. Co-location encourages communication, collaboration, and quick decision-making, which are key to Agile success. Having teams close to each other helps in real-time interaction and fosters a collaborative work environment. Information radiators (e.g., task boards, burndown charts, and progress displays) are essential in Agile to provide transparent and up-to-date information to the whole team.
- Why this is preferred: Co-location enables spontaneous discussions, faster problem-solving, and promotes a sense of shared responsibility. Information radiators serve as constant reminders of the team's progress and help align everyone with the sprint goals. This creates an environment conducive to Agile's iterative and collaborative nature.
B) Isolate each development team to reduce all outside distractions.
- Rationale: While some isolation can be beneficial in terms of reducing distractions for focused work, it’s important to strike a balance between focus and collaboration. In Agile, collaboration is vital to quick decision-making, sharing knowledge, and solving problems. Over-isolation can hinder communication and create silos, which goes against Agile’s core values of cross-functional teams and close interaction.
- Why this is rejected: Excessive isolation contradicts Agile’s emphasis on communication and team cohesion. Teams working in isolation may miss opportunities for cross-team collaboration and knowledge sharing, both of which are essential in Agile. This could also discourage spontaneous discussions and the kind of rapid problem-solving needed in Agile workflows.
C) Ensure management understands the need for isolation to allow for concentration.
- Rationale: While concentration is important, Agile encourages collaboration over isolation. Management understanding this need could be a part of the process, but it shouldn’t lead to a rigid en...
Author: CrimsonViperX · Last updated May 12, 2026
An agile team member identifies a potential problem within the project team.
How should the team's ...
In this scenario, an agile team member identifies a potential problem within the team. The response of the team’s coach should foster the principles of self-organization, collaboration, and continuous improvement, which are core to Agile methodology. Let's review the options and analyze them based on these principles:
A) Document the problem, escalate to the project manager, and develop a solution for the team
- Rationale: This approach goes against the Agile principle of self-organizing teams. Escalating the problem to the project manager undermines the team’s autonomy and shifts responsibility away from the team itself. In Agile, the team should be empowered to solve its own problems rather than relying on a higher authority to step in.
- Why this is rejected: Agile values the empowerment of teams to self-manage and resolve issues. Escalating the issue to the project manager detracts from the team’s ownership and might not foster the kind of proactive problem-solving culture Agile encourages.
B) Add the problem to the backlog and assign resolution to a future iteration
- Rationale: While adding issues to the backlog for future resolution is a good practice for work-related problems, this option doesn't address the immediate nature of a potential team dynamic issue. The backlog is typically for product or technical work, not necessarily for resolving team issues, unless it’s an improvement action. Deferring this issue to a future sprint could delay solving an issue that could impact the team's performance or dynamics in the current iteration.
- Why this is rejected: Adding it to the backlog may be useful for technical debt or features, but it is not the best approach for an interpersonal or process issue that can hinder team performance now. Agile encourages resolving team dynamics and process issues as soon as they are identified, rather than deferring them.
C) Instruct the team to try to solve the problem within the team
- Rationale: This is the most Agile-friendly option. Agile teams are designed to be self-organizing, meaning the team should ideally address its own issues. The coach can facilitate by guiding the team on how to approach the problem, but ultimately, the team...
Author: Mia · Last updated May 12, 2026
Stakeholders are displeased with the latest release of a product's software. While most stakeholders attended every sprint review, they were otherwise largely uninvolved in the project.
...
In this scenario, stakeholders are dissatisfied with the product’s latest release, despite attending every sprint review. This suggests that there was a communication gap or a lack of continuous engagement throughout the process, leading to unmet expectations. The agile practitioner needs to identify the most effective approach to improving stakeholder satisfaction, addressing the root cause of the issue, and aligning stakeholder expectations with the team’s work. Let's analyze the options:
A) Communicated early and often, as outlined in the communications matrix
- Rationale: While frequent communication is essential in Agile, simply following a communications matrix (which outlines who to communicate with, when, and how) may not be sufficient if stakeholders were not actively engaged in the process. It's important that communication is not just about frequency but also about the content and level of engagement. If stakeholders attended sprint reviews but were otherwise uninvolved, there might have been a lack of meaningful, proactive communication.
- Why this is rejected: Communication needs to be meaningful, interactive, and not just about frequency. A communications matrix alone doesn’t guarantee stakeholder satisfaction if it’s not paired with efforts to engage them directly and ensure alignment with their expectations.
B) Ensured engagement among stakeholders and the product owner
- Rationale: This option focuses on proactive engagement, which is key in Agile. Stakeholders must be continuously engaged in the development process to ensure that their needs and expectations are being met. The product owner is a central figure in this process, as they serve as the bridge between the team and stakeholders. By ensuring ongoing engagement, the team can receive early feedback, adjust direction as necessary, and align more closely with stakeholder expectations.
- Why this is selected: This option directly addresses the core issue: stakeholders' dissatisfaction arises from the fact that they were largely uninvolved in the project. Ongoing, proactive engagement with stakeholders allows for better understanding of their needs, expectations, and any changes in their priorities. This can also help avoid issues where the product is not aligned with what stakeholders actually wanted.
- Scenario usage: This option is ideal when stakeholders are involved in sprint reviews but are otherwise disengaged or passive throughout the rest of the project. Ensuring regular engagement would provide opportunities for course correction before issues...
Author: NebulaEagle11 · Last updated May 12, 2026
An agile project manager notices that the product manager manages team member's day-to-day tasks in a way that distracts them from their core responsibilities.
In addition, the team believes that their questions on produc...
In this scenario, there are two main concerns: the product manager managing the day-to-day tasks of the team members, which interferes with their core responsibilities, and delayed responses to questions about the product backlog prioritization. The agile practitioner must address both issues effectively to help improve team autonomy and ensure smooth collaboration with the product owner. Let's analyze the options:
A) Discuss and address this in the iteration retrospective
- Rationale: Retrospectives are an excellent venue for the team to reflect on process issues, including role conflicts or delays in communication. However, while retrospectives are a valuable tool for team improvement, this issue seems to be primarily related to role clarity and external interference (product manager involvement in daily tasks), which might not be best solved by simply discussing it in a retrospective. This could become a deeper organizational issue that needs direct intervention, rather than a retrospective discussion that may not lead to immediate resolution.
- Why this is rejected: While it’s good to bring up process issues in a retrospective, this problem is more about role boundaries and timely communication, which could be better addressed with direct action, rather than waiting for a retrospective discussion. Additionally, retrospectives focus on the team’s own processes rather than external roles impeding the team.
B) Let the product owner know it is the project manager's responsibility to drive a team's tasks
- Rationale: This approach is somewhat effective in clarifying roles but doesn't necessarily address the root problem: the product manager is interfering with team members' autonomy and task management. The product owner should work closely with the team to provide product-related direction, not focus on task allocation or micromanagement, which should be the responsibility of the team or scrum master in Agile.
- Why this is rejected: The product owner should focus on the product backlog and prioritization, not managing the team’s day-to-day tasks. This option places blame on the product owner instead of resolving the issue directly with the product manager and improving role clarity. It also does not address the underlying issue of backlog communication delays.
C) Discuss the roles and responsibilities of the project team with the product owner
- Rationale: This option is the most direct and effective response. The product owner and the product manager likely need a clear understanding of their respective roles and boundaries in the Agile process. The product manager should focus on overseeing pr...
Author: Elijah · Last updated May 12, 2026
An agile team member from a cross-functional team has been unable to complete assignments due to tasks assigned by the f...
In this scenario, the issue is that a team member from a cross-functional team is unable to complete assignments due to tasks assigned by a functional manager, which disrupts the flow and productivity of the Scrum team. The Scrum Master's role is to ensure the smooth functioning of the team and address any issues that may impede progress.
Let's break down each option:
A) Dismiss the team member
- Why it's rejected: Dismissing a team member is an extreme action and should not be the first course of action. The team member might be facing constraints that are outside of their control, and dismissing them could create further disruptions. Instead of removing the individual, the Scrum Master should look into the root cause of the issue and address the underlying problem.
- Scenario: This option is not appropriate unless the team member is consistently disruptive or unwilling to collaborate, which is not the case here.
B) Discuss the situation with the functional manager
- Why it's selected: The Scrum Master should approach the functional manager to understand the issue and work toward a resolution. It’s likely that the functional manager doesn’t understand the impact of assigning these additional tasks to the team member. A discussion can help align the priorities and clarify the boundaries between the Scrum team's work and the tasks from functional management.
- Key Factors:
- Agile values collaboration and transparency.
- Scrum Masters act as facilitators and ensure that external forces (e.g., functional managers) don't interfere with the team's autonomy.
- A discussion allows for alignment and education without confrontation.
- Scenario: This is the best course of action when the functional manager may not be aware of the impact of their actions on the team...
Author: Ella · Last updated May 12, 2026
During a mature agile team's planning meeting, a team member proposes a new framework that would considerably reduce implementation time. However, the team lacks the confidence to try the new fram...
In this scenario, a team member proposes a new framework that could significantly reduce implementation time, but the team lacks the confidence to try it. The key goal here is to help the team gain confidence in adopting this new framework, while managing risk and ensuring informed decision-making. Let's examine each option:
A) Develop a spike
- Why it's selected: A spike is a time-boxed research or investigation activity that allows the team to explore a concept or idea in more depth. In this case, the team could use a spike to experiment with the new framework. This approach enables the team to explore the framework in a low-risk environment, gather insights, and address any concerns or uncertainties. A spike can help the team gain practical experience and assess whether the framework will indeed reduce implementation time without fully committing to it yet.
- Key Factors:
- Agile teams are encouraged to experiment and learn iteratively.
- A spike reduces uncertainty and provides the team with more information, which can build confidence.
- This approach fits well when a new solution is proposed but the team is unsure about its feasibility.
- Scenario: This is the ideal option when the team needs to assess a new tool, technique, or framework before fully adopting it.
B) Create an Ishikawa diagram
- Why it's rejected: An Ishikawa diagram (also known as a fishbone diagram) is used to identify the root causes of a problem by categorizing potential causes and examining them systematically. While this tool can be useful for problem-solving and identifying issues, it does not directly address the team's lack of confidence in trying the new framework. It’s more useful for analyzing existing problems rather than exploring new frameworks or concepts.
- Scenario: This option would be useful if there were issues in the current pro...
Author: Suresh · Last updated May 12, 2026
The team is in the middle of an iteration and there is an urgent request for a small change to be introduced to the committed scope. Unless this change is accepted, there is no value...
In this scenario, the team is in the middle of an iteration, and there's an urgent request for a small change that would add value to the customer if accepted. However, adding this change impacts the team's ability to meet their current commitment. The key challenge here is balancing the need to deliver customer value while respecting the integrity of the iteration.
Let's evaluate each option:
A) Add the new change request as a new user story in the product backlog for the upcoming iteration
- Why it's rejected: While this option keeps the change request in the backlog, it delays the delivery of the value to the customer until the next iteration. The main goal of Agile is to deliver value incrementally and frequently. Postponing the change request until the next iteration means that the customer won't receive the value during the current iteration, which goes against the premise of delivering value as soon as possible.
- Scenario: This would be appropriate when the change is not urgent or cannot be realistically completed in the current iteration, but not in this case where it would deliver customer value immediately.
B) Evaluate the impact of the change request and let the team and product owner decide and re-prioritize based on value
- Why it's selected: This approach is in line with Agile principles. The Scrum team, led by the product owner, should evaluate the request's impact and re-prioritize based on value. This allows the team to make an informed decision on whether the change can be incorporated into the current iteration without derailing their commitment. Re-prioritizing ensures that the most valuable work is being done, and it keeps the team focused on delivering customer value. The team’s ability to decide how to adjust their work ensures autonomy and alignment with Agile values.
- Key Factors:
- Customer value: The change is needed to provide value during this iteration.
- Collaboration: The team and product owner need to collaborate to evaluate the trade-offs and impact.
- Flexibility: Agile allows for flexibility, as long as the team is able to accommodate the change without sacrificing key commitments.
- Scenario: This is ideal when the change request is valuable, urge...
Author: Noah Williams · Last updated May 12, 2026
During a review session, an agile team presented done requirements to a group of stakeholders. Stakeholder feedback indicated that the done requirements failed to meet most press...
In this scenario, the team presented their completed (done) requirements to the stakeholders during a review session, only to find that the requirements did not meet the most pressing needs and failed to deliver value. This points to a potential gap in communication, understanding, or alignment between the team and the stakeholders during the iteration. Let’s examine each option to understand how the team could have prevented this situation.
A) Reprioritized requirements prior to committing to iteration work
- Why it's selected: Prioritization of requirements is a key aspect of Agile, and the team should have worked closely with the product owner and stakeholders to ensure that the most valuable and pressing needs were prioritized before committing to the iteration work. If the team had a clearer understanding of the stakeholders' needs, they could have adjusted their priorities to align with the most urgent business goals, ensuring the features developed would meet those needs. Reprioritizing ensures that the team delivers maximum value each iteration.
- Key Factors:
- Agile encourages continuous collaboration and feedback, particularly around prioritization.
- Without the right prioritization, even completed requirements can miss the mark.
- Aligning the work upfront with stakeholder needs reduces the risk of delivering features that don't add value.
- Scenario: This option is ideal in a scenario where there is a misalignment of priorities between stakeholders and the team, leading to wasted effort or unmet needs after the iteration has been completed.
B) Ensured that requirements remained stable during the iteration cycle
- Why it's rejected: In Agile, it’s expected that requirements may evolve as more information is gathered and stakeholders provide feedback. While some stability is important for the team to make progress, rigidly keeping the requirements unchanged throughout the iteration would have hindered the ability to adapt to real-time feedback or shifting priorities. The issue here is more about ensuring alignment early on rather than maintaining stability in requirements during the iteration.
- Scenario: This option would apply in situations where scope creep or constant change during the...
Author: MysticJaguar44 · Last updated May 12, 2026
A member of a project's development team approaches the team lead and requests database administrator training. The team member believes that their inability to handle this work and to rely on ...
In this scenario, a development team member requests database administrator (DBA) training because they feel that their inability to handle this work and the reliance on external specialists is affecting the team's velocity. The team lead needs to balance the need for individual development with the overall productivity and needs of the team. Let's examine each option carefully:
A) Send the member to training
- Why it's rejected: While training can be valuable for the individual, simply sending one team member to training without assessing the broader team’s needs could cause disruption or inefficiency. If only one person receives training, they might not be able to fully share the knowledge or support the team after the training. Moreover, the team lead needs to evaluate if this is the root cause of the velocity issue or if there are other systemic problems that need addressing first. Training should be a targeted decision, not a knee-jerk response.
- Scenario: This approach might be suitable if the training need is urgent and specific to one individual, but in this case, the team lead needs to ensure that the team as a whole can handle the DBA work effectively.
B) Ask the outside specialists if database administration is required from the team
- Why it's rejected: While it's important to understand the role of outside specialists, simply asking them whether DBA skills are required from the team does not address the core issue: the team's ability to meet velocity goals and manage work independently. The team lead should instead focus on whether the team can handle DBA tasks collectively, and whether this is affecting their overall flow. Relying too heavily on specialists can be a problem if it is slowing down the team's ability to self-organize and deliver work efficiently.
- Scenario: This could be used as part of a broader discussion, but it doesn’t provide a proactive solution to building the team’s capacity and resolving the velocity issue.
C) Send one member to training only after asking the team if there is an issue with the current work flow
- Why it's selected: This approach focuses on assessing whether the team's velocity is genuinely being impacted by the lack of DBA skills. The team lead should first evaluate if the team’s velocity problems are due to lack of DBA experti...
Author: Daniel · Last updated May 12, 2026
What role should a servant leader perform to reduce team distractions and improve progress toward pr...
To address the scenario of reducing team distractions and improving progress toward project goals, a servant leader should focus on fostering collaboration, removing obstacles, and guiding the team rather than enforcing strict controls. Let’s examine each option:
A) Managing: To ensure compliance with the project plan
- Reasoning: While managing the team and ensuring compliance with the project plan is important, it can sometimes feel more authoritative than a servant leadership style. Servant leaders prioritize team autonomy and empowerment rather than strict management, so this role might lead to micromanagement, which can inadvertently cause distractions or frustration.
- Rejection Reason: This approach can lead to less engagement and creativity, reducing overall productivity if team members feel overly controlled.
B) Mentoring: To share their knowledge with the team
- Reasoning: Mentoring fits well with a servant leadership approach because it focuses on building relationships and developing the team. A servant leader who mentors provides support, guidance, and knowledge transfer, all of which can help reduce distractions by clarifying questions or uncertainties. Team members can focus more on the project without feeling lost or unsupported.
- Selected Reasoning: By mentoring, the leader actively helps to address gaps in skills or understanding, thus removing potential roadblocks. This role is proactive and helps in nurturing a team that’s confident and self-sufficient, improving progress without causing unnecessary distraction.
C) Controlling: To ensure compliance with the scope, budget, and schedule
- Reasoning: Si...
Author: Emma Brown · Last updated May 12, 2026
During a retrospective meeting, a team develops a large list of initiatives. All will have a positive impact and improve te...
When a team develops a large list of initiatives during a retrospective meeting, it can be tempting to act quickly on all of them. However, this may lead to overwhelm, lack of focus, and even burnout. The agile coach’s role is to guide the team to prioritize and focus on the most impactful and feasible initiatives for improvement. Let’s break down each option to determine the best approach:
A) Positively acknowledge the list and share it with management
- Reasoning: While acknowledging the list and sharing it with management is a good way to communicate improvements and garner support, it doesn’t address the immediate need for the team to focus and take action. Just sharing the list may lead to inaction or overwhelm because the team may not know where to start or how to prioritize effectively.
- Why Rejected: Simply acknowledging and sharing the list doesn’t help the team select a practical and focused course of action. It’s more of a communication step rather than a productive next move. The team needs guidance on how to prioritize and implement.
B) Immediately have the team implement the initiatives
- Reasoning: Implementing all initiatives immediately, even if they will have a positive impact, is not a sustainable approach. The team will likely struggle to balance multiple initiatives, leading to decreased focus, increased complexity, and potential burnout. It’s also possible that some initiatives may not provide as much value as others or may require more resources than initially anticipated.
- Why Rejected: This option fails to prioritize and instead encourages a scattered approach, which can reduce the effectiveness of the improvements. It doesn’t take into account capacity or the most impactful changes.
C) Help the team choose one or two initiatives for immediate implementation
- Reasoning...
Author: Zain · Last updated May 12, 2026
A product owner concludes that the majority of a project's value can be delivered by completing only the first half of the prior...
When a product owner determines that the majority of a project's value can be delivered by completing only the first half of the prioritized backlog, it's crucial to make an informed decision that maximizes value delivery, manages expectations, and aligns with the project's goals. Let's analyze each option to determine the best course of action.
A) Remove the second half of the backlog, and communicate their decision in the next backlog grooming meeting
- Reasoning: Removing the second half of the backlog might be premature unless it’s certain that these items will not provide value. A product owner should avoid eliminating potential work without proper validation. Additionally, backlog grooming is about refinement and prioritization, not necessarily about removing items completely. This option could restrict future flexibility and prevent re-prioritization if circumstances change.
- Why Rejected: While communication is important, removing items too soon could be a mistake. The backlog may still contain items that could add value later, and the decision should involve more careful stakeholder and team collaboration.
B) Reprioritize backlog items to future iterations
- Reasoning: Reprioritizing the backlog for future iterations makes sense if the team can complete valuable work in future sprints. This allows the product owner to focus on what’s most important now, while still keeping an eye on future priorities. However, this option doesn’t guarantee that value is realized immediately; the backlog may still have items that are of lower priority but might still need attention in the near future.
- Why Rejected: While this approach ensures a continued focus on value, it might not address the immediate need for delivering the most valuable work now. It defers important decisions and doesn't actively help in realizing value in the short term.
C) Work with the team to deploy the first half of the backlog to ensure that value is realized
- Reasoning: This is a pragmatic and value-driven approach. By focusing on t...
Author: Liam · Last updated May 12, 2026
During the review session, the product owner discovers that the user interface has a response time of 10 seconds. The non-functional requirements state that it should respond in less than two seconds. The team complains...
In this scenario, the product owner discovers a significant discrepancy between the user interface's response time and the non-functional requirement. The team’s complaint that the requirement wasn’t communicated suggests a misalignment in expectations and a lack of clear documentation or communication about the requirement. To prevent this, let's examine each option in detail to determine the best approach.
A) A comprehensive user story with all non-functional requirements should have been created
- Reasoning: Creating a user story that includes non-functional requirements is a good practice because it makes sure that these requirements are part of the overall feature delivery. However, non-functional requirements often don’t fit neatly into a user story since they are usually system-wide or technical in nature. They are better suited to being part of acceptance criteria or definitions that apply across multiple user stories or tasks.
- Why Rejected: While creating a user story that incorporates non-functional requirements is helpful, it might not be sufficient on its own. Non-functional requirements are often cross-cutting concerns that need to be treated separately from specific feature-based user stories.
B) Non-functional requirements should have been added to the acceptance criteria
- Reasoning: Acceptance criteria are used to define the conditions that must be met for a user story to be considered complete. If non-functional requirements, such as performance criteria, are added to the acceptance criteria, it ensures that they are explicitly checked during development and testing. This way, the team knows from the outset that these are requirements they must meet for a feature to be deemed "done."
- Why Selected: This is the most effective option. By including non-functional requirements as part of the acceptance criteria, the team knows that they must consider them when developing the feature. This makes the requirements clear and testable, helping the team avoid surprises during review sessions.
C) Non-functional requirements should have been added to the definition of done
- Reasoning: The d...
Author: Kai · Last updated May 12, 2026
Midway through a sprint, a scrum team member advises the team of a new requirement that may change t...
When a team member identifies a new requirement midway through a sprint, it’s crucial to address how this requirement impacts the sprint goal, scope, and capacity. The team needs to handle this situation in a way that respects agile principles and ensures minimal disruption to the sprint. Let's analyze each option to determine the best course of action.
A) Work on requirements that the product owner may have overlooked
- Reasoning: While it’s possible that the product owner overlooked a requirement, it’s not the team’s role to decide unilaterally to add unplanned work to the sprint. In Agile, the product owner is responsible for managing and prioritizing the product backlog, and changes to the scope should be discussed with them. Working on requirements without proper clarification could lead to misalignment and scope creep.
- Why Rejected: The team should not take it upon themselves to implement a new requirement without first consulting with the product owner. It could lead to mismanagement of scope and potential miscommunication about priorities.
B) Record the scope creep in the change management log
- Reasoning: While it's important to track changes, simply recording scope creep without addressing the issue directly doesn’t solve the problem. In Agile, the team needs to adapt quickly to changes and prioritize them based on business value and feasibility, rather than just documenting them. The focus should be on ensuring that the team can still meet the sprint goal and respond to changes appropriately.
- Why Rejected: Recording scope creep in a log doesn’t directly address the issue of how to handle the new requirement. Agile encourages flexibility and responsiveness to change, not just logging changes after they occur.
C) Add the new requirement to the product backlog
- Reasoning: The product backlog is the correct place for new requirements, as it is the living document that reflects the current needs and priorities of the product. If a new req...
Author: ThunderBear · Last updated May 12, 2026
A product owner, new to the role, is very enthusiastic about an agile project with an energetic team.
What should be don...
To ensure the successful delivery of a product, the first thing that should be done is to align the team and the product owner on a shared understanding of the project's goals, guiding principles, and how they will work together. This requires clear communication, collaboration, and an understanding of the product's vision.
Evaluation of Options:
1. Option A: Hold a meeting with the team and the product owner to develop the team charter, working agreement, guiding principles, and product vision
- Reasoning: This is a strong choice because it creates a collaborative environment where both the product owner and the team get a chance to align their expectations, understand the shared vision, and agree on how they will work together. This helps establish a solid foundation for teamwork and communication. Developing the product vision together ensures that everyone has clarity on the objectives and goals from the very start.
- Why it’s selected: It promotes alignment between the team and the product owner, sets the stage for a positive working relationship, and covers all the key aspects of the project—vision, principles, and team dynamics.
2. Option B: Ask the product owner to create the project vision and charter, and then discuss the guiding principles with the team
- Reasoning: While it's important for the product owner to define the vision and charter, doing this in isolation can lead to misalignment with the team. The guiding principles should be a shared creation between the team and the product owner, as they impact the way the team will work together. Creating the vision first is good, but not without team involvement at this stage.
- Why it’s rejected: It might create a disconnect between the product owner’s vision and the team’s approach to working, leading to miscommunication or mis...
Author: Noah Williams · Last updated May 12, 2026
During a current sprint, a team member asks permission from the scrum master to investigate an alternative de...
In Agile, especially in Scrum, it’s crucial to promote an environment of continuous improvement, experimentation, and adaptability. If a team member asks to investigate an alternative design approach during the current sprint, the Scrum Master needs to balance the need for progress in the current sprint with the benefits of innovation and learning.
Evaluation of Options:
1. Option A: Discourage the team member from deviating from the plan and document the request during the retrospective
- Reasoning: While sticking to the plan is important for maintaining focus and delivering the sprint goal, discouraging exploration might suppress valuable learning or innovation. Agile encourages teams to adapt and explore improvements, especially if an issue arises that could benefit from exploration. Documenting it for the retrospective can make sense, but outright discouraging it may hinder the team's ability to innovate or adapt when necessary.
- Why it’s rejected: This approach is too rigid and could stifle the team’s ability to experiment and improve the product increment. It doesn't foster the kind of open collaboration that Scrum promotes.
2. Option B: Encourage the team member to research the issue and present the findings during the retrospective
- Reasoning: Encouraging the team member to explore the alternative approach and present findings later can be a good idea because it fosters experimentation. However, this is a bit disconnected from the immediate needs of the sprint. If the investigation might impact the sprint goal or timeline, it could cause distractions.
- Why it’s rejected: While it's valuable to allow time for exploration, this option doesn't directly encourage experimentation during the sprint. It might lead to delays in the sprint or unnecessary distractions if not handled carefully.
3. Option C: Discourage the team member from using experimentation/spikes unless it is fully developed and accounts ...
Author: Rahul · Last updated May 12, 2026
The scrum master for a large project must provide an estimate of what can be delivered in six months...
In Scrum, it's essential to be realistic and adaptable in planning, as it involves constant feedback and flexibility. When a Scrum Master is asked to estimate what can be delivered in six months, the focus should be on maximizing transparency and managing expectations while aligning with Agile principles.
Evaluation of Options:
1. Option A: Commit to a specific feature set for delivery
- Reasoning: Committing to a specific set of features without sufficient information or planning would be premature. Scrum is iterative, and it’s difficult to predict exactly what will be achievable in six months without regular feedback loops. This approach could lead to unrealistic expectations and failure to adapt to changing circumstances.
- Why it’s rejected: This goes against the Scrum principle of flexibility. The product backlog should evolve, and making a strict commitment upfront is not aligned with the dynamic nature of Agile development.
2. Option B: Explain that a commitment will be provided after planning
- Reasoning: While it’s important to plan iteratively and adapt, saying "we’ll commit later" without offering a tangible basis for estimation might come across as vague. The Scrum Master should help stakeholders understand the challenges of long-term forecasting in Agile and provide a more concrete estimation method based on available data. This option doesn’t fully utilize the tools that Scrum provides for forecasting.
- Why it’s rejected: While the option acknowledges the need for planning, it lacks the proactive use of Scrum tools and data, like historical velocity, which can be valuable in providing a reasonable range of what can be delivered.
3. Option C: Have the team estimate in story points to commit to a specific set of features
- Reasoning: Estimating in story points can provide a...
Author: Harper · Last updated May 12, 2026
A member of the development team is working on a prioritized non-functional requirement involving integrating with a 3rd party system. This integration has not bee...
When dealing with a non-functional requirement like integrating with a 3rd-party system that has not been done before, the focus should be on exploring the solution with flexibility, minimizing risk, and ensuring feedback loops. It's critical to handle this task with care because it involves uncertainty and technical complexity, so the approach should be experimental and iterative rather than rigid or overly detailed from the outset.
Evaluation of Options:
1. Option A: Develop and document a detailed architectural design, peer review with the development team, and implement/test
- Reasoning: While documenting a detailed architectural design can be helpful, Scrum values adaptability and the ability to respond to change over extensive upfront planning. In this case, a detailed architectural design might not be the most efficient use of time before testing and experimenting with the integration itself. Since this is an unfamiliar integration, it’s better to start small, test quickly, and learn from the process rather than invest in a comprehensive design that may need to be adjusted later.
- Why it’s rejected: This approach may lead to over-engineering and wasted effort if the integration approach doesn't work as expected. It's not as adaptable as an iterative, test-driven approach, which is more suitable in Agile projects.
2. Option B: Develop the functional requirements of the solution first before any non-functional requirement, as they provide more customer value
- Reasoning: While functional requirements are crucial, non-functional requirements (such as system integrations) are often just as important for delivering a usable product. Prioritizing functional requirements without considering how the system will interact with external systems may cause delays or rework later on, especially if integration challenges are discovered too late.
- Why it’s rejected: Ignoring non-functional requirements can lead to technical debt or a product that is not fully functional from an operational perspective. Integration with a 3rd party is a core part of deliverin...
Author: Vivaan · Last updated May 12, 2026
During a retrospective, the agile practitioner discovers that a team member's process improvement idea has worsened t...
When a team member’s process improvement idea has worsened the outcome during a retrospective, it’s essential to foster a culture of openness, learning, and continuous improvement, rather than placing blame or suppressing discussion. The response should promote collective problem-solving and an understanding that not every experiment will lead to immediate success, but it’s still valuable as a learning opportunity.
Evaluation of Options:
1. Option A: Commend the team on trying the idea, then encourage discussion regarding alternatives
- Reasoning: This option is the most aligned with Agile principles of openness, learning, and improvement. It acknowledges the team's effort to experiment with a new idea, which is crucial in fostering a growth mindset. By encouraging a discussion of alternatives, the team is empowered to analyze what went wrong and explore solutions together, making the process a collaborative learning experience.
- Why it’s selected: This option encourages transparency and creates an opportunity for the team to discuss the failure and adjust. It ensures that the failure is seen as a stepping stone for growth and refinement, rather than something to be avoided or hidden. It also empowers the team to make decisions collectively, reinforcing team ownership of improvements.
2. Option B: Ask a manager to direct the team on fixing the process
- Reasoning: This option shifts the responsibility from the team to management, which could undermine the team's autonomy and sense of ownership over the process. Agile encourages self-organizing teams that are capable of making decisions about how to improve their own processes. Bringing a manager into the conversation might signal a lack of trust in the team’s ability to solve the problem themselves.
- Why it’s rejected: This undermines the principles of self-organization and collaboration in Agile. It should not be necessary for management to intervene unless there are systemic issues beyond...
