The Product Owner in God Mode: Ceremonies, Backlog Grooming, and the ITIL Service Catalogue Connection
Vote for this post
Click the arrows to vote • 1 vote per logged in user
Login to Vote
The Product Owner in God Mode: Ceremonies, Backlog Grooming, and the ITIL Service Catalogue Connection
In Scrum, the Product Owner is not a project manager with a fancy title. The role carries something closer to sovereign authority over the product — the right to decide what is built, in what order, and why. When that authority is exercised well, the Scrum team moves with purpose and clarity. When it is exercised poorly, or not at all, the backlog becomes a wish list and the sprints become noise.
The Product Owner's "God Mode" Authority
The Scrum Body of Knowledge (SBOK™ Guide) is unambiguous about where product authority lives. The Product Owner is the single person accountable for the Prioritized Product Backlog — the ordered, living list of everything the team will ever build. No one else sets that order. No one else decides which user stories represent the highest value. The Scrum Master facilitates; the Development Team delivers; the Product Owner decides what is worth delivering.
This is sometimes called "god mode" in informal Scrum conversations, and while the term is tongue-in-cheek, the intent is serious. The Product Owner must have the organisational authority to make binding decisions about the product without running every choice through a committee. A Product Owner who cannot say "we are building this next, not that" is not a Product Owner — they are a message-carrier between leadership and the team, and that structure produces exactly the kind of delay and confusion that Scrum is designed to eliminate.
The authority is total within its domain, and the domain is the backlog. The Product Owner does not tell the team how to build — that belongs to the Scrum Team. The Product Owner tells the team what to build and in what order, and that is enough power to shape everything the team produces.
The Product Owner holds singular authority over the Prioritized Product Backlog — the single source of truth for everything the team will build.
The Ceremonies the Product Owner Owns
The Product Owner does not sit outside the Scrum ceremonies and receive status reports. They are an active participant in all of them, and in several they carry specific obligations that cannot be delegated. The Scrum Master facilitates the structure; the Product Owner supplies the content and the decisions.
Sprint Planning SBOK: Plan & Estimate
The Product Owner opens Sprint Planning by presenting the top of the Prioritized Product Backlog — the stories that represent the highest current value. They articulate the Sprint Goal: the single outcome the sprint should achieve. The Development Team then selects the work they can commit to completing within the sprint, and together the Product Owner and team negotiate what the sprint will contain. The Product Owner must be present, must be prepared, and must be able to answer questions about the stories in the top of the backlog on the spot. Arriving at Sprint Planning with poorly defined stories wastes the entire team's time.
Daily Standup SBOK: Execute — Conduct Daily Standup
The Daily Standup is primarily a ceremony for the Development Team and the Scrum Master. The Product Owner attends but does not run it. Their role is to listen, to understand whether progress is tracking toward the sprint goal, and to surface any changes in priority that the team needs to know about. A Product Owner who turns the Daily Standup into an interrogation session is misusing the ceremony.
Sprint Review SBOK: PMC — Demonstrate & Validate Sprint
The Sprint Review is arguably the Product Owner's most important ceremony. At this event, the Development Team demonstrates working software against the stories committed in Sprint Planning. The Product Owner's job is to accept or reject each completed story against the Definition of Done and the acceptance criteria that were agreed before the sprint began. Stakeholders attend the Sprint Review, and the Product Owner represents the product — fielding feedback, capturing new requirements, and making visible decisions about what the feedback means for the backlog going forward.
Sprint Retrospective SBOK: PMC — Retrospect Sprint
The Retrospective belongs primarily to the Scrum Team and the Scrum Master — it is a safe space for honest reflection on how the team worked together. The Product Owner may attend, but their presence changes the dynamic if they are not careful. Some teams prefer the Retrospective to be a team-only space. The Product Owner should follow the Scrum Master's lead on this and resist the temptation to use the Retrospective to re-litigate backlog decisions.
Backlog Grooming (Refinement) SBOK: Execute — Groom Prioritized Product Backlog
This is the ceremony that most separates well-run Scrum teams from struggling ones — and it is where the Product Owner's work is most intensive. It is covered in detail below.
Backlog Grooming: The Two Levels That Must Not Be Confused
Backlog Grooming — also called Backlog Refinement — is not a single activity. It operates at two distinct levels, and confusing them produces a backlog that is either strategically vague or technically premature. The Product Owner owns both levels but plays a different role in each. The SBOK™ process map shown below names these precisely: Create Prioritized Product Backlog and Groom Prioritized Product Backlog sit in the Initiate and Execute phases respectively, while the Scrum Team's technical engagement happens across the Plan & Estimate processes — Approve, Estimate and Commit User Stories, Create Tasks, Estimate Tasks, and Create Sprint Backlog.
The SBOK™ Guide process map: the Product Owner's backlog work spans Initiate (Create Prioritized Product Backlog) and Execute (Groom Prioritized Product Backlog), while the Scrum Team engages across the full Plan & Estimate column before each sprint.
Before the sprint begins, the Scrum Team and Product Owner must agree the Definition of Done and what will be demonstrated at the Sprint Review — this is non-negotiable.
Level 1 — Product Owner: Strategic Grooming
- Maintains the full backlog from the top user and business perspective — the Create Prioritized Product Backlog process in the Initiate phase
- Writes and refines user stories — who wants it, why, and what it must do
- Prioritises by business value, risk, and dependency
- Removes stories that no longer represent value
- Adds new stories from stakeholder feedback, Sprint Reviews, and the CSI Register — feeding the Groom Prioritized Product Backlog process in Execute
- Ensures the top 2–3 sprints of the backlog are always story-ready
- Owns the Release Planning Schedule — the external commitment to stakeholders, established in the Initiate phase alongside Conduct Release Planning
Level 2 — Scrum Team: Technical Refinement
- Applies technical minds to the top of the backlog — the Approve, Estimate and Commit User Stories process in Plan & Estimate
- Breaks large stories (epics) into sprint-sized user stories via Create User Stories
- Creates and estimates tasks — the Create Tasks and Estimate Tasks processes in Plan & Estimate
- Identifies technical dependencies, blockers, and risks the PO may not see
- Challenges and clarifies acceptance criteria — what must actually be true for a story to be Done?
- Agrees the Definition of Done for each story and the sprint overall
- Finalises the Create Sprint Backlog — the committed scope the team will deliver and demonstrate at the Sprint Review
The critical distinction is this: the Product Owner grooms the backlog from the perspective of the user and the business. They know what problem each story solves and why it matters. The Scrum Team grooms the top of the backlog from the perspective of delivery. They know what it will take to build, what can go wrong, and whether the acceptance criteria are clear enough to code against. Neither perspective is sufficient alone. Both are required for a sprint to begin cleanly.
The Definition of Done Is Not Decoration
One of the most important outputs of Backlog Grooming is an agreed Definition of Done for each story entering the sprint. This is not a formality. The SBOK™ Guide is clear that the Definition of Done makes the word "done" mean the same thing to the developer, the tester, the Product Owner, and the stakeholder. Without it, stories cross the Scrumboard's Done column carrying invisible disagreements — and those disagreements surface at the Sprint Review as surprises. The Scrum Team defines how Done is achieved. The Product Owner defines what Done must demonstrate to the business. Both must be in that conversation.
What Must Be Agreed Before the Sprint Starts
The Scrum Master's role in Sprint Planning and Backlog Grooming is to facilitate the process — to ensure the right conversations happen, that timebox discipline is maintained, and that nothing enters the sprint without sufficient definition. But the content of those conversations is driven by the Product Owner and the Scrum Team together. The following must be settled before the sprint begins:
| Agreement | Owner | Why It Matters |
|---|---|---|
| Sprint Goal | Product Owner (with team input) | The single outcome the sprint is trying to achieve — the North Star that guides decisions when scope needs to flex mid-sprint |
| Acceptance Criteria per Story | Product Owner writes; Scrum Team validates | The specific, testable conditions under which the Product Owner will accept the story as complete at the Sprint Review |
| Definition of Done | Scrum Team defines; Product Owner approves | The shared quality standard that applies to every story — what "done" means in terms of coding standards, testing, documentation, and demonstration-readiness |
| Sprint Demonstration Plan | Product Owner & Scrum Master jointly | What will be shown at the Sprint Review, to whom, and against which acceptance criteria — prevents the Review being a surprise for anyone in the room |
The Product Owner as Owner of the ITIL Service Catalogue
Here is where Scrum and ITIL v3 converge in a way that is rarely discussed explicitly — but is enormously powerful for IT organisations operating both frameworks in parallel.
In ITIL v3, Service Catalogue Management (Process 7 in Service Design) is responsible for maintaining the definitive, approved list of all live IT services — what each service does, who it serves, what its SLAs are, and how it connects to the broader service portfolio. The Service Catalogue is the organisation's promise to the business: these are the services we operate, to this standard, for these users.
ITIL v3 Context — The Service Catalogue and the CSI Register
In the ITIL v3 Service Lifecycle, the Service Portfolio contains three zones: the Service Pipeline (services in development), the Service Catalogue (active live services), and Retired Services (decommissioned). The Product Owner who owns a business function owns, in effect, the Service Catalogue entries for that function — the live services their users consume, governed by SLAs negotiated in Service Level Management.
The CSI Register — the Continual Service Improvement log that captures every improvement opportunity identified across the lifecycle — feeds directly into the Product Owner's backlog. In ITIL v3, CSI Registers are most effectively managed per business function rather than as a single monolithic IT register, because the context and priority of improvements differ radically between functions. This aligns precisely with the Scrum model: the Product Owner for a business function maintains the backlog of improvements, enhancements, and new capabilities for that function's services.
This connection is explored in detail in the ITIL v3 Service Lifecycle Reference published on this site — a full interactive reference covering all five lifecycle phases, the CSI model, and the relationship between Service Portfolio Management, Demand Management, and Continual Improvement.
In practice, this means that a Product Owner who manages, say, the Finance function's IT services is not just the owner of the sprint backlog. They are the owner of the Finance Service Catalogue — the authoritative record of every IT service the Finance department consumes, including its availability targets, its SLAs, and its improvement pipeline. Their Prioritized Product Backlog is the working form of the Finance CSI Register: ordered by value, ready to sprint, and connected to the live service commitments their users depend on.
This is a powerful framing because it extends the Product Owner's authority and accountability beyond the sprint cadence into the ongoing governance of service quality. A sprint that delivers a working feature is a Service Transition event in ITIL terms. The Product Owner who signs off the Sprint Review's Definition of Done is performing the same function as the business user who signs off UAT before go-live. The language differs; the governance intent is identical.
Scrum Backlog
The ordered, prioritised list of everything the team will build — maintained by the Product Owner from the user's perspective. Every item represents value to be delivered.
ITIL CSI Register
The formal record of every service improvement opportunity identified across the lifecycle — per business function in effective ITIL v3 practice. Fed by incidents, SLA breaches, user feedback, and strategic goals.
Service Catalogue Entry
The live, governed definition of a service — its utility, its warranty, its SLA, and its owner. The Product Owner who manages a business function's backlog is the effective custodian of that function's Service Catalogue.
The Scrum Master's Role in Making All of This Work
The Scrum Master does not own the backlog, does not set priorities, and does not decide what is Done. What the Scrum Master does — and does critically — is ensure that the ceremonies run on time, that the grooming conversations happen before they are needed, and that the collaboration between the Product Owner and the Scrum Team is productive rather than adversarial.
In organisations where the Product Owner is a senior business stakeholder with many competing demands, the Scrum Master often carries the practical burden of scheduling and preparing the grooming sessions, reminding the Product Owner when stories at the top of the backlog lack sufficient definition, and escalating when the backlog is not sprint-ready in time for planning. This is not the Scrum Master overstepping — it is the Scrum Master doing their job. The framework will not run itself.
Signs the Product Owner — Scrum Master Partnership Is Working
- Backlog Grooming happens on a regular cadence — not just the night before Sprint Planning
- The top 2–3 sprints of the backlog are always story-ready with clear acceptance criteria
- The Definition of Done is agreed before the sprint begins, not argued during the Sprint Review
- The Sprint Review demonstration plan is prepared in advance — no surprises for stakeholders
- The CSI Register (or equivalent improvement log) is connected to the backlog — ITIL improvements become sprint stories
- The Product Owner can answer acceptance criteria questions in Sprint Planning without deferring to someone else
- Stories enter Sprint Planning without acceptance criteria — the team negotiates them under time pressure
- The Definition of Done is vague or inconsistent between sprints
- The Sprint Review reveals that what was built does not match what the Product Owner wanted
- The backlog grows continuously without any stories being removed, split, or deprioritised
- ITIL service improvement actions sit in a separate register that never connects to the sprint backlog
The Bottom Line: Authority With Accountability
The Product Owner's "god mode" is not a licence to be a dictator. It is a mandate to make decisions — quickly, clearly, and in service of the users whose problems the product exists to solve. That mandate comes with equal accountability: if the backlog is poorly groomed, the sprints will fail. If the acceptance criteria are vague, the Sprint Reviews will be arguments. If the Product Owner does not maintain the connection between the live service catalogue and the improvement backlog, the organisation will deliver features while service quality quietly deteriorates.
The ITIL v3 framework gives us the language for what the Product Owner is governing: a portfolio of live services, an improvement register, and a pipeline of future capabilities. Scrum gives us the engine for delivering those improvements at pace, in a disciplined cadence, with the whole team aligned to a shared definition of done. Neither framework is sufficient alone. Together — with a capable, empowered Product Owner at the centre — they describe something close to a complete model for managing IT service quality in a modern organisation.
One Backlog to Rule Them All
The Product Owner who understands both Scrum and ITIL v3 holds a single, unified view of their domain: the live services their users depend on, the SLAs those services must meet, the improvement opportunities identified in the CSI Register, and the sprint backlog that turns those improvements into working software. These are not four separate things. They are one thing, viewed from four different angles. The Product Owner's job is to hold all four angles simultaneously — and to ensure that every sprint moves the whole picture forward.
Further Reading
This article draws on the Scrum Body of Knowledge (SBOK™ Guide) published by SCRUMstudy and the ITIL v3 Service Lifecycle framework. The ITIL v3 Service Lifecycle Reference — covering all five phases, the CSI model, and the Service Catalogue — is published on this site as an interactive reference tool.
Leave a Comment