7.2 Cross-Functional Teams

7.2 Cross-Functional Teams

Scrum Guide 2020: Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

Cross-functionality is the companion of self-management under Developing People and Teams. A team that can decide how to work but lacks the skills to finish value still cannot produce a Done Increment. A team full of skills that is not allowed to self-manage will still stall under external direction. PSPO I expects you to reason about both—especially from a Product Owner ordering and collaboration viewpoint.

---

Definition: Skills to Create Value Each Sprint

Cross-functional means the team as a whole has the skills necessary to create value each Sprint. Skills depend on the product domain:

The Guide does not require that every individual is a full-stack generalist who can perform every skill equally. Specialization is allowed. What is required is that the team collectively can deliver valuable Done work without waiting forever on a permanent external specialist chain.

Cross-functional ≠ no specialists

---

No External Handoffs for a Done Increment (Ideal)

Ideally, creating a Done Increment does not require a multi-week handoff to an external design group, a separate test department that “accepts” after the Sprint, a release engineering queue outside the team’s control, or a documentation team that finishes next quarter.

Why this matters for empiricism:

• Transparency of Done: If “coding finished” is treated as success while testing lives outside the Sprint, the Increment is not transparent.
• Inspection of real product: Sprint Reviews inspect usable work, not partial components waiting on other groups.
• Adaptation of the Product Backlog: Learning comes from real user/stakeholder feedback on Done work, not from slideware about incomplete pieces.

Practical reality vs. ideal

Organizations sometimes have real constraints (shared compliance labs, rare specialized equipment, regulated release windows). Scrum does not pretend those vanish overnight. The direction of travel still matters:

1. Make dependencies visible in planning and forecasting.
2. Reduce permanent handoffs over time (bring skills into the team, automate, change org design).
3. Never redefine Done downward so unfinished work looks complete.
4. Order the Product Backlog so the team can still create the most valuable Done Increment possible given current constraints—not a pile of half-finished work that depends on three external queues.

---

Product Owner Implications for Ordering Work

The Product Owner does not magically create skills. The Product Owner does strongly influence whether selected work can be completed to Done by how they order, split, and clarify Product Backlog items.

1. Order work that can become Done

Selecting five high-value items that all require a missing specialized skill the team does not have—and will not have this Sprint—creates false forecasts. Better patterns:

• Order items the team can complete end-to-end soon, while investing in skill growth or staffing for larger capability
• Split large outcomes so a vertical slice is Done each Sprint rather than horizontal layers that cannot be released alone
• Make skill-related enabling work explicit on the Product Backlog when it is truly product work (for example, building test automation that unlocks faster value delivery)—not as a shadow side project disconnected from value

2. Prefer vertical value slices over component handoffs

Healthy ordering aims at outcomes users can experience (or inspect) as Done work each Sprint.

3. Clarify acceptance intent without dictating every how

Cross-functional teams still need a clear what/why from the Product Owner. Ambiguous items force the team to guess, which looks like skill failure but is often backlog failure. Clear intent enables designers, developers, testers, and operators on the team to collaborate on a shared outcome.

4. Do not use ordering to recreate functional silos

If the PO routinely orders “developer work” for one Sprint and “tester work” for the next as if they were separate teams, the organization is practicing waterfall in two-week boxes. Cross-functionality expects shared ownership of the Increment, not sequential mini-waterfalls labeled as Sprints.

---

Skill Gaps: PO + Scrum Master + Organization

When the team lacks skills needed for valuable Done Increments, treat it as a system problem:

Exam trap: Blaming Developers alone for not being “T-shaped enough,” while the Product Owner keeps ordering work that requires an absent skill and the organization refuses to change structure. Scrum’s answer is not blame; it is transparency and adaptation of team design and backlog strategy.

---

Multi-Team Products and Cross-Functionality

When multiple Scrum Teams share one product:

• They still share one Product Goal, one Product Backlog, and one Product Owner
• Each team should still be able to create integrated value; a shared Definition of Done (minimum) keeps “Done” meaningful across teams
• Cross-team dependencies should be reduced over time—not accepted forever as “the integration team will finish it later”

Product Owner ordering becomes more sophisticated: sequence work to reduce cross-team blocking, make integration risks visible, and still protect usable product increments rather than component completion metrics.

---

Cross-Functional + Self-Managing: One Capability

For Product Owners, the practical slogan is:

I order and clarify work that a complete, self-managing team can turn into a Done Increment—then I respect how they do it.

---

Scenario Patterns on PSPO I

Scenario A: “We need the UX team’s approval before any coding”

If UX is permanently outside the Scrum Team and blocks every Sprint, cross-functionality is weak. Better paths: include design skills on the team, embed designers, or change the workflow so design collaboration happens inside the team’s Sprint capability—not as an external gate after selection.

Scenario B: “QA Scrum Team tests what Dev Scrum Team builds”

This recreates sub-teams and handoffs. The Guide’s model is one cohesive Scrum Team (or multiple full teams on one product), not a chain of specialty Scrum Teams that only hand off partial work.

Scenario C: PO orders only features Developers like coding

If testing, documentation required for Done, or operational readiness are deferred indefinitely, the Increment is not Done. Cross-functionality includes all skills for value—not only the exciting feature layer.

Scenario D: Stakeholder demands a feature the team cannot complete safely this Sprint

PO response: be transparent about Done and skill/capacity reality; order a valuable slice that can be Done; place remaining work on the Product Backlog; do not declare partial work Done to please a demo.

---

Quick Self-Check

You are ready for exam items on this topic when you can state:

• Cross-functional = all skills necessary to create value each Sprint (team-level, not every person does everything)
• Ideal: Done Increment without external handoff chains
• PO lever: order and refine work completable to Done; prefer vertical value; keep DoD honest
• Skill gaps: backlog strategy + SM coaching + organizational design—not fake Done
• Cross-functionality pairs with self-management as one team capability system

Master those links and you will avoid both “everyone must be a generalist” overstatements and “handoffs are fine forever” understatements that the Scrum Guide does not support.