Often I was asked how to apply Scrum to Portfolio Management, here are a few ideas to help you get started with a more Scrum-Friendly Profilo Management approach.

From Project to Product

Traditional Portfolio Management is built around projects, and Scrum is built around Products, so it would be good to start with the basic unit and see the difference…

-

Success

Time

Purpose

Changes

Development

Team

Project

Scope, Time, Budget

Definite start date and end date

Cost-Saving

Changes should be controlled

One-Off

Resource Utilization

Product

Value(Revenue/ time saved), User Adoption, etc.. Scrum.org/EBM

On-going as long as there is value

Value-Generating

Changes are expected and embraced

Continuous

Dedicated Full-time team

I went through a similar journey, we started with some projects, very often a part-time team, and moved around to different projects a lot, later we started to think more about the Product, how it generates value in either revenue or internal savings, or makes customers/employee happier, or improve quality or time-to-market. Gradually, we move to a more long-term team structure with long-term objectives.

Scrum-Friendly Team Structure 

Their differences are huge and affect how we think about portfolios and teams. Traditionally companies would start the project, gather the related people, finish the project, and disband the team, that way, a lot of know-how and chemistry is lost. Transforming from project to product, we form a long-term stable Product-oriented team, you can start small to test out the product-market fit and team fit, once there is initial success, then gradually build up the team.

During the process, you may have to re-think your current product or service approach to build a long-term team, typically team structures are….

1. A Single Product team (typically more common for B2C or B2B Products when there is revenue ), that can be supported by one Scrum team or multiple Scrum Teams

2. A Service  - it can be internal, a Business to Enterprise (B2E) team serving multiple business units, it can also be a data governance, data science or analytics or marketing/operation service serving multiple internal business units.

3. A Platform, eco-system, or whatever you call it, provides value to multiple internal or external clients, but still from a Scrum perspective, that’s just the same as a Product.

Within the process, you may have to focus and pause/stop some projects that are of lower priority, or have a smaller chance to deliver value, and if the value is insignificant.

Budget Management 

Traditionally when we think about budget, we often think about throwing x amount of money into a project, waiting for a few months, and praying for success, usually there are lots of surprises, and possibly delays. Then we have to throw more money into it and yet we don't know whether we would be successful, with that thinking, our approach would be to control and cut down on the cost and hopefully reduce delay.

The new approach with Scrum is that we have something in return every sprint, (our increment), so every sprint, maximum for 1 month, shorter for 2 weeks, 1 week even a few days can shorten the feedback loop. With every single sprint, we have some potential return, from a budget perspective, Product Owners can work with stakeholders and decide whether to invest more money or not, if there’s no value, maybe it’s ok to cancel the product. If that’s proven value, the Product Owners can work with management to decide whether it’s a positive Return on investment to invest more or keep investing. From a Budget perspective, that way it’s more flexible, we can risk manage every sprint, and decrease / freeze / increase investment if needed. 

Summary

Portfolio Management applies to Scrum / Products can be quite different and maybe even quite disruptive for teams, we do not suggest you to go to a big-bang approach, and suddenly change all to Scrum / Product Oriented teams, instead, we suggest you try it bit by bit, you can still use projects to fund the team, but hopefully, the measurement/team structure is more product-focused.