How to Get a Job For Project Managers

Learn how to write resume and interview

Leadership for Project Managers

Learn how to lead and drive project success.

Project Management with AI

From a beginner to project management professional.

Agile Project Management and SCRUM with AI

Learn to run Scrum and Agile with AI.

Scrum Guidance Body Recommendations

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.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Eight teaching sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Build the Sprint Reporting System, Not Another Prompt

AI Systems with Claude is our own course for Scrum Masters and Agile Project Managers, taught against one running project across eight teaching sections. You build five working systems and keep them: the sprint report machine, the retro intelligence system, the stakeholder comms engine, the backlog health monitor, and the risk and dependency tracker. Direct from HK School of Management, not on Udemy.

See What Is Included