PSM-III Exam Questions & Answers

When starting development of a brand new product with fifteen developers, forming effective teams is a critical early decision that significantly influences the success of product development. From a Scrum Master's perspective, multiple approaches are commonly used in practice. Each approach offers distinct benefits and drawbacks when evaluated against Scrum principles such as self-organization, cross-functionality, and value delivery.

1. Facilitating Teams to Self-Organize

One common approach is to facilitate the developers in forming teams themselves. This approach aligns strongly with Scrum, as the Scrum Guide states that Scrum Teams are self-managing and decide internally how best to accomplish their work.

Benefits:

Allowing teams to self-organize promotes empowerment, ownership, and accountability. Developers can use their existing knowledge of each other's strengths, weaknesses, and working styles to form balanced teams. This often increases motivation and psychological safety, both of which support high performance.

Hindrances:

For a new product, this process can be messy and time-consuming, especially if developers lack experience in forming effective teams. Teams may optimize for comfort or familiarity rather than cross-functionality, potentially leading to skill gaps or imbalanced teams.

2. Forming Two or Three Cross-Functional Feature Teams

Another common approach is to deliberately form two or three cross-functional feature teams, each containing all the skills necessary to deliver working product increments.

Benefits:

This approach closely matches how Scrum describes teams. Cross-functional feature teams can independently deliver integrated, ''Done'' Increments of the product, improving flow, reducing dependencies, and supporting empiricism. All necessary skills are available within the team, enabling faster inspection and adaptation.

Hindrances:

In the context of a brand new product, teams may not yet know which skills are actually required, making it difficult to form truly balanced teams upfront. Additionally, specialists may feel isolated and lose regular interaction with peers who share the same expertise across teams.

3. Forming Teams Based on Specialization (Component Teams)

A third approach is to organize teams according to technical specialization, such as front-end and back-end teams. These are often referred to as component teams.

Benefits:

This structure allows specialists to work closely together, enabling fast knowledge sharing, technical consistency, and deep expertise in specific components of the system. It can feel efficient, especially in the early stages of development.

Hindrances:

From a Scrum perspective, this approach significantly hinders value delivery. Component teams struggle to deliver complete, integrated features independently and introduce dependencies and handoffs. This makes it harder to produce a usable Increment each Sprint and is not how Scrum describes teams, even though it remains a commonly used strategy in many organizations.

Scrum Master Perspective and Conclusion

As a Scrum Master, my role is not to mandate a single team structure, but to coach and facilitate the organization toward structures that best enable Scrum. While all three approaches are seen in practice, Scrum clearly favors self-organizing, cross-functional feature teams because they maximize learning, transparency, and the ability to deliver value each Sprint.

Leadership plays a critical role in enabling self-organizing teams to succeed with Scrum. While Scrum Teams are self-managing, organizational leadership must create the conditions in which Scrum can thrive. This support is expressed through behaviors that reinforce empiricism, accountability, and continuous improvement, rather than through command-and-control practices.

First, leadership can help by actively supporting self-organization and Scrum adoption. This includes trusting teams to decide how they do their work, resisting the urge to micromanage, and reinforcing Scrum practices and values across the organization. Leaders who understand and support Scrum help protect teams from external pressure that undermines self-management.

Second, leaders should learn about Agile and Scrum and understand how to interact with Scrum Teams effectively. This knowledge enables leadership to engage in ways that are helpful rather than disruptive---for example, collaborating through Scrum events instead of bypassing the Product Owner or directly assigning work to Developers. Informed interaction strengthens alignment while preserving team autonomy.

Third, leadership must respect Scrum accountabilities, especially the authority of the Product Owner. Respecting Product Owner decisions on ordering the Product Backlog ensures clear accountability for maximizing value. When leadership overrides or bypasses the Product Owner, it undermines transparency, focus, and trust within the Scrum Team.

Fourth, leadership can significantly support teams by removing impediments that are beyond the team's control. These may include organizational policies, structural constraints, tooling limitations, or conflicting incentives. By actively addressing such impediments, leadership enables teams to improve their effectiveness and deliver value more consistently.

Finally, leadership should provide a clear organizational vision and strategy. A compelling vision and coherent strategy give Scrum Teams a sense of purpose and direction, helping them understand how their work contributes to broader organizational goals. This clarity supports better decision-making, alignment, and motivation at the team level without prescribing detailed solutions.

The Sprint Review is a key Scrum Event that directly enables empiricism, which is the foundation of Scrum. Empiricism is based on making decisions using what is known, observed, and learned, supported by the pillars of transparency, inspection, and adaptation. The Sprint Review operationalizes these pillars at the product level.

