HKSM

Updated Scrum Guidance Body Recommendations are the latest organization-approved guidelines, checklists, and standards for using Scrum, refreshed with new learnings and improvements. They are produced as outputs from learning-focused events like Retrospect Sprint or Retrospect Project and then serve as inputs across future Scrum processes and projects.

Key Points

• Organization-level guidance curated by the Scrum Guidance Body (SGB), not team-specific notes.
• Produced or refined after learning events and change proposals, especially Retrospect Sprint and Retrospect Project.
• Version-controlled recommendations that can be advisory or mandatory depending on governance decisions.
• Act as inputs to many SBOK processes such as Create User Stories, Estimate Tasks, and Groom Prioritized Product Backlog.
• Intended to be lightweight, actionable, and supportive of team autonomy while promoting consistency.
• Examples include DoD templates, acceptance criteria formats, estimation scales, risk categories, and compliance checklists.

Purpose

The purpose is to capture organizational learning and propagate better ways of working across all Scrum teams. By standardizing high-value practices, teams reduce rework, accelerate onboarding, and avoid repeating known pitfalls.

These recommendations support scaling and governance without heavy bureaucracy. They provide common guardrails while allowing product-level flexibility.

Key Terms & Clauses

• Scrum Guidance Body (SGB) - A group or function that maintains organizational Scrum guidelines.
• Recommendation - A concise, testable practice or rule, e.g., a DoR checklist or estimation policy.
• Applicability - Scope of use such as all teams, a portfolio, or a specific domain.
• Advisory vs Mandatory - Whether a recommendation is guidance or a required standard.
• Owner and Version - Named steward and version number to manage updates and traceability.
• Effective and Review Dates - When the recommendation takes effect and when it should be re-evaluated.

How to Develop/Evaluate

1. Collect proposals from retrospectives, audits, pilots, and stakeholder feedback.
2. Screen proposals for clarity, value, and alignment with Scrum values and organizational goals.
3. Evaluate using criteria: reduces waste, improves flow/quality, measurable, minimal overhead, respects team autonomy.
4. Pilot with one or two teams when impact or uncertainty is high; gather metrics and qualitative feedback.
5. Decide advisory vs mandatory status; define applicability, owner, version, and effective date.
6. Publish in a centralized repository and communicate the change through Scrum Masters and Communities of Practice.

How to Use

Teams and roles consult the updated recommendations as inputs during day-to-day work and in formal SBOK processes.

• Initiate: Use to shape Create Project Vision and Develop Epic(s) with standard templates and risk categories.
• Plan and Estimate: Apply to Create User Stories, Approve-Estimate-Commit User Stories, Create Tasks, Estimate Tasks, and Create Sprint Backlog.
• Implement: Reference during Create Deliverables and Groom Prioritized Product Backlog for DoD/DoR and acceptance criteria patterns.
• Review and Retrospect: Feed new learnings back to the SGB during Retrospect Sprint and Retrospect Project to refresh the guidance.
• Release: Ensure Ship Deliverables aligns with any organizational compliance or documentation clauses.

Example Snippet

• Recommendation ID: SGB-AC-07 - Acceptance Criteria Format - Use Given-When-Then for all user stories; mandatory for regulated products; effective next sprint.
• Recommendation ID: SGB-DOD-03 - Definition of Done - Include peer review, unit tests at 80 percent coverage, and updated user documentation.
• Recommendation ID: SGB-EST-02 - Estimation Scale - Use Fibonacci 1-13 for story points; advisory for teams using cycle-time metrics.

Risks & Tips

• Risk: Over-standardization can stifle experimentation. Tip: Mark most items advisory and review mandatory ones frequently.
• Risk: Stale content reduces trust. Tip: Set review dates and track usage metrics to prune low-value guidance.
• Risk: Poor communication leads to uneven adoption. Tip: Announce updates via Scrum of Scrums and Scrum Master forums.
• Risk: Heavy templates slow delivery. Tip: Keep recommendations short, testable, and tied to measurable outcomes.
• Risk: Ignoring team context. Tip: Define clear applicability and allow justified exceptions with local working agreements.

PMP/SCRUM Example Question

During Retrospect Sprint, a team discovers a better Definition of Ready checklist that could benefit all Scrum teams in the organization. What is the best next step for the Scrum Master?

1. Update the team's working agreement and require other teams to adopt it immediately.
2. Add the checklist as a change request to the product backlog for the Product Owner to prioritize.
3. Submit the proposal to the Scrum Guidance Body to update and publish the organization-wide recommendations.
4. Create an impediment ticket and assign it to the PMO to enforce across teams.

Correct Answer: C — Submit the proposal to the Scrum Guidance Body to update and publish the organization-wide recommendations.

Explanation: Organization-wide practices are curated by the SGB. The improved checklist should be evaluated and, if approved, included in Updated Scrum Guidance Body Recommendations for future sprints.