HKSM

A lightweight, living artifact that describes how the Scrum Team and stakeholders share information, including audiences, channels, frequency, responsibilities, and escalation paths. Created early in Initiate and refined through retrospectives, it serves as an input to planning and review activities to keep communication timely and transparent.

Key Points

• Created early in Initiate and maintained throughout the project as needs change.
• Acts as an input to Release Planning, Sprint Planning, Backlog Refinement, Daily Standup, and Sprint Review.
• Defines who communicates what, to whom, when, and through which channels.
• Product Owner leads external stakeholder communication; Scrum Master facilitates the process and removes communication impediments.
• Encourages transparency through information radiators and shared tools instead of heavy documentation.
• Must address time zones, language, compliance constraints, and confidentiality where relevant.

Purpose

The plan aligns expectations about communication so that stakeholders receive the right information at the right time with minimal friction. It reduces noise, prevents delays in decisions, and supports rapid feedback loops, which are essential for empirical Scrum.

It connects stakeholders to Scrum events and artifacts, clarifies response times and escalation paths, and enables consistent messaging across sprints and releases.

Key Terms & Clauses

• Audiences and roles: Product Owner, Scrum Master, Developers, customers, business sponsors, compliance, operations.
• Cadence: Sprint length, Sprint Review schedule, Backlog Refinement frequency, release communication timing.
• Channels and tools: chat, video, email, dashboards, wikis, issue trackers, information radiators.
• Content and artifacts: product backlog updates, increment status, release notes, burndown/burnup summaries, impediment logs.
• Responsibilities: who sends updates, who invites to events, who approves external announcements.
• Response targets and availability: office hours, time zones, holidays, language preferences.
• Escalation paths: how and when to escalate impediments, risks, or urgent decisions.
• Compliance and confidentiality: required notices, data sensitivity, stakeholder access levels.

How to Develop/Evaluate

Start during Initiate by gathering inputs such as the Project Vision, stakeholder list, organizational policies, and tooling standards. Co-create the plan with the Product Owner, Scrum Master, key stakeholders, and the Scrum Team.

• Map information needs to Scrum events and artifacts (e.g., who attends Sprint Review and who receives release notes).
• Select channels that maximize transparency and speed while respecting constraints (time zones, security).
• Define responsibilities for sending updates, maintaining dashboards, and managing invitations.
• Set cadences, response expectations, and escalation routes for impediments and urgent decisions.
• Keep it short and visible; pilot for one sprint and refine based on feedback.
• Evaluate each sprint in the Retrospective: what worked, what caused noise or delay, and adjust accordingly.

How to Use

Use the plan to guide invitations, updates, and artifact visibility during each sprint. Share it widely and link it in team workspaces and calendar invites.

• Release/Sprint Planning: confirm stakeholder touchpoints and update calendar cadences.
• Daily Standup: reinforce that it is for Developers; define how observers may attend silently if allowed.
• Sprint Review: invite the defined audiences; send a summary and next steps within the agreed timeframe.
• Backlog Refinement: establish a recurring slot and feedback channel for stakeholders to propose changes.
• Impediments: route blockers to the Scrum Master immediately and escalate per the plan if external help is needed.
• Compliance: follow the specified channel and cadence for required reports or approvals.

Example Snippet

• Audience: Business stakeholders — Sprint Review, every 2 weeks, 60 minutes, via video; summary within 24 hours by Product Owner.
• Audience: Compliance — Monthly report, email and repository link; read-only access to dashboards; owner: Product Owner.
• Channel/Artifacts: Product backlog and Sprint backlog visible in the tracker; burndown auto-published daily.
• Response Targets: Team responds to stakeholder questions within 1 business day; urgent items flagged in chat with @ScrumMaster.
• Escalation: Impediments unresolved in 24 hours escalated by Scrum Master to sponsor per RACI.
• Time Zones: Core hours 14:00–17:00 UTC; asynchronous updates outside core hours; recordings shared within 12 hours.

Risks & Tips

• Risk: Over-documenting creates delay and low adoption. Tip: keep it to one page and link to living dashboards.
• Risk: Plan goes stale as stakeholders change. Tip: review and update in every Sprint Retrospective.
• Risk: Using the plan to bypass Scrum events. Tip: reinforce that events remain the primary feedback forums.
• Risk: Time zone and language barriers reduce engagement. Tip: offer asynchronous summaries and clear response windows.
• Risk: Confidential updates leak. Tip: define access levels and protected channels for sensitive content.
• Risk: Single point of failure for communications. Tip: assign backups and automate regular updates.

PMP/SCRUM Example Question

A new regulatory stakeholder cannot attend the Sprint Review due to time zones but requires monthly status and release notes. What should the Scrum Master and Product Owner do next?

1. Extend the Daily Standup to include the stakeholder so they can hear updates directly.
2. Update the Communications Plan with the stakeholder’s cadence and channel, then share it and adjust invites.
3. Ask Developers to send daily emails to the stakeholder with progress and tasks.
4. Create an additional weekly ceremony solely for compliance reporting.

Correct Answer: B — Update the Communications Plan with the stakeholder’s cadence and channel, then share it and adjust invites.

Explanation: The Communications Plan is the appropriate artifact to document and align on audiences, frequency, and channels. It is created early and updated as needs change, guiding how information flows without altering core Scrum events.