How the Sprint Review Enables Empiricism

First, the Sprint Review creates transparency by making the current state of the product visible. During the event, the Scrum Team presents a ''Done'' Product Increment that meets the Definition of Done. Stakeholders can see and often use the actual product rather than relying on reports or assumptions. This shared visibility ensures that discussions are grounded in reality.

Second, the Sprint Review enables inspection. The Scrum Team and stakeholders jointly inspect the Increment and assess progress toward product goals. The Developers provide context about what was delivered, what was not, and what challenges were encountered. This inspection is focused on outcomes and value, not individual performance.

Third, the Sprint Review supports adaptation. Based on the inspection and feedback, new insights emerge about customer needs, market conditions, risks, and opportunities. The Product Owner uses this information to adapt the Product Backlog, reordering items, adding new work, or refining existing items. This completes the empirical feedback loop by ensuring future decisions are based on the latest evidence.

Impact of Development Team Members Not Attending the Sprint Review

If some Developers are not present at the Sprint Review, empiricism is weakened.

First, transparency decreases. Developers possess critical, first-hand knowledge about implementation details, technical trade-offs, constraints, and risks. Without their presence, stakeholders receive an incomplete picture of the Increment and its implications.

Second, inspection becomes less effective. Stakeholders may ask questions about behavior, limitations, or quality that only Developers can accurately answer. The absence of Developers limits meaningful dialogue and reduces the quality of inspection.

Third, adaptation suffers. Decisions about what to do next---such as changes to scope, priorities, or technical direction---depend on accurate understanding. Without Developers participating, adaptations to the Product Backlog may be based on assumptions rather than evidence, increasing the risk of poor decisions.

Finally, excluding Developers undermines Scrum Values, particularly Respect and Openness, by treating the Sprint Review as a reporting event rather than a collaborative working session. This can lead to disengagement and reduced shared ownership of product outcomes.

Practicing 'zombie' or 'mechanical' Scrum refers to an approach where teams and organizations follow the rules and events of Scrum in a superficial manner, merely going through the motions, without embracing the underlying purpose, values, and principles of the framework.

In mechanical Scrum, teams conduct the required events, maintain the prescribed artifacts, and use Scrum terminology, but do so without focusing on value, learning, or outcomes. Scrum events become routine meetings rather than opportunities for inspection and adaptation. The Sprint Goal may exist on paper, but it does not meaningfully guide decisions. As a result, Scrum is reduced to a checklist of practices rather than a framework for solving complex problems.

This approach contrasts sharply with practicing ''Real'' Scrum, which is value-driven and goal-oriented. Real Scrum emphasizes delivering meaningful outcomes for customers and stakeholders, rather than simply completing tasks. Teams focus on achieving the Sprint Goal, maximizing product value, and understanding the impact of their work.

Furthermore, mechanical Scrum often ignores the Scrum Values. Without Courage, teams avoid difficult conversations; without Openness, problems are hidden; without Respect, collaboration suffers; without Commitment and Focus, teams optimize for activity rather than outcomes. This leads to stagnation and missed opportunities for improvement.

In contrast, Real Scrum recognizes that Scrum is a framework, not a rigid methodology. It intentionally leaves room for teams and organizations to discover and adopt additional practices that support empiricism, continuous improvement, and stakeholder satisfaction. These practices are chosen to reinforce Scrum's core values, not to replace them.

When a Development Team realizes mid-Sprint that it may not be able to deliver all planned Sprint Backlog Items, this situation should be handled through empiricism, not concern or blame. As a Scrum Master, I would reassure the team and guide them back to Scrum principles.

First, I would remind the team that in Scrum they do not commit to delivering all Sprint Backlog Items. Instead, the Scrum Team commits to doing their very best to achieve the Sprint Goal. Discovering additional work, complexity, or unknowns during the Sprint is expected, especially in complex product development. The Sprint Backlog is a forecast, not a fixed contract.

Second, I would help the team assess the impact of what they have discovered. If the newly discovered work is minor and the Sprint Goal is still within reach, the team can continue as planned while adapting the Sprint Backlog as needed. This reflects normal inspection and adaptation during the Sprint.

Third, if the impact is significant and threatens the Sprint Goal, the Development Team should have a focused discussion about if and how the Sprint Goal can still be met. This may involve changing the approach, reducing scope while preserving the Sprint Goal, or identifying alternative ways to deliver the intended value.

In such cases, the Product Owner should be involved in the conversation. Including the Product Owner increases transparency and enables faster value-based decision-making, such as re-negotiating scope or adjusting priorities while keeping the Sprint Goal intact. This collaboration ensures that adaptations are aligned with product value.