Portfolio Management

(Presented as Part 3 in the Scrum Alone is Not Enough series.)

As mentioned in the introduction to the Scrum Alone is Not Enough series, Scrum is simply the framework and, to work best, other tools and patterns need to be incorporated to build the most effective systems.

Portfolio Management is one of those things that should be seriously considered.

There are several key underpinnings:

• Scrum Teams are an indivisible unit – in organizations where it is hard to create permanent, effectively sized (5-9 people) Scrum Teams, effective Portfolio Management can be the first step to making this happen
• All of the work flows through the Teams – there are no special projects done on the side
• Product Owners collaborate with their Development Team (aka Doers) to achieve the business goals
• Our focus is on delivering value and delighting the customer, not on maximizing the utilization of individual team members
• Incremental funding/budgeting versus annual cycles
• The organization has already visualized the state of the work using a Portfolio Kanban Board or similar tool

When your organization has only two or three Scrum Teams, it is entirely possible for Portfolio Management to be conducted by the Team Product Owners. They get together to discuss the big picture and where they want to steer their products over the next few months.

But when the number of teams becomes too large for informal coordination to be sufficient, or when Product Owners frequently find themselves outgunned by stakeholders with more clout, we need Portfolio Management to help keep the focus in the right place.

In the context of the World’s Smallest Online Bookstore we have a Portfolio Kanban board in this state (click for full version):

Managing the Portfolio can be as simple as holding a review meeting every six to eight weeks. The meeting needs to include the individual Team Product Owners, Chief Product Owner, executives who have a significant stake in the direction of the business, and other key stakeholders (internal and possibly external). In each Portfolio Review Meeting the assembled group will need to ask itself these things:

What is the current state of the Product(s)? This should involve a demonstration of each Product as it currently stands. As with Scrum at the team level, all decisions need to be grounded by seeing the actual working software.

The oft used traffic light Project Status Reporting – Green for all good; Yellow for needs some help, and Red for in trouble – are worse than useless, and are dangerously misleading. Instead of focusing on value delivered, they focus on schedule and a percentage of work done, versus actual features complete and value delivered. This leads to unrealistic beliefs about progress in a project because, right up and until the last moment, people believe that the project is healthy.

All of Scrum is based around the idea that value is only accrued or measured when it is truly done. In the above case of the Smallest Online Bookstore, that would mean demonstrating the items in the “Ready for Deployment” column. Perhaps we also demonstrate the features that are missing Online Help but are otherwise Ready for Deployment, such as Ship a Book Home and Star Reviews.

Are the current features that have been committed or are being worked on still the most important?

In the case of the Smallest Online Bookstore, that means asking whether the next items in the Product Backlog (“Find a book similar to…,” “Fancy Gift Card Graphics,” and “Support Payment Options Beyond MasterCard”) are still the most important. 

Reviewing the current Sprint should be a safety check, and not an alteration. Work that has already started isn’t quite sacrosanct, but it should be very, very unusual for it to be cancelled/changed now. If changes happen once the work has been started, that implies a failure at both the PO and Portfolio level. The effect of cancelling work that is in progress will be quite devastating and will affect the Team’s morale for some Sprints to come. In the case of the Bookstore there is nothing I can imagine that would justify cancelling a Sprint. From personal experience, Sprints might get cancelled because the company got bought and the product no longer makes sense, or a major client whose needs we’re working on fires the company. We’re talking major and unforeseeable stuff, not just someone changing their mind.

Are there any impediments to achieving the current Portfolio goals? What can this group do to resolve them?

Having stakeholders, executives, and Product Owners jointly agree to a direction and assume accountability for sticking to the plan will remove most, if not all, common obstacles. At the Bookstore, Steve’s team is having trouble getting daily pickups scheduled with Fedex. It turns out this is a contract issue and beyond the ability of the Scrum Team to handle on their own. Sarah’s team is being asked to do some work around displaying purchase histories by a stakeholder. Since the work doesn’t fit inside of the features they’ve been asked to work, and since their PO wasn’t able to solve the problem alone, we need someone above the team level to remind the stakeholder of the team’s focus.

Are there any feature areas that the Scrum Teams have invested enough time and effort? Have we validated/tested the current features with the Market? Do we want to Keep, Release or Transform (aka Pivot)?

Will the current work around Gift Cards, Premium Shipping, and Book Returns likely be sufficient?

Are there open slots for work in front of the Scrum Teams?

If so in what feature areas would the Portfolio group like them to invest? What would we like to see finished next? Is there sufficient capacity in the next 6-8 weeks that it is worth asking the teams to build new items?

Note this is not a commitment on behalf of the Scrum Teams – instead it’s an invitation to make these the next work items if there is capacity. This is where features in the Idea column of the board can be considered.

What are ballpark estimates for the next few features that are likely to considered?

Instead of Story Point estimates, simply ask whether the feature is likely to be bigger or smaller than a well-known feature that we’ve built in the past. At the Bookstore, that would mean asking the team if “Publishers can add books” is bigger or smaller than “Buy a Book” (large) and “Write Reviews” (smaller). To be clear, we’re not looking for precision – simply “bigger” or “smaller”. Some people use Tshirt sizing (S, M, L, XL) to illustrate the goal and keep it generalized.

But as you can imagine, when a group hands out a budget envelope, they want to believe that they will get value in return. This can sometimes cause conflict in the case of idle workers. We will address that in the next post in this series.

Resource: Map Your Current Process with Kanban

Mark Levison

Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.