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 Development Team. The Scrum Guidance Body (SGB) is also responsible for capturing Scrum Best Practices. These best practices are for use by all Scrum projects within an organization.

Decision-making at the project level is not supported by the Scrum Guidance Body (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 Scrum Guidance Body (SGB) as they need advice. Recommendations from the Scrum Guidance Body should be used on Scrum projects to ensure the proper alignment of the project vision. Following these recommendations ensures process compliance to the standard and guidelines that have been established by the Body. Although the Scrum Guidance Body (SGB) is an important role, it must be understood that the Body is optional.

Scrum Guidance Body 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. 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 Scrum Guidance Body (SGB). It is also based on the 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 Product Owner will not make daily decision a priority. Instead, the Product Owner 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 Scrum Guidance Body (SGB) documentation.

Chief Product Owner

The Chief Product Owner is responsible for making daily business decisions on large Agile projects. This role is responsible for the coordination of work for multiple Product Owners. With feedback from the Product Owners, the Chief Product Owner 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 Product Owner takes care of the final deliverable for the projects. Lastly, each Product Owner for the Scrum Teams is responsible for only the component and features that are developed by their assigned Scrum Teams.

We found these books great for finding out more information on Agile Scrum:

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 is 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 proper association of the large project with the goals and intentions of the related program.

Scrum Guidance Body and Large Project Environments

For large projects, it is important to determine the number and types of environments needed for the 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.

Scrum Guidance Body Definition of Done

The Scrum Guidance Body (SGB) generally defines and documents the Definition of Done. The “Done” criteria represents 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