The SBOK roles the Scrum Guide does not name

A reader who learns the Scrum Guide's three accountabilities and then opens the SBOK® Guide's chapter on organisation meets a longer cast. There are core and non-core roles, a Voice of the Customer, a Scrum Guidance Body and a Chief Scrum Master. Without a map it feels as though the SBOK added bureaucracy. With a map it turns out that most of the extra roles name people the Guide mentions without labelling.

The Guide's cast

The Guide is minimal on purpose. The Scrum Team has one Scrum Master, one Product Owner and Developers, with no sub-teams or hierarchies. Outside it are stakeholders, who are mentioned throughout: the Product Owner represents their needs in the backlog, key stakeholders attend the Sprint Review, and the Scrum Master serves the organisation and helps remove barriers between stakeholders and teams. The Guide does not define or divide the stakeholder group.

The SBOK's two groups

The SBOK Fifth Edition divides roles into core and non-core.

Core roles are mandatory for producing the product, are committed to the project and are ultimately responsible for the success of each Sprint and of the project. They are the Product Owner, the Scrum Master and the Scrum Team, together called the Scrum Core Team. The SBOK stresses that none of the three has authority over the others. The Scrum Team in the SBOK sense is what the Guide calls the Developers, and the SBOK's Scrum Core Team is the Guide's Scrum Team.

Non-core roles are not mandatory and may not be continuously involved, but understanding them matters for some projects. They are business stakeholders, supporting services, vendors and the Scrum Guidance Body.

The non-core roles, one at a time

Business stakeholders is a collective term for customers, users and sponsors. The customer acquires the product, service or result. Users directly use it. The sponsor provides funding, support and other resources, and is the stakeholder to whom team members are accountable. The same person may fill more than one of these. The Product Owner is responsible for keeping them engaged. The Guide has none of these three terms, but its stakeholders and Product Goal assume them.

Supporting services are groups inside or outside the organisation that support or are affected by the project, such as training, logistics, marketing, finance and infrastructure. In the Guide's world they are simply the people the Scrum Team collaborates with.

Vendors are external individuals or organisations providing products and services outside the project organisation's core competence. The Guide says nothing about vendors. In practice a vendor either sits inside a team as Developers, which is simple, or outside it as a dependency, which needs managing.

The Scrum Guidance Body is optional but highly recommended in the SBOK. It consists of documents, experts or both, who define objectives for quality, regulation, security and other organisational parameters that guide the work of the Product Owner, Scrum Master and Scrum Team. It does not make project decisions. It consults and records good practice for all Scrum projects in the organisation. The Guide's nearest idea is the organisational Definition of Done, which all Scrum Teams must follow as a minimum.

The roles for larger efforts

When several teams work together, the SBOK adds core roles.

Chief Product Owner. For a large project with numerous Scrum Teams and several Product Owners, one person makes the day-to-day business decisions and coordinates the Product Owners. They maintain the overall Prioritized Product Backlog and are responsible for the final deliverables, while each team's Product Owner is responsible for the deliverables of that team. The Guide's approach to the same problem is to say that when a Scrum Team grows too large it should split into several cohesive teams that share one Product Goal, one Product Backlog and one Product Owner.

Chief Scrum Master. Responsible for collaboration among teams, usually through the Scrum of Scrums meeting. The SBOK says there is no hierarchy among Scrum Masters, and they are all peers.

Programme and Portfolio Product Owners and Scrum Masters. For programmes and portfolios, similar roles work at a higher level. The Program Product Owner defines strategic objectives and priorities for a programme, maintains a prioritised programme backlog and coordinates with other programmes. The Portfolio Product Owner makes decisions at the portfolio level and drives the prioritised portfolio backlog. The Program and Portfolio Scrum Masters are the counterparts for facilitating Scrum at those levels. None of these appears in the Guide, which stays at the level of one product and one team.

A worked example: a six-team project

This is an illustrative project. A bank is building a new payments platform with six teams. In Guide terms, the nearest model is one product with one Product Backlog and one Product Owner, with the teams sharing a Definition of Done and a Product Goal. A single Product Owner for six teams is a heavy job, so many organisations add helpers in practice.

In the SBOK model the same project has a Chief Product Owner who owns the combined backlog and decides cross-team priorities. Each team has its own Product Owner who looks after that team's part of it, and a Scrum Master. A Chief Scrum Master runs the Scrum of Scrums meeting, where the Scrum Masters share impediments and dependencies. Above the project, a Program Product Owner aligns it with two other projects that share a customer. A Scrum Guidance Body of two security experts and an architect publishes the security standards that every team must meet.

None of these roles contradicts the Guide. They are ways of splitting the workload of one accountability across several people, with a person at the top who decides. The danger in both models is the same: too many layers, and the accountability gets lost. Try to keep the number of layers small, and see the proxy Product Owner problem for what happens when decisions drift away from the role.

How to use the extra names

If you are reading the SBOK to learn how Scrum is applied in a larger organisation, the extra roles are useful vocabulary. If you are learning the framework, ignore them at first and learn the three accountabilities. If you are preparing to talk to a team that follows the SBOK, learn the translation: Scrum Team (SBOK) is Developers (Guide), Scrum Core Team (SBOK) is Scrum Team (Guide), and Business Stakeholders correspond to the people the Guide calls stakeholders.

The Agile Manifesto's principle that business people and developers must work together daily is a reminder that the sponsor, the customer and the user are not distant parties.

How to practise it

For a project you know, sketch the people who would hold each SBOK role, and mark any that nobody holds. Gaps often explain a recurring pain. In the simulator the Sponsor and Stakeholders appear as characters you work with, so you can see how a sponsor and a team interact.