HKSM

In SBOK, Scrum Core Team(s) are the Product Owner, Scrum Master, and Scrum Team members who collectively own delivery of product increments and operate the Scrum framework. As an ITTO, it represents the staffed team or teams formed during initiation and used as a constant input across planning, execution, review, and release processes.

Key Points

• Composed of the Product Owner, Scrum Master, and Scrum Team members.
• Formed during project initiation and used throughout all Scrum processes.
• Small, cross-functional, and dedicated to the product and sprint goals.
• Self-organizing team structure with clear accountability and decision rights.
• May scale to multiple coordinated teams with roles like Chief Product Owner and Chief Scrum Master.
• Acts as both an output of team formation and an input to backlog, planning, implementation, review, and release activities.

Purpose

The purpose of Scrum Core Team(s) is to provide a dedicated, empowered unit that can refine the product backlog, plan sprints, build increments, and inspect and adapt through reviews and retrospectives. The team structure ensures decisions are made close to the work, maximizing value delivery and responsiveness.

In multi-team efforts, several core teams synchronize to deliver on a shared product vision, reducing dependencies and aligning increments toward release objectives.

Key Terms & Clauses

• Product Owner: Owns value, orders the product backlog, clarifies acceptance criteria, and makes scope trade-offs.
• Scrum Master: Servant leader who coaches Scrum, removes impediments, and shields the team from disruptions.
• Scrum Team: Cross-functional developers, testers, designers, and engineers who build the Done increment.
• Core vs Non-core: Core are PO, SM, and Scrum Team; non-core include stakeholders, customers, vendors, and the Scrum Guidance Body.
• Scaling Roles: Chief Product Owner and Chief Scrum Master facilitate alignment across multiple core teams.
• Working Agreements: Team charter, Definition of Done, and Definition of Ready guide quality, flow, and collaboration.

How to Develop/Evaluate

Form the Scrum Core Team(s) during initiation by confirming a single empowered Product Owner, assigning a capable Scrum Master, and staffing a small, cross-functional Scrum Team with the skills to deliver user stories end to end.

• Identify skills needed from epics and initial product backlog to inform staffing.
• Confirm availability and dedication (ideally full-time) for stable velocity and predictable delivery.
• Establish working agreements, Definition of Done, and sprint cadence that suit time zones and dependencies.
• Set up collaboration tools, environments, and integration practices for continuous delivery.

Evaluate readiness with a lightweight checklist:

• All core roles filled with clear decision rights and authority.
• Coverage of required skills and environments to deliver a Done increment.
• Stable capacity for the next several sprints and an agreed cadence.
• Initial product backlog is ordered and refined enough for near-term sprints.

How to Use

As an output, Scrum Core Team(s) result from initiation activities that staff the Product Owner, Scrum Master, and Scrum Team. As an input, the team(s) enable:

• Backlog activities: creating, ordering, refining, and estimating epics and user stories.
• Planning: release planning, sprint planning, and capacity-based commitment.
• Implementation: daily coordination, development and testing, and impediment resolution.
• Inspection and adaptation: sprint reviews, retrospectives, and backlog adjustments.
• Scaling: Scrum of Scrums coordination across multiple core teams to manage dependencies.

The identification of Scrum Core Team(s) also links to other artifacts and logs, such as the Impediment Log, Definition of Done, and burndown/burnup charts, which the team updates and uses to guide delivery.

Example Snippet

A product initiative spins up three Scrum Core Teams. Each team has a dedicated Product Owner, a Scrum Master, and a cross-functional set of members capable of design, development, testing, and integration.

They share a unified product vision, coordinate via Scrum of Scrums for cross-team dependencies, and apply a common Definition of Done. The teams feed estimates to the release plan and run synchronized two-week sprints.

Risks & Tips

• Risk: Part-time or unstable membership reduces velocity and quality. Tip: Aim for dedicated staffing and minimize context switching.
• Risk: Skill gaps lead to incomplete Done increments. Tip: Staff for cross-functionality and invest in T-shaped skills.
• Risk: Oversized teams slow decision-making. Tip: Keep teams small and split work across multiple core teams when needed.
• Risk: Weak Product Owner authority causes backlog churn. Tip: Empower PO with clear decision rights and stakeholder access.
• Risk: Unclear working agreements create rework. Tip: Agree on a clear Definition of Done and revisit it during retrospectives.
• Risk: Poor cross-team coordination delays integration. Tip: Use Scrum of Scrums, integration cadences, and shared standards.

PMP/SCRUM Example Question

A new Scrum project is about to start backlog refinement, but the Product Owner has not been confirmed and only half the developers are assigned. What should the Scrum Master ensure happens first?

1. Begin estimation with whoever is available to avoid delay.
2. Ask stakeholders to pre-approve the top epics before staffing the team.
3. Form the Scrum Core Team by confirming the Product Owner, Scrum Master, and full Scrum Team.
4. Appoint a project manager to assign tasks until the team is staffed.

Correct Answer: C — Form the Scrum Core Team by confirming the Product Owner, Scrum Master, and full Scrum Team.

Explanation: Backlog refinement and estimation depend on an empowered Product Owner and a cross-functional, dedicated Scrum Team. Establishing the Scrum Core Team(s) is a prerequisite input to effective planning and delivery.