HKSM

A concise, living plan that outlines activities, norms, and actions to develop and sustain a high-performing Scrum Team. Created when the team is formed and refined throughout the project, it guides collaboration, conflict resolution, skill growth, and onboarding. In SBOK, it is an output of forming the team and an input to planning, implementation, and retrospectives.

Key Points

• Output of forming the Scrum Team; input to Sprint and release-level planning and to team retrospectives.
• Captures working agreements, collaboration norms, skill growth actions, and onboarding steps.
• Supports conflict prevention and resolution through clear protocols and facilitation approaches.
• Reviewed in each Retrospect Sprint and adjusted as the team matures.
• Helps the Scrum Master plan coaching and remove impediments tied to team dynamics.
• Aligns with Definition of Done, but focuses on people and interactions rather than product quality criteria.

Purpose

The plan provides a structured approach to building trust, improving communication, and developing the capabilities needed for predictable delivery. It sets expectations for how the team collaborates within sprints and across releases, and how new members are integrated.

By making norms explicit, the plan reduces friction, shortens storming phases, and supports continuous improvement. It also informs resource needs such as tools, facilitation, and training.

Key Terms & Clauses

• Working agreements: core team norms for collaboration, focus time, and decision rules.
• Communication protocols: channels, response expectations, and escalation paths.
• Facilitation and conflict handling: techniques, roles, and when to involve the Scrum Master.
• Skill development and pairing: cross-training, mentoring, pairing/mobbing guidelines.
• Onboarding checklist: access, ceremonies, code standards, Definition of Done, and tooling.
• Team events and cadences: team-building activities aligned to sprints and releases.
• Measures and review cadence: qualitative feedback, team health checks, and review points in Retrospect Sprint.

How to Develop/Evaluate

1. Assess context: team size, skill mix, distribution, time zones, and product complexity.
2. Define goals: collaboration aims, learning objectives, and expectations for self-organization.
3. Draft working agreements: meeting etiquette, decision-making, and focus-time rules.
4. Plan activities: pairing schedules, knowledge-sharing, and periodic team-building events.
5. Set onboarding steps: access, environments, standards, and buddy assignments.
6. Specify metrics: brief team health checks and feedback loops tied to Retrospect Sprint.
7. Validate feasibility: confirm timeboxes, budget, and alignment with release and sprint calendars.
8. Review and adapt: inspect outcomes in retrospectives; update based on impediments and feedback.

How to Use

• Initiate - Form Scrum Team: produce the initial Team Building Plan as an output alongside team roster and training needs.
• Plan & Estimate - Commit User Stories / Create Sprint Backlog: use collaboration norms and pairing plans to inform realistic commitments and capacity assumptions.
• Implement - Conduct Daily Standup: apply communication protocols and conflict handling rules to keep the event focused and constructive.
• Implement - Scrum of Scrums Meeting (if scaled): align cross-team norms and share improvement actions that affect multiple teams.
• Review & Retrospect - Retrospect Sprint: evaluate team health measures; update activities, agreements, and onboarding steps.
• Support Impediment Log: log and address team-dynamic impediments discovered while applying the plan.

Example Snippet

Sample Team Building Plan elements for a new, partially distributed Scrum Team:

• Working agreements: 2-hour daily focus block per member; decisions by consent; cameras on for key ceremonies.
• Pairing: rotate pairs twice per week; one mentoring session per sprint for cross-training.
• Communication: Slack for async, 4-hour response window business hours; urgent issues via phone.
• Conflict protocol: raise in Daily Standup; if unresolved, 15-minute mediated chat with Scrum Master same day.
• Onboarding: access within 24 hours; DoD and coding standards walkthrough; assign a buddy for the first sprint.
• Health check: 3-question pulse in Retrospect Sprint; track trends and actions.

Risks & Tips

• Risk: plan becomes ceremonial and ignored. Tip: keep it short, visible, and reviewed every sprint.
• Risk: over-prescription limits self-organization. Tip: set boundaries and intentions, not micromanagement.
• Risk: no budget or time for activities. Tip: timebox lightweight actions inside the sprint and align with release milestones.
• Risk: misalignment with Definition of Done and coding standards. Tip: reference quality agreements and update onboarding steps.
• Risk: remote friction. Tip: define explicit communication windows, tools, and handover practices.
• Risk: new joiners struggle. Tip: maintain a living onboarding checklist and assign buddies.

PMP/SCRUM Example Question

While forming a new Scrum Team, the Scrum Master wants to reduce early conflicts and speed up onboarding. Which artifact should be created as an output and then used in Sprint Planning and Retrospectives to guide collaboration norms and improvement actions?

1. Definition of Done.
2. Release Plan.
3. Team Building Plan.
4. Product Increment.

Correct Answer: C — Team Building Plan

Explanation: The Team Building Plan is produced when the team is formed and used as input to planning and retrospectives to set norms, onboarding steps, and improvement activities. The other options do not focus on team development and collaboration practices.