HKSM

A lightweight, living agreement that describes how the Scrum Team and stakeholders collaborate, including channels, cadences, decision rules, availability, and escalation paths. It is created early and refined throughout the project to enable fast, transparent, and coordinated work across roles and locations.

Key Points

• A concise, living working agreement for team collaboration, revisited each Sprint.
• Usually produced during Initiate (Form Scrum Team) and refined in Review and Retrospect.
• Captures channels, cadences, decision rules, availability, time zones, and escalation paths.
• Owned by the Scrum Team; Product Owner and Scrum Master steward visibility and adherence.
• Serves as an input to Daily Standup, Scrum of Scrums, backlog refinement, and dependency management.
• Complements the Communications Plan by focusing on day-to-day teamwork and responsiveness.

Purpose

The plan sets clear expectations for how people coordinate work, make decisions, and share information so the team can self-organize and reduce delays. It minimizes collaboration waste such as handoff gaps, slow responses, and unclear ownership.

Within SBOK flow, it acts as an output from early setup in Initiate and as a guiding input across Plan and Estimate, Implement, and Review and Retrospect processes.

Key Terms & Clauses

• Channels and Tools: e.g., chat, video, issue tracker, wiki, and when to use each.
• Cadences: Daily Standup time, backlog refinement, Sprint Planning, Review, Retrospective.
• Decision Rules: Product Owner decisions on priority; team decisions on technical implementation; consent or majority rules when needed.
• Availability and Core Hours: time zones, overlap windows, on-call rotas, holiday plan.
• Responsiveness SLAs: expected response times for chat, email, and pull requests.
• Escalation Path: impediment routing to Scrum Master, then to management or Scrum of Scrums.
• Dependency Contacts: named points of contact for external teams/vendors.
• Information Radiators: where to find the product backlog, Definition of Done, metrics, and dashboards.

How to Develop/Evaluate

1. Gather inputs: Project Vision, stakeholder list, org policies, compliance constraints, and tooling standards.
2. Facilitate a team workshop (Scrum Master) to co-create a one-page draft with the Product Owner and key stakeholders.
3. Define channels, cadences, decision rules, availability, dependencies, and escalation in clear, testable statements.
4. Validate with adjacent teams and leadership where integration or approvals are needed; publish in a visible location.
5. Set review cadence in each Sprint Retrospective and track simple measures like response time, meeting attendance, and lead time for decisions.

Evaluation criteria:

• Clarity and brevity (ideally one page with links to details).
• Team buy-in and visibility to all stakeholders.
• Alignment with enterprise policies and security/compliance needs.
• Coverage for distributed teams and cross-team dependencies.
• Actionability with measurable expectations.

How to Use

During Initiate and Plan and Estimate, use it to agree on refinement cadence, response expectations for user story clarifications, and availability of SMEs. In Implement, apply it to run Daily Standups on time, manage asynchronous updates, and route impediments effectively.

In Review and Retrospect, inspect collaboration outcomes and update the plan. In multi-team environments, reference it during Scrum of Scrums to coordinate dependency contacts, sync times, and escalation paths.

• Input to Create User Stories and backlog refinement for fast feedback loops.
• Input to Estimate and Commit processes to ensure the right people are reachable when needed.
• Guide for Conduct Daily Standup, resolve impediments, and coordinate with external stakeholders.
• Support onboarding by giving new team members a clear collaboration playbook.

Example Snippet

• Channels: Chat #team-alpha for quick questions; issues in Jira; urgent items by phone.
• Cadences: Daily Standup 09:30 UTC; Refinement Tue 14:00 UTC; Scrum of Scrums Wed 15:00 UTC.
• Decisions: Product Owner final on priority; team decides implementation; tie-break via consent after 15 minutes.
• Availability: Core hours 13:00–17:00 UTC; PR review within 24 hours; story clarification within 4 business hours.
• Escalation: Blockers to Scrum Master within 2 hours; unresolved items raised in Scrum of Scrums.
• Dependencies: Payments team contact Jane D.; API vendor support via vendor-portal link.

Risks & Tips

Risks

• Overly detailed or rigid plan that slows adaptation.
• Stale content not reviewed in Retrospectives.
• Lack of stakeholder buy-in or visibility outside the team.
• Unrealistic response time targets leading to burnout.
• Ignoring time zones, accessibility, or compliance requirements.

Tips

• Keep it short, link to details, and post it where the work happens.
• Make expectations measurable and adjust with data from flow metrics.
• Include cross-team contacts to streamline dependency management.
• Reconfirm cadences and availability whenever team composition changes.
• Align with Definition of Done and code review policies to reduce handoff friction.

PMP/SCRUM Example Question

A Scrum Master is helping a newly formed, distributed team agree on communication channels, meeting times across time zones, who makes which decisions, and how to escalate blockers. Which artifact should be created and made visible to all?

1. Release Plan.
2. Collaboration Plan.
3. Sprint Backlog.
4. Impediment Log.

Correct Answer: B — Collaboration Plan

Explanation: The Collaboration Plan defines channels, cadences, decisions, and escalation for day-to-day teamwork. The Release Plan focuses on timing of releases, the Sprint Backlog lists work for the Sprint, and the Impediment Log tracks blockers but does not define how people collaborate.