Decision Making
Decision Making Interview with follow-up questions
1. Can you describe a situation where you had to facilitate a decision-making process in a Scrum team?
In one project, the Scrum Team needed to decide whether to continue with the existing API integration approach or migrate to a new third-party service mid-product cycle. The decision had implications for the Sprint Backlog, the Product Backlog ordering, and potentially the Product Goal—so it needed genuine input from the Developers and alignment with the Product Owner.
My role was to facilitate the process, not drive the outcome. I structured it in a few steps:
First, I created space in a dedicated session separate from the regular Scrum events, so the team wasn't trying to make a high-stakes decision under the time pressure of Sprint Planning. I asked the Developers to prepare a brief analysis of each option against criteria they agreed mattered: technical risk, estimated effort, and impact on the current Sprint Goal.
Second, I used a structured format—each person shared their view before open discussion started—to prevent the loudest voices from anchoring the conversation before quieter team members had spoken. The 2020 Scrum Guide characterizes the Scrum Team as self-managing, which means the Developers should own technical decisions like this. My job was to ensure the process was fair and that the Product Owner understood the trade-offs, not to pick the answer.
Third, once the team reached a clear direction (in this case, staying with the existing approach for the current Product Goal and flagging the migration as a future backlog item), I made sure the decision and its rationale were captured in a way that would survive team turnover.
The follow-up interviewers often ask is: what do you do when the team can't reach consensus? My answer is that I use techniques like dot voting or Fist-to-Five to make the level of disagreement explicit, then facilitate a time-boxed discussion focused specifically on the blocking concerns. If it's truly deadlocked on a technical question, that's often a signal that the uncertainty is real and the right answer is to make a reversible decision and inspect the outcome in the next Sprint.
Follow-up 1
How did you ensure everyone's input was considered?
To ensure everyone's input was considered, I created a safe and inclusive environment where team members felt comfortable expressing their opinions. I encouraged active participation by asking open-ended questions and actively listening to everyone's perspectives.
I made sure to give equal opportunity for everyone to speak and ensured that no one dominated the discussion. I also encouraged quieter team members to share their thoughts by specifically asking for their input.
Additionally, I used collaborative tools like online whiteboards or shared documents to capture and document everyone's input. This allowed team members to see their ideas being acknowledged and considered by the entire team.
Follow-up 2
What was the outcome of the decision?
The outcome of the decision was that the team collectively decided to go with Option A, which was the more established technology with a larger community and extensive documentation. This decision was made based on a thorough analysis of the pros and cons of both options and considering their impact on our project goals, timeline, and team's skillset.
By choosing Option A, we were able to leverage the existing knowledge and support system available for that technology, which ultimately helped us in delivering the project successfully within the desired timeframe.
Follow-up 3
How did you manage any disagreements during the process?
During the decision-making process, it is natural for disagreements to arise. To manage these disagreements, I employed the following strategies:
Active listening: I made sure to actively listen to everyone's perspectives and concerns without interrupting or dismissing their ideas. This helped in understanding the underlying reasons for disagreements.
Facilitating open discussions: I encouraged open and respectful discussions where team members could express their differing opinions. I ensured that everyone had an opportunity to present their arguments and counter-arguments.
Seeking common ground: I looked for areas of agreement or compromise among the team members. By focusing on shared goals and objectives, we were able to find common ground and work towards a mutually acceptable solution.
Data-driven approach: I encouraged the use of data and evidence to support arguments. This helped in making the decision-making process more objective and reduced the influence of personal biases.
By employing these strategies, I was able to effectively manage disagreements and ensure that the decision-making process remained constructive and collaborative.
Follow-up 4
What would you do differently next time?
Reflecting on the decision-making process, there are a few things I would do differently next time:
Allow more time for individual reflection: In the given situation, I focused on facilitating group discussions and gathering input during the team meeting. However, in the future, I would allocate some time for individual team members to reflect on the options and gather their thoughts before the meeting. This would ensure that everyone has a chance to fully process the information and come prepared with their insights.
Seek external expertise: In complex decision-making situations, it can be beneficial to seek external expertise or opinions. Next time, I would consider involving subject matter experts or seeking input from external sources to gain a broader perspective and ensure a more informed decision.
Document the decision-making process: While I used collaborative tools to capture everyone's input, I would also document the decision-making process more comprehensively. This would include recording the key arguments, considerations, and the rationale behind the final decision. Having a documented record would help in future reference and provide transparency to stakeholders who were not directly involved in the process.
By implementing these changes, I believe I can further improve the decision-making process and ensure a more inclusive and well-informed outcome.
2. How do you handle decision-making when there is a conflict of interest among team members?
Conflicts of interest in a Scrum team often show up when individual preferences or external pressures pull against what is best for the Sprint Goal or the Product Goal. The Scrum Master's role here is not to be a judge—it is to make the decision-making process transparent and to anchor the conversation back to the team's shared commitments.
My approach:
Name the conflict clearly. Unacknowledged conflicts of interest tend to go underground and show up as passive obstruction. I surface them explicitly but neutrally: "It sounds like you each have a different stake in this outcome—let's make that visible before we decide."
Return to the Sprint Goal and Product Goal as objective criteria. The 2020 Scrum Guide establishes these as the team's commitments. When two team members want different things, the question is not whose preference wins but which option better serves the Sprint Goal and, longer term, the Product Goal. Reframing the conversation this way depersonalizes the conflict.
Separate the people from the positions. I ask each person to explain the interest behind their position—what outcome they are actually trying to protect—rather than defending a fixed answer. This often reveals that the underlying interests are more compatible than the stated positions.
Use structured techniques where needed. For high-stakes decisions, I might use dot voting, a decision matrix, or a Fist-to-Five to make the level of support visible and prevent the loudest voice from dominating.
Escalate clearly when necessary. If a conflict of interest involves the Product Owner and the Developers—for instance, a disagreement about what scope is actually feasible within a Sprint—the Scrum Master's role is to facilitate that conversation, not to arbitrate it. The Product Owner owns the "what"; the Developers own the "how" and "how much." Keeping those accountabilities clear usually resolves apparent conflicts that are really just unclear boundaries.
Follow-up 1
Can you provide a specific example?
Certainly! Here's an example:
In a previous project, there was a conflict of interest between two team members regarding the allocation of resources. One team member wanted to allocate more resources to their own task, while the other team member believed that the resources should be distributed evenly among all tasks.
To handle this conflict, I scheduled a meeting with both team members to discuss their perspectives and concerns. I facilitated a constructive discussion where both team members were able to express their viewpoints.
During the meeting, we identified the common goal of completing the project successfully within the given timeline. We explored alternative solutions, such as reallocating resources based on the urgency and importance of each task.
After evaluating the options, we agreed on a compromise where resources were allocated based on the priority of tasks. This decision was communicated to the entire team, along with the rationale behind it.
This example demonstrates how I handled a conflict of interest by following a fair decision-making process and ensuring that the team's goals were prioritized.
Follow-up 2
How did you ensure a fair process?
To ensure a fair process in decision-making during conflicts of interest, I take the following steps:
Impartial facilitation: I act as an impartial facilitator during discussions, ensuring that all team members have an equal opportunity to express their viewpoints.
Active listening: I actively listen to all team members, giving them the space to fully articulate their perspectives and concerns.
Encouraging diverse perspectives: I encourage team members to consider different perspectives and challenge their own assumptions. This helps in broadening the range of options and finding a fair solution.
Transparency: I ensure transparency by clearly communicating the decision-making process, including the criteria used to evaluate options and make a final decision.
Consensus building: I strive to build consensus among team members by finding common ground and addressing their concerns. This helps in ensuring that the decision is accepted and supported by the team as a whole.
By following these practices, I aim to create a fair and inclusive decision-making process.
Follow-up 3
What was the impact on the team?
The impact of handling conflicts of interest in a fair and transparent manner can be positive for the team. Here are some potential impacts:
Improved trust and collaboration: By involving team members in the decision-making process and considering their perspectives, trust and collaboration within the team can be strengthened.
Enhanced problem-solving skills: Dealing with conflicts of interest requires the team to think critically and explore alternative solutions. This can enhance their problem-solving skills and promote creativity.
Increased team cohesion: When conflicts are resolved in a fair manner, team members are more likely to feel valued and heard. This can lead to increased team cohesion and a sense of unity.
Higher motivation and productivity: When team members feel that their interests are being considered and their voices are being heard, they are more likely to be motivated and productive.
Overall, handling conflicts of interest in a fair manner can have a positive impact on team dynamics and performance.
Follow-up 4
How did you manage the aftermath of the decision?
Managing the aftermath of a decision made during a conflict of interest is crucial to ensure the team moves forward in a positive manner. Here's how I typically manage the aftermath:
Communicate the decision: I communicate the decision to the team members involved and the wider team. I explain the rationale behind the decision and address any questions or concerns they may have.
Provide support: I offer support to team members who may be affected by the decision. This could involve providing additional resources, guidance, or reassurance.
Monitor the situation: I closely monitor the impact of the decision on the team and the project. This allows me to identify any issues that may arise and take proactive measures to address them.
Foster a positive environment: I strive to create a positive work environment where team members feel comfortable expressing their opinions and concerns. This helps in preventing future conflicts and maintaining team morale.
By managing the aftermath of the decision effectively, I aim to ensure that the team can move forward and continue working towards their goals.
3. What strategies do you use to facilitate decision-making in a Scrum team?
The 2020 Scrum Guide describes the Scrum Team as self-managing—meaning the Developers decide how to do their work, and the team as a whole determines how to organize around the Sprint Goal. As a Scrum Master, my job in decision-making is to create conditions where good decisions can emerge from the team, not to make decisions for them.
The strategies I use:
Use the Scrum framework itself as the decision structure. Sprint Planning is where the team makes the most consequential per-Sprint decisions: what to select, how much to take on, and how to approach the work. The Sprint Goal gives the team a clear criterion for evaluating options throughout the Sprint. I make sure these events are used well rather than treated as formalities.
Make implicit criteria explicit. Many team disagreements are actually disagreements about unspoken priorities. I ask the team to agree on what matters—quality, speed, risk reduction, user impact—before evaluating options. Techniques like dot voting, impact/effort matrices, or simple forced ranking work well here.
Separate decision types. Reversible decisions (how to implement a specific feature) should be made quickly by whoever has the most relevant knowledge, ideally the Developers closest to the work. Irreversible or high-stakes decisions (changes to the Product Goal, significant architectural shifts) warrant broader input and more deliberate process. Conflating the two wastes time on low-stakes choices and under-invests in high-stakes ones.
Protect psychological safety. People share genuine views only when they believe it's safe to disagree. I create that safety by modeling it—asking for dissenting views, treating concerns as data rather than obstacles, and never letting the discussion get personal.
Time-box discussions. A decision that takes two hours in a meeting could often be made well in twenty minutes with a clear structure. I use explicit time-boxes and visible facilitation to prevent circular discussion.
Interviewers often follow up on how I handle situations where the team defers to me to make the call. My answer: I resist that, because a decision the team makes is one they own. If the team is genuinely stuck, I'll facilitate a structured vote and commit the team to trying the outcome for one Sprint and revisiting it in the Retrospective.
Follow-up 1
Can you give an example of when you used these strategies?
Certainly! Here's an example of when I used these strategies to facilitate decision-making in a Scrum team:
We were working on a project where we had to decide on the technology stack to be used for the development. I organized a meeting with the team members and encouraged them to share their opinions and preferences. We discussed the pros and cons of different technologies, and I facilitated a consensus-based decision-making process. We used dot voting to prioritize the options, and then analyzed the data and feedback from the team members. Based on this, we reached a decision to use a specific technology stack that was agreed upon by the majority of the team. This approach helped to ensure that everyone's voices were heard, and that the decision was made based on a combination of expertise and data.
Follow-up 2
How do you ensure that all voices are heard?
To ensure that all voices are heard in the decision-making process, I follow these practices:
Active listening: I actively listen to each team member's opinions, ideas, and concerns. This includes giving them my full attention, asking clarifying questions, and paraphrasing their points to ensure understanding.
Encouraging participation: I create a safe and inclusive environment where team members feel comfortable expressing their thoughts and ideas. I encourage everyone to contribute and make sure that no one dominates the discussion.
Structured discussions: I use structured discussion techniques such as round-robin or go-around to give each team member an equal opportunity to speak. This helps to prevent any individual from being overshadowed or ignored.
Anonymous feedback: In some cases, I may use anonymous feedback mechanisms such as surveys or suggestion boxes to gather input from team members who may be hesitant to speak up openly.
By implementing these practices, I strive to ensure that all voices are heard and considered in the decision-making process.
Follow-up 3
What challenges have you faced while implementing these strategies?
While implementing these strategies, I have faced a few challenges:
Time constraints: Sometimes, there may be time constraints that limit the amount of discussion and deliberation that can take place. In such cases, I try to prioritize the most important decisions and ensure that the team has enough information to make an informed choice.
Conflicting opinions: It is common for team members to have different opinions and preferences. Managing conflicting opinions can be challenging, but I address this by encouraging open and respectful communication, facilitating discussions to find common ground, and emphasizing the importance of reaching a consensus.
Dominant personalities: In some teams, there may be individuals with dominant personalities who tend to overshadow others. To address this, I actively encourage quieter team members to share their thoughts and ideas, and ensure that everyone has an equal opportunity to contribute.
By being aware of these challenges and implementing appropriate strategies, I strive to overcome them and ensure effective decision-making in the Scrum team.
Follow-up 4
How do you adapt your strategies to different team dynamics?
Adapting strategies to different team dynamics is crucial for effective decision-making. Here's how I do it:
Understanding team dynamics: I take the time to understand the unique dynamics of each team. This includes observing how team members interact, identifying any existing power dynamics, and understanding the communication styles and preferences of team members.
Flexibility in decision-making processes: I adapt the decision-making processes to suit the specific needs and dynamics of the team. For example, if a team is more comfortable with informal discussions rather than formal meetings, I may facilitate decision-making through informal conversations.
Tailoring communication approaches: I adjust my communication approach based on the team dynamics. For example, if a team has members who are more introverted, I may provide opportunities for individual reflection and feedback rather than relying solely on group discussions.
Building trust and psychological safety: I prioritize building trust and psychological safety within the team. This helps team members feel comfortable expressing their opinions and ideas, even if they differ from the majority.
By adapting strategies to different team dynamics, I ensure that decision-making processes are effective and inclusive, leading to better outcomes for the Scrum team.
4. How do you handle decision-making when there is a tight deadline?
Tight deadlines in Scrum are a signal worth examining, not just a condition to manage. Scrum's time-boxed Sprints are designed precisely to prevent the "deadline crunch" pattern by creating a regular cadence of inspection and adaptation. When a deadline creates real pressure, my first question is whether the constraint is external and fixed—a regulatory date, a launch commitment—or whether it's a symptom of scope that wasn't managed well earlier.
For genuine external deadlines, my approach:
Surface the constraint early and make it visible. The team can't make good decisions about trade-offs unless they understand the constraint. I bring it into Sprint Planning and Sprint Review explicitly.
Shift to a scope conversation, not a speed conversation. Asking the Developers to work faster is rarely the answer. The better question is: given the Sprint Goal and the time we have, what is the smallest increment that still delivers value? The Product Owner's accountability is to order the Product Backlog in a way that puts the highest-value, highest-risk items first—so that even if the deadline hits early, what gets shipped is the most important work.
Protect the Definition of Done. Under deadline pressure, teams are sometimes pressured to cut quality corners. Shipping work that doesn't meet the Definition of Done is not a completed Increment—it's deferred work that accumulates as technical debt. I hold this line and help the team explain the trade-off to stakeholders in concrete terms.
Make decisions with the information available, empirically. Scrum is built on empiricism: transparency, inspection, and adaptation. When information is incomplete, the team makes the best available decision, creates the increment, and inspects the outcome. Waiting for certainty under a deadline is not an option, and that's fine—the framework anticipates it.
The Retrospective after a deadline sprint is particularly valuable. It's where the team examines what the deadline pressure revealed about their process and makes concrete improvements to the Sprint Backlog or ways of working.
Follow-up 1
Can you provide a specific example?
Certainly! In a previous project, we had a tight deadline to deliver a new feature. We needed to decide between two different approaches to implement the feature. To make a quick decision, I gathered the development team and discussed the pros and cons of each approach. We considered factors such as development time, complexity, and impact on the existing codebase. After a brief discussion, we decided to go with the approach that required less development time but still met the project requirements.
Follow-up 2
How do you balance the need for speed with the need for consensus?
Balancing the need for speed with the need for consensus can be challenging, but it's important to find a middle ground. I prioritize open communication and collaboration with the team to ensure that everyone's opinions and concerns are heard. However, I also understand that in some situations, a quick decision is necessary to meet the deadline. In such cases, I make sure to involve the key stakeholders and gather their input, but ultimately, I take responsibility for making the final decision.
Follow-up 3
What was the outcome?
The outcome of the decision-making process was successful in meeting the tight deadline. By making a quick decision and involving the relevant stakeholders, we were able to implement the necessary changes and deliver the feature on time. The chosen approach proved to be efficient and effective, and it met the project requirements.
Follow-up 4
How did the team react to the decision?
The team reacted positively to the decision. They appreciated the open communication and involvement in the decision-making process. Although there were differing opinions, the team understood the urgency of the situation and the need for a quick decision. They were supportive and worked together to implement the chosen approach. Overall, the team's reaction was collaborative and focused on meeting the deadline.
5. Can you describe a time when you had to make a decision without complete information?
This situation comes up constantly in Scrum, and the framework is actually designed for it. Empiricism—the foundation of Scrum—explicitly acknowledges that decisions will always be made with incomplete information. The Sprint itself is a short experiment: the team makes a hypothesis, builds an Increment, and inspects what they learn.
A concrete example: midway through a project, the team needed to decide whether to build a custom notification service or use a third-party provider. We had limited information about the third-party's reliability under load, and the team was split. Waiting to resolve the uncertainty wasn't an option—the Sprint Goal depended on the notification capability being available.
I facilitated a structured approach to the decision:
First, I asked the team to be explicit about what they knew, what they didn't know, and what the cost of being wrong would be in each direction. That forced the discussion away from opinion and toward risk.
Second, we identified whether the decision was reversible. In this case, using the third-party provider was relatively easy to reverse in a subsequent Sprint if it proved inadequate—which meant the cost of deciding quickly was low.
Third, we committed to a decision—the third-party provider—and agreed on a specific signal that would trigger a revisit (a failure rate threshold). That signal became part of the Sprint Backlog as an explicit monitoring task.
The outcome was good enough: the provider worked, and the team had built in the mechanism to detect if it didn't. The Retrospective surfaced one improvement—that we should have asked the Product Owner to bring this risk to stakeholders earlier rather than absorbing it entirely at the team level.
The point interviewers are looking for: a Scrum Master doesn't wait for certainty before facilitating a decision. They create a structured, time-boxed process, support the team in making a defensible call, and build in the inspection point to learn from it.
Follow-up 1
What would you do differently next time?
In hindsight, there are a few things I would do differently next time. Firstly, I would try to gather more information and insights before making a decision, even if it means delaying the decision-making process slightly. Secondly, I would involve more stakeholders in the decision-making process to get a broader perspective and avoid any blind spots. Lastly, I would document the decision-making process and the rationale behind the decision to have a reference for future projects.
Follow-up 2
How did you approach the decision-making process?
To approach the decision-making process, I gathered as much information as possible from the available resources. I consulted with the team members who were directly involved in the implementation and also reached out to subject matter experts for their insights. I analyzed the available data and considered the potential risks and benefits of each possible decision. I also considered the project constraints and the impact on the overall project goals.
Follow-up 3
What was the outcome?
The outcome of the decision was positive. Despite the lack of complete information, the decision I made turned out to be the right one. The new feature was successfully implemented within the given timeframe and it met the project requirements. The performance and user experience were not negatively affected as we had anticipated.
Follow-up 4
How did you communicate the decision to the team?
I communicated the decision to the team by organizing a meeting where I explained the situation and the reasons behind the decision. I shared the available information and the analysis that led to the decision. I encouraged the team members to ask questions and provide their input. I made sure to address any concerns or doubts raised by the team members and provided reassurance that the decision was made with careful consideration.
Live mock interview
Mock interview: Decision Making
- Read your scene and goals
- Talk it out; goals tick off live
- Get a score and stronger lines
Your voice and your AI key never touch our servers; the key stays in this browser and is sent only to Google. Only your round scores are saved to track progress.