PSM IIDemo

Unresolved technical debt can impede implementation work and reduce the amount a Development Team completes in a Sprint, lowering velocity. A team can also appear to increase short-term velocity by taking quality shortcuts and deferring the resulting technical work, but this creates debt that must later be addressed.

A Scrum Master establishes Scrum by helping people understand and apply Scrum theory and practice across the Scrum Team and organization. The role enables effective use of the Scrum framework and causes impediments to the Scrum Team’s progress to be removed. Product Backlog management belongs to the Product Owner, and Developers self-manage their work and capacity.

Scrum Team members respect one another as capable, independent people; being receptive to ideas and viewpoints reflects Openness; and constructively engaging with difficult interpersonal situations requires Courage. Repeatedly ignoring a teammate conflicts with Respect, Openness, and Courage.

A self-organizing Development Team determines how to accomplish its work and manages its internal collaboration. Team members exploring new possibilities and resolving their own internal conflicts demonstrate that autonomy and self-management.

The Sprint Review provides a formal opportunity for the Scrum Team and key stakeholders to inspect the Sprint outcome and discuss future adaptations, but Scrum does not limit stakeholder collaboration to that event. The Product Owner is accountable for effective stakeholder collaboration to maximize product value.

Only work that meets the Definition of Done is part of an Increment. An item that does not meet it must be excluded from the Sprint Increment and returned to the Product Backlog for future consideration; its remaining work can be estimated so the Product Owner can determine its subsequent ordering and treatment.

Product Owners engage stakeholders to understand changing needs and optimize product value; appropriate stakeholders participate in the Sprint Review to inspect outcomes and adapt future work. Product Owners remain accountable for effective Product Backlog management, but may collaborate with—and delegate related work to—knowledgeable Developers and others while learning the product domain.

A Product Owner is accountable for communicating the Product Goal and ordering Product Backlog items, and proposes how the product could increase value and utility in the current Sprint. Lack of authority over backlog decisions or ordering, or lack of objectives for upcoming Sprints, removes the product direction needed to select related work around a Sprint Goal. Scrum Teams are typically ten or fewer people; an eleven-person, functionally siloed Development Team can also impede the collaboration needed for focused Sprint planning.

Sprint Backlog scope may be clarified and renegotiated with the Product Owner as more is learned during the Sprint, without affecting the Sprint Goal. Removing or adjusting selected Product Backlog items promptly is therefore the appropriate adaptation. The Definition of Done should not be weakened to accommodate excess work.

Sprint 0 is not an official Scrum construct. A Sprint is expected to produce a valuable, usable Increment; preliminary setup or planning that does not meet that purpose is not a Scrum Sprint. Consequently, Scrum does not prescribe Product Owner activities for “Sprint 0.”

A cross-functional Scrum Team contains the capabilities needed to create value, but people who previously worked in separate component silos need time to learn shared collaboration, coordination, and end-to-end delivery practices. Newly formed teams commonly experience a temporary reduction in productivity while their working relationships and practices stabilize; nevertheless, integrating the work within one team can increase the ability to deliver business value by reducing handoffs and external dependencies.

Scrum Teams should develop the cross-functional capability needed to create value, so interested Developers can learn and take on work in Nicole’s domain. With several teams working on one product and experiencing dependencies, a suitable scaling approach may be worth evaluating. In the near term, expanding specialist capacity while the Product Owner orders work so teams can proceed with items that do not require Nicole is appropriate. Product Backlog ordering is the Product Owner’s accountability.

Focused work on a single Scrum Team generally improves productivity by avoiding the coordination and context-switching overhead of supporting several teams simultaneously. A well-structured Product Backlog can separate and order work to reduce dependencies, which often removes the need for Development Team members to work across multiple Scrum Teams during a Sprint. Scrum is intentionally incomplete and can be used as-is; scaling does not require customization of its core framework.

Budgeting and forecasting can be informed through frequent inspection of Sprint Increment outcomes to assess value delivered for the investment made. Funding may also cover a release comprising multiple Sprints, with each Sprint producing a shippable Increment. Scrum neither removes the need for budgets nor forbids fixed budgets.

Scrum events are timeboxed to establish regular opportunities for inspection and adaptation. Each Sprint produces a usable, potentially releasable Increment, which sets a clear delivery and quality boundary for the team. Scrum teams are cross-functional rather than organized into functional handoff phases; a mix of experience is beneficial but is not a prescribed Scrum boundary.

Management supports Scrum Teams by providing an enabling environment, organizational support, insights, and resources so teams can remain self-managing and continue progressing. Scrum does not assign management the role of monitoring Developers’ skills or velocity, or identifying underperforming individuals. The Scrum Guide states that Scrum Teams are empowered by the organization to manage their own work.

The Product Backlog is the transparent, ordered source of work for the Scrum Team, and progress information can be made transparent to stakeholders using empirically based projections such as burn-downs, burn-ups, or cumulative-flow trends. Sharing both the backlog and release-date projections provides a meaningful view of work, progress, and likely delivery timing; projections remain forecasts rather than commitments.

The Sprint Retrospective enables the Scrum Team to examine what is causing changes, understand their effect on product value and delivery, and identify improvements to how the team works together. The Scrum Master facilitates this collaborative inspection and adaptation rather than controlling changes or assigning one role authority over another.

A Scrum Master is accountable for the Scrum Team’s effectiveness, including coaching team members in self-management and helping remove impediments to the team’s progress. Checking whether the concern is surfaced in the Sprint Retrospective, and assessing the team’s comfort if it is not, supports transparent inspection. Facilitating a full-team session helps the self-managing team address the harmful interaction collaboratively and agree on better ways to work together.

Sprint work is forecast in an environment of complexity, so learning during the Sprint can reveal work that changes the Sprint Backlog. The Developers and Product Owner can clarify and renegotiate Sprint Backlog scope as more is learned, without changing the Sprint Goal. The Scrum Master should coach the Product Owner on this empirical, forecast-based approach rather than treating the entire Sprint Backlog as a guaranteed commitment.

A Scrum Team has three defined accountabilities: the Product Owner, the Scrum Master, and the Developers. “Development Team” is the terminology used in earlier Scrum Guide editions for the Developers accountability; Scrum does not define Business Analyst, Project Manager, Product Manager, or Stakeholders as Scrum Team roles.

Adding teams to a shared product creates coordination and integration work, including alignment on the shared Product Goal, Product Backlog, Product Owner, and Definition of Done. That initial overhead is likely to reduce the original team’s productivity.

Self-organization gives team members autonomy to determine how work is completed, which encourages creative problem-solving, personal accountability, and commitment to the team’s goals.

A Scrum Team includes one Product Owner and one Scrum Master, each with a distinct accountability. Their participation and availability affect the Scrum Team’s ability to maximize product value, establish Scrum effectively, and produce valuable outcomes.