HKSM

Organization-level guidelines, standards, and advisories issued by the Scrum Guidance Body to promote consistent, compliant Scrum practices across teams. They serve as governance inputs to Scrum processes and are updated as outputs when the body refines policies, templates, and baselines.

Key Points

• Organization-wide guidance created by the Scrum Guidance Body (SGB) to align teams.
• Acts as both an input to many Scrum processes and an output when recommendations are updated.
• Covers policies, standards, templates, compliance needs, and tailoring rules.
• Intended to enable consistency without blocking agility.
• Often includes baselines for Definition of Done and quality practices.
• Should be versioned, transparent, and periodically improved based on feedback.

Purpose

The purpose is to provide lightweight governance that helps multiple Scrum teams work consistently and meet regulatory or organizational standards. It reduces rework and risk by offering clear, reusable guidance that teams can adopt and tailor.

These recommendations align product, program, and portfolio efforts while leaving room for empirical adaptation at the team level.

Key Terms & Clauses

• Policy statement - What is required or recommended and why.
• Scope - Who and what the guidance applies to (teams, products, tools).
• Mandates vs guidelines - What is mandatory, what is suggested, and what is team choice.
• Tailoring rules - How teams may adapt, with examples and any guardrails.
• Compliance mapping - Links to regulations, security, privacy, and quality controls.
• Templates and checklists - Standard artifacts (e.g., user story format, DoD checklist).
• Version control and change history - Effective date, owner, and approval path.
• Escalation and exceptions - How to request deviations or propose updates.

How to Develop/Evaluate

1. Assemble cross-functional representatives (Scrum Masters, Product Owners, developers, compliance, security, architecture).
2. Gather regulatory and organizational needs, plus recurring issues from retrospectives and audits.
3. Draft minimal, outcome-focused guidance with clear mandates and tailoring options.
4. Provide supporting templates and checklists to reduce ambiguity.
5. Pilot with 1-2 teams, collect feedback during sprints and reviews.
6. Finalize, version, and publish with an accessible repository and owner.
7. Evaluate quarterly or per release using metrics (defect trends, lead time, compliance findings) and update as needed.

How to Use

Use the recommendations as an input when performing SBOK processes such as Create User Stories, Approve-Estimate-and-Commit User Stories, Create Tasks, Estimate Tasks, Create Deliverables, Demonstrate and Validate Sprint, and Retrospect Sprint.

• Product Owner - Applies standards to Product Backlog structure, acceptance criteria, and prioritization policy.
• Scrum Master - Coaches teams on applying mandatory clauses and facilitates exceptions or updates.
• Developers - Use DoD baselines, coding standards, security practices, and test templates during implementation.
• Release and compliance stakeholders - Verify that releases meet organization and regulatory expectations.
• SGB - Treats feedback from teams and audits as input to update the recommendations (output of SGB work).

Example Snippet

Sample organization-wide recommendation elements:

• User stories must include acceptance criteria; Gherkin is recommended for critical workflows.
• Definition of Done baseline: code review completed, unit tests at 80% coverage, security scan passed, and product documentation updated.
• All PII must be masked in non-production environments; follow Data Handling Checklist v2.1.
• Teams may tailor the DoD if mandatory compliance checks remain intact; changes must be documented in the team wiki.
• Exception requests use the SGB Exception Form and require approval within 3 business days.

Risks & Tips

• Risk: Overly prescriptive guidance slows teams. Tip: Keep it minimal and outcome-oriented.
• Risk: Stale policies cause noncompliance. Tip: Timebox reviews and assign clear ownership.
• Risk: Conflicts with team practices. Tip: Publish tailoring rules and provide a fast exception path.
• Risk: Poor discoverability. Tip: Centralize access in a single repository with version tags.
• Risk: Command-and-control misuse. Tip: Emphasize enablement and learning, not policing.
• Risk: Inconsistent adoption. Tip: Integrate guidance into DoD, DoR, and checklists used in ceremonies.

PMP/SCRUM Example Question

A company wants all Scrum teams to follow a minimum Definition of Done and meet data privacy rules. During Sprint Planning, what should the Scrum Master advise the team to use as the primary input?

1. The Product Roadmap created by the Product Owner.
2. The Scrum Guidance Body Recommendations published by the organization.
3. The Sprint Retrospective notes from the previous sprint.
4. The team's historical velocity chart.

Correct Answer: B — The Scrum Guidance Body Recommendations published by the organization.

Explanation: SGB recommendations provide organization-level standards such as DoD baselines and compliance requirements, which are inputs to Sprint Planning. The other options offer useful context but do not define mandatory governance guidance.