Free Scrum Professional Scrum Master III PSM-III Exam Questions

An example of unethical behaviour by a Development Team member in Scrum is knowingly delivering low-quality or non-secure software while being aware of the potential negative impact on users, stakeholders, or the organization. Such behaviour contradicts the ethical expectations embedded in Scrum and violates multiple Scrum Values.

For instance, a developer may intentionally ignore known defects, security vulnerabilities, or technical debt in order to finish work faster or appear more productive. Releasing software that is known to be insecure or unstable places end-users at risk and misrepresents the true state of the product. This undermines Commitment to quality and Courage, as the individual avoids addressing difficult issues or raising concerns.

Another unethical example is withholding important information from the Scrum Team or stakeholders. This may include hiding risks, downplaying impediments, or not being transparent about progress or challenges. Such behaviour violates Openness and damages trust, which is essential for empiricism and effective collaboration.

Unethical behaviour may also be expressed through failing to support team members. For example, refusing to help others, dismissing or disrespecting colleagues' opinions, or working in ways that harm team cohesion contradicts the Scrum Value of Respect. Scrum expects team members to collaborate and support each other in achieving the Sprint Goal.

Finally, going against agreements made by the Scrum Team, such as ignoring the Definition of Done or agreed working agreements, is unethical. This damages accountability and can mislead stakeholders about the quality and completeness of the work.

In Scrum, team structure significantly impacts the ability to deliver value. Two commonly discussed structures are component teams and feature teams. Although the Scrum Guide does not explicitly define these terms, it strongly favors the characteristics of feature teams through its definition of a Scrum Team.

Component teams are organized around technical specialties or system components, such as database, frontend, or middleware teams. Their work typically represents partial contributions to a product feature, requiring coordination and handoffs across multiple teams to deliver customer value. As a result, component teams often introduce dependencies, delay integration, and struggle to produce a usable Increment independently within a Sprint.

Feature teams, in contrast, are organized around delivering complete product features or Product Backlog Items. They are cross-functional and possess all the skills required to design, build, test, and deliver a ''Done'' Increment of value. Feature teams minimize dependencies and can independently deliver customer-facing functionality each Sprint.

From the Scrum Guide perspective, feature teams align more closely with Scrum principles:

The Scrum Guide states that Scrum Teams are cross-functional, which directly supports feature teams and challenges component team structures.

Scrum requires each Sprint to produce a usable Increment. Feature teams can meet this expectation, while component teams usually cannot without reliance on other teams.

Scrum is based on empiricism (transparency, inspection, and adaptation). Reduced dependencies in feature teams improve transparency and enable faster inspection and adaptation.

Scrum emphasizes value delivery and accountability. Feature teams maintain clear ownership of outcomes, whereas component teams fragment accountability across technical silos.

While component teams may exist due to legacy structures or technical constraints, they represent organizational impediments rather than an ideal Scrum implementation. From a Professional Scrum Master III perspective, moving toward feature teams supports agility, improves value delivery, and better enables Scrum as defined in the Scrum Guide.

How an organization discusses, plans, and decomposes work is inevitably reflected in the software it produces. When technical systems are decomposed into elements such as activities, workflows, functions, features, or components, these decomposition choices have a direct and systemic impact on Scrum Teams, especially in scaled Scrum environments.

1. Decomposition Influences Team Structure (Conway's Law)

In scaled projects, system decomposition often drives how teams are formed. When work is decomposed along technical components or functions, organizations tend to create specialist or component teams (e.g., front-end teams, back-end teams). This results in:

Increased dependencies between teams,

More handoffs and coordination,

Reduced autonomy of individual teams.

Scrum, however, expects teams to be cross-functional and capable of delivering usable Increments independently. Component-based decomposition therefore hinders effective Scrum adoption at scale.

2. Effect on Value Delivery and Transparency

Scrum relies on frequent inspection of integrated, working product Increments. When decomposition focuses on small technical parts rather than end-to-end features or capabilities, teams may deliver partial outputs instead of usable value.

This negatively affects:

Transparency, as progress is reported through intermediate artifacts rather than working software,

Inspection, since stakeholders cannot meaningfully evaluate value,

Adaptation, because feedback is delayed until integration occurs.

In scaled Scrum, this often results in ''almost done'' work that is not truly Done.

3. Feature-Oriented Decomposition Supports Scrum

Scrum scales more effectively when system decomposition emphasizes vertical slices of value, such as features or capabilities, rather than horizontal technical layers. Feature-oriented decomposition enables:

Cross-functional teams,

Reduced dependencies,

Faster feedback cycles,

Independent delivery of value by each team.

This approach aligns with Scrum's expectation that every Sprint produces a usable Increment.

4. Impact on Integration and Risk

Decomposition decisions strongly affect integration frequency. Poor decomposition increases integration complexity and encourages late integration, which raises risk and reduces learning.

In Scrum---especially at scale---integration must happen early and often. Unintegrated work is not considered Done, and delayed integration undermines empiricism by hiding real system behavior until late in development.

5. Learning and System Optimization

When Scrum Teams work on complete features rather than isolated components, they gain broader insight into:

Customer needs,

System-wide trade-offs,

End-to-end product behavior.

This shared understanding improves decision-making and supports continuous improvement at the system level, rather than local optimization within silos.

When Developers raise the lack of certain knowledge or expertise as an impediment, the Scrum Master must address the situation in a way that reinforces Scrum principles, especially cross-functionality, empiricism, and self-management, while also supporting value delivery.

First, it is essential to verify whether this is truly an impediment. In Scrum, an impediment is something the team cannot resolve on its own. As a Scrum Master, I would facilitate a discussion with the Developers and, if appropriate, the Product Owner to inspect whether the expertise is genuinely required to achieve the desired outcome. In some cases, the scope or approach can be adapted, or the Product Backlog Item can be refined so that alternative solutions are viable. This conversation may reveal that the need for specialized knowledge is less critical than initially assumed.

Second, if the expertise is indeed necessary, the Scrum Master should encourage the team to address the issue as a cross-functional Scrum Team. Scrum expects teams to have, or acquire, all skills needed to deliver value. Therefore, I would ask the Developers how they could learn or acquire the necessary knowledge themselves. Possible options include allocating time for learning, research, training, experimenting, or building a prototype. These activities can be planned as part of the Sprint Backlog and support long-term team capability.

Third, the Scrum Master can help the team make effective use of outside expertise without undermining self-management. During Sprint Planning or refinement, the team may consult internal or external experts to gain insights, validate approaches, or reduce uncertainty, while still retaining ownership of the work and the Sprint Backlog.

Finally, if none of these options resolve the impediment, the Scrum Master has a responsibility to help the organization support the Scrum Team. This may involve facilitating access to expertise from elsewhere in the organization or, if necessary, from outside the organization. The Scrum Master does not solve the problem personally but works to remove organizational barriers so the team can proceed.