Implementing Scrum Programs

Scrum Programs represent a collection of related projects. The objective of a program is to produce business results as they have been identified in the Program Vision Statement. The Prioritized Program Backlog includes Product Backlogs for every project within the program. Scrum at the Program level includes five (5) high-level processes.

Create Program or Portfolio Components

This process requires that the Program Product Owner, along with key stakeholders identify the common components and resources that are needed for the Scrum Programs. To be clear, key stakeholders at the program level should include the sponsors (project or program levels), and senior officials. In addition, the “Minimum Done Criteria” is established and the key stakeholders are pinpointed. The company’s vision and mission are very important at the project level. They are even more important at the program and portfolio levels. Both programs and portfolios need to be propelled by the mission and vision of the organization. This practice institutes the unity of the effort for every person in the organization.

The Scrum Guidance Body (SGB) recommendations are especially important at the program and portfolio levels. This is because adequate guidance is required where there is a large number of projects. A Communication Plan is important at this level because it outlines how information will be distributed to stakeholders, the organization, portfolios and programs. This plan needs to authenticate how and when communication will occur and what will be the methods of communication that will be used. Finally, the program needs to provide direction and contribution to the communications plan for each individual project within the program.

Review and Update Scrum Guidance Body

The Scrum Guidance Body (SGB) members include experts in Scrum, carefully chosen Scrum Masters, Product Owners and Development Team members of all ranks. The number of members within the Body should be limited to ensure that it remains pertinent and does not inadvertently becomes inflexible. During this process, the SGB recommendations are reviewed by the members of the Body and updated if they have been considered to be necessary. Changes in the membership of the SGB are also tackled. It is important to understand that the SGB must also adhere to regulations. This includes all pertinent Federal, Local, State or industry regulations that the program or portfolio is required to follow. Any User Stories that are produced to meet regulations within a specific time frame should be included in the Portfolio or Program Backlog.

Create and Prioritize Program or Portfolio Backlog

The Prioritized Program Backlog contains the requirements for the program and its significances. Program-level deliverables and their acceptance is accomplished in the projects under the program. The “Done” or “Acceptance” requirements for each Product Backlog User Story can be outlined at the Program Level. This means that Projects are required to follow the Program requirements, but also have the flexibility to add its own requirements as well. During this process, the Program or Portfolio Backlog is developed, revised and sustained. The Scrum Guidance Body Recommendations can be made during this process and the completion deadlines may be altered based on changed requirements and the development of the projects in the program or portfolio.

Coordinate Program or Portfolio Components

At the program or portfolio level, there is coordination among projects in order to manage dependencies. In addition, shared impediments are addressed and best practices are distributed across projects. Scrum Guidance Body recommendations occur as needed. Possible dependencies at the Program level include but are not limited to the following:

1. Dependencies amongst the releases
2. Having the same release dates for associated projects
3. Dependencies with associated features

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

Potentially Shippable Deliverables from each of the related projects within the program are the inputs for coordination at the program or portfolio levels. When the Sprints from each project end, product increments are completed. User Stories included in the product increments have satisfied the “Definition of Done” and their designated “Acceptance Criteria”. As the Sprints are completed, this would mean that project projections pertaining to deadlines provide information required to properly deal with the dependencies between the projects. Impediments from each of the projects can impact other projects in the scrum program. This suggests that Impediment Logs need to be shared amongst the projects or other programs.

Scrum Programs: Retrospect Program or Portfolio Releases

The Retrospective at the Program or Portfolio level is very similar as the one conducted at the Project Level. The main difference is that these meetings are conducted less frequently than those at the Project level. The Program or Portfolio Product Owner and stakeholders convene to retrospect the program or portfolio release. Lessons Learned are captured, discussed and the hope is that they lead to actionable improvement in future releases. Program-level retrospectives often result in suggestions or feedback to the SGB. If these suggestions or are accepted, this results in updates to the SGB.

Whenever Scrum is used to manage projects within a Scrum Program or Portfolio, the recommendation is the Agile principles are followed. It is a well-known fact that in order to be successful at the program level with Scrum, small adjustments may be made to the tools and the organizational structure.