Who is the Portfolio Scrum Master and what role do they play within Scrum Projects, Programs and Portfolios? Scrum is well Documented for small Projects. It is reasonably easy to present Scrum to a small-medium sized IT Business. Larger Companies have found adopting Scrum to be a bit of a challenge. This is especially the case for Companies with an established Project Management Office (PMO), Program Managers and several Portfolio Managers. The same goes for larger IT Projects that need 3 or more Scrum Teams.

Portfolio Scrum Master: Working to Scale

When adopting Scrum as an Agile Framework, it is advised that the Project has a Scrum Team of 5 to 9 resources. This gives the impression that it is only appropriate for small Projects. This is not the case. Scrum can be used for larger Projects too. The trick is to have multiple Scrums Teams Working on sub-Projects. These multiple Scrum Teams are kept in synchronisation by periodic joint Meetings. Utilizing a Meeting known as the “Scrum of Scrums”. A new hierarchy is needed to be presented for this which requires a Chief Scrum Master and Chief Product Owner. These two individual facilitate and co-ordinate the general Project.

Scrum Defined at Portfolio and Program Level

Lots of Companies practice Programme and Portfolio Management for comprehensive oversight of all their Projects. New Roles are required for Programmes and Portfolios, particularly:-.

• Program Product Owner.
• Program Scrum Master.
• Portfolio Product Owner.
• Portfolio Scrum Master.

Program and Portfolio Management are essentially “Command and Control” functions and are based upon a hierarchical Organisational structure. This conflicts with the democratic nature of Scrum Teams at a Project level.

Portfolio Product Owner.

• Delivers Value for Portfolios.
• Creates Business Justification for Portfolios.
• Provides Value Guidance for Programs.
• Approves Business Justification for Programs.

Program Product Owner.

• Delivers Value for Programs.
• Creates Business Justification for Programs.
• Provides Value Guidance for Projects.
• Approves Business Justification for Projects.

Product Owner (Voice of the Customer).

• Delivers Value for Projects.
• Creates Business Justification for Projects.
• Confirms Benefit Realization to Stakeholders.

Another significant difference is that the Product Owner and Scrum Master Roles in a Scrum are transient; the Product Owner in particular go back to their regular Jobs once the Project is over. As the Program and Portfolio Product Owner supervise numerous Projects, these Roles would be permament.

Portfolio Scrum Master: Portfolio and Program Artefacts.

In order to adhere to the Principles of Agile, Scrum lines up the Roles and activities at Portfolio and Program level with what takes place within a Scrum at Project level. In order to Manage these oversight levels, 2 brand-new Artefacts, which are consolidations of the Product Backlogs, have been defined, the Program and the Portfolio Backlogs. These 2 knowledge bases contain all the content of the secondary Project Product Backlogs. The Business rules for choosing if these User Stories are “Done” is the same; and there is a set of Acceptance Criteria that have actually to be satisfied prior to a Deliverable being accepted as complete.

Portfolio Scrum Master: Risk

Program and Portfolio Management can be utilized as vehicles for Risk Management. The approach recommended is bottom-up, where individual Scrum Teams report on a Risk recognised during the Daily Stand-Up Meeting or similar gathering (Sprint Review and Sprint Retrospective), and this Risk is passed up the reporting line. Risks can also be recognized at Program and/or Portfolio level that need to be cascaded downwards to Project level.

What is suggested for Risk Management in Risk-Mature Organisations is that Risk Management Responsibility is Managed at Program level. Risk Management Meetings are held at this level where Project Product Owners and the Portfolio Product Owner attend and contribute. The output from such a Meeting would be an updated Portfolio and Program Risk Register, which would include a column that suggests which Scrum Projects are affected by the Risk. This would remove the redundancy of having each Project Team running their own Risk Management Meetings and keeping their own Risk Registers. The Team member who raised the event could likewise be invited to the Meeting and take part in the Assessment and Mitigation activities. Someone who recognised a Risk is the most likely person to describe a Mitigation for it.

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

The disadvantage to moving the Risk Management to Program level is that the Scrum Team do not get the direct exposure to managing Risk that they would get if each Team runs Risk Management Meetings. They would, nevertheless, have more time to Develop the Product, which is their very first priority.

Portfolio Scrum Master: Implementing Scrum.

The choice to implement Scrum at these levels might take some time, as there are two possible approaches:-.

• Create the new Scrum Roles and integrate them into the present Programme and Portfolio architecture, OR.
• Redesign the Programme and Portfolio Management Organisational structure, replacing the existing Managers or transforming their Roles into their Scrum equivalents.

What is advised is that the new Scrum Roles do not change the Traditional Program and Portfolio Manager Roles, but Work in conjunction with the established Managers. The Product Owners can Manage the Quality of the Products and the Scrum Masters can deal with resourcing and Scrum compliance concerns. Experienced Scrum Masters and Product Owners could fill these new Roles and transfer the knowledge and skills to the PMO and the other Role-Players in the Programme and Portfolio space. The Scrum Master will have the Responsibility of convening Planning Meetings and other Meetings necessary at this level to satisfy the Requirements of Scrum. The Product Owner will establish the Program or Portfolio Product Backlog and train all those concerned in prioritizing and refining the Backlog, as well as building the contents. This is a Project on its own, and includes implementing the recommended processes to support the new approach.