Scrum Guidance Body Recommendations

From the Agile Thoughts Blog
This blog represents everything agile. Agile thoughts, issues, concerns, experiences, etc. I want to share and provide an outlet for the agile mindset. "Don't just do agile, be agile".

About this Blog


Recent Posts

Implementing Programs in Scrum

Regression Testing in Scrum

Planning for Uncertainty

Task Estimation with Scrum

Scrum Guidance Body Recommendations

Categories: Agile, Guidance, Scrum

The Scrum Guidance Body (SGB) typically consists of a group of professionals that define the set of standards that pertain to quality, government regulations, and other important organizational considerations. The standards are developed to provide guidance for the Product Owner, Scrum Mater and the Scrum Team. The SGB also is responsible for capturing Scrum Best Practices for use by all Scrum projects within an organization. Decision-making at the project level is not supported by the SGB; rather it provides guidance and/or the consulting foundation for all organizational project related levels (i.e. portfolio, program, and project). The Scrum Team is free to utilize the SGB as they need advice. Recommendations from the Scrum Guidance Body should be used on Scrum projects to ensure of the proper alignment of the project vision and process compliance to the standard and guidelines that have been established by the Body. Although the SGB is an important role, it must be understood that the Body is optional.

Scalability Recommendations

Scalability refers to the ability to adapt to any type of expansion. For Scrum, it means that a single Scrum Team can be scaled for larger projects by means of multiple teams. The Guide to the Scrum Body of Knowledge (SBOK Guide) has provided specific steps that support Scrum’s ability to be scaled and applied on large projects. Scalability in Scrum can be applied at three levels: Projects, Programs and Portfolios. The process begins with the Scrum of Scrum (SoS) meetings that support harmonization between multiple Scrum Teams. A representative from each of team provide feedback regarding their team’s progress, issues confronted and synchronization activities. The frequency of the SoS meeting is based on recommendations from the SGB, complexity level, project size and dependencies between the teams. Other recommendations include co-location and face-to-face communication among the Scrum team. As many of us may have experienced, co-location is sometimes very difficult to achieve. Companies often use distributed teams that work in different time zones and a variety of geographies. Regarding scaling for large projects, geographically dispersed team use chats, social media, video conferencing and other virtual communication practices.

Large Project Considerations

With projects that create large components, it is important to understand the role of multiple Product Owners and the way that multiple Scrum Teams work together. We will now discuss the inputs that are necessary for creating large project components in Scrum. Basically, the role of the Product Owner stays for same for small and large projects. The difference is that for large projects, the PO will not make daily decision a priority. Instead, the PO provides input and recommendations to the Chief Product Owner. Stakeholder interactions are distributed between all Product Owners and each one continues to work with their designated team. Role and responsibilities are captured in the Product Owners Collaboration Plan. Large project planning often results in recommendations to revise or improve the Scrum Guidance Body recommendations. If the body accepts the proposed modifications or additions, they will be added as updates to the SGB documentation. Figure 1 outlines the workflow for the creation of the large project components.

Figure 1. Create Large Project Components – Data Flow Diagram

Chief Product Owner

The Chief Product Owner is responsible for making daily business decisions on large projects. This role is responsible for the coordination of work for multiple Product Owners. With feedback from the POs, the Chief PO is responsible for the preparation and maintenance of the Prioritized Product Backlog, which is used as the source of work for the Product Owners and their Scrum Teams. Finally, the Chief PO takes care of the final deliverable for the projects. Lastly, each PO for the Scrum Teams is responsible for only the component and features that are developed by their assigned Scrum Teams.

Project Vision

The project vision clarifies the business need for the project. This statement should not be specific and needs to have room to be very adaptable. The reasons behind this flexibility are because it is very probable that the project could be based on suppositions that could change as the project progresses. The project vision must be able to accommodate changes and it should focus on the problem and NOT on the solution.

Chief Scrum Master

The Chief Scrum Master has the responsibility for communicating information and managing dependencies between the Scrum Teams on large projects. Collaboration is required among the Scrum Team via the Scrum of Scrums (SoS) meetings. One of the main responsibilities of the Chief Scrum Master is to remove impediments and fostering a productive environment for the Scrum Teams. This role also collaborates with the Chief Product Owner, Scrum Masters, and Product Owners to establish a list of components and resources needed across all Scrum Teams. As expected, the Chief Scrum Master is expected to facilitate all ceremonies that exceed the responsibilities of a single Team Scrum Master. There is also consistent interfacing with the Program Scrum Master to make sure that there is the proper association of the large project with the goals and intentions of the related program.

Large Project Environments

For large projects, it is important to determine the number and types of environments needed for a large number of Scrum Teams to accomplish their work during their Sprints. These categories of environments include but are not limited to testing, development, work locations, resources or applicable procedural borders required for the Scrum Teams.

Definition of Done

The SGB generally defines and documents the Definition of Done. The “Done” criteria represent a set of rules that will be applied to all user stories in a specific Sprint, including but not limited to the following:

  • Team Reviewed
  • Unit Testing Completed
  • Quality Testing Completed
  • All Defects Corrected
  • Demo Successful
  • Documentation Completed for each user story


SCRUMstudy. (2016). A Guide to the Scrum Body of Knowledge (SBOKTM Guide.), 3rd Edition

SCRUMstudy. (2017). Scalability of Scrum. Retrieved from

SCRUMstudy. (2017). Inputs Required for Creating Large Projects in Scrum. Retrieved from

SCRUMstudy. (2017). What are Done Criteria? Retrieved from

Posted on: September 09, 2018 12:16 AM | Permalink

Comments (9)

Please login or join to subscribe to this item
I'm yet to to see a Scrum Guidance Body in any organization. Perhaps it is covered under some other governance body, PMO etc. The extent to scrum "guidance" is usually at the Scrum Master or Scrum Coach level. Although if it is seriously adopted into the organization, it can become part of the organizational standard for projects, thus could have some governing body guiding it.

Interesting. Ive never heard of Chief Scrum Master position before.

Rami and Sante:

A Scrum Guidance Body is like Scrum Alliance or ScrumStudy. These organizations are not typically outside organizations.


The Chief Scrum Master is the same as a "Release Train Engineer" in the Scaled Agile Framework practice.

Interesting post. Thanks for sharing !

Very interesting, thanks for sharing

There are other scaling frameworks. It is interesting to know about SBOK!

Please Login/Register to leave a comment.


Music is the medium. Passion is the message.

- Herbie Hancock