Or “How Do I Start to Get My Portfolio Under Control?”

Often when we start an agile implementation it is well known that there is too much work to do, and insufficient capacity to get it done. But there is also a problem in that we have already “committed” to get all this work done, and further there is more work coming in. In many situations this is well known but there is a problem in that people feel that this is “just the way it is” and so live with the problem. In some cases the problem is exacerbated in that Teams could have their work visible in (often different) tools, feel like their work is under control and so don't see a need for a more holistic view. But a lot of WIP on Teams is directly the result of organizational WIP and so we need to understand the total picture.

The problem with too much work is that for each item we have, we are typically increasing the length of time it takes to get the work done on average. This is the work-in-progress (or WIP) problem (see What Is Wrong With 100% Utilization Thinking for more information on why this is).

As said, most people understand that this is a problem but don't see a way out of it. They feel like they have no basis for deciding, for example, which is the most important work, and which work should be scheduled later or even stopped entirely. Agile approaches provide solutions based on understanding the “Cost of Delay” to provide a more economic approach to prioritizing work.

The question for many is “how do we start?” The following script shows one approach to starting this discussion. It calls for a facilitated discussion that can be typically done in one day to help understand the priority order of work, the capacity available, and the items that should be “stopped”. While the script was originally developed to work at the enterprise portfolio level of project, there same approach can be applied at just about any level, although there is probably diminishing returns at say a Team level.

One note: this approach is aimed at setting things up. It does not talk about how you maintain these lists in evergreen format so that you don't have to go back an reprioritize all items every (say) quarter. You should also work to determine the going forward process of accepting new work in parallel so that you don't end up with the same problem later on.

As said, this is expected to be a one day facilitated event. At the end of the day we would expect the following outcomes:

• Core
  • Initial set of data to help us understand what the true capacity of organization
  • Prioritized list of Epics so we can understand where we focus
  • Initial pass down prioritized list to understand where cutline is (below is list things that we should stop)
  • Epic list is up to date
• Stretch
  • Begin understanding of how we do economic decision making in the Portfolio

We assume that people in the room have a common set of assumptions:

• We need to stop starting and start finishing
• We have limited capacity and need to understand what is possible
• We will use agile approaches to generate required data. This will be wrong, but it will provide a view and we will track data from here on in to improve
• We will compare our understanding of business value to size to determine preliminary priority
• We will do rough calculation of capacity the organization has for planned items
• We will compare size to list to understand cutlines, and discuss what falls below the line
• We will use Normalized Story Points

The following items are needed as an input into the day's events:

• Current list of all Epics on “stickies” in some way (for working on the wall): The simplest way to get this is to establish some kind of template and have the people that “know” pull together the list by filling in the template. Perhaps this means dumping a report out from a number of tools. Perhaps this means just generating a list. The key thing is to be clear about what data is required.
• Current list of all Epics in “tool” (as the final record): you will need to make a decision on where this is. This decision can be postponed, but this will make it harder in the long term to keep the list evergreen, especially if you have remote participants. Bottom line is that you need to know the single source of truth for this work.
• A field in the tool to capture Business Value (BV), Time Criticality (TC), and Job Size (JS)

The following sections provide a brief view of the facilitation for the day.

Set the stage with:

• Review reason for being here and outcomes
• Review background - what got us here, and why will be doing most of this on the fly
• Chalk talk on approach we will take
  • Have Understanding of Total Capacity Available to the Organization
  • Discuss / decide % of capacity that is not plan-able. Remainder is what we will plan to.
  • Build prioritized list of Epics based on economic decision making using WSJF = ((Business Value + Time Criticality) / Job Size)
• Review agenda

At this stage we are typically early in the development of our portfolio system so we are really looking at a Kanban board with “Backlog”, “WIP”, and “Done” columns. Set up a wall with these columns.

For your first time through this the activity is:

• Each person with “work” reads out their Epic and puts it in the correct column on the board.
• Others can ask clarifying questions about that work (this allows you to combine items that are related and remove duplicates as you go)
• Continue until no more Epics

If you already have captured this in the past and are looking to refresh the information so that it is current then the activity is:

• Bring up current Epic list
• Ask what items are finished? Move these to Done
• Ask what new items have we started on? Move these items into “WIP”
• Ask what areas are we missing? Create new items in the Backlog.
• Update “tool”, “stickies” with new information

Note: Basic rule remains “if it takes capacity, we need to discuss how it is represented on the Portfolio Kanban.”

The assumption here is that most of the time when people start this type of thinking, they decide they need to do this to get an understanding of “what we will get done in this budget year” and so they start saying “lets see what we can do in the remainder of the year”. Adjust the time period to whatever makes sense - the calculations below are based on “we are in the middle of the year, have 6 months left, and we need to see what we are going to get done by the end of the year.”

For 2 weeks, normalized Team Velocity is:

• (Number of people of the Team - Product Owner - Scrum Master) * 8) - Holidays and vacations
  • “8” is 10 working days per 2 weeks, minus planning, demo, retro, and dailies
  • PO and SM are there to help work and while they might help the team do the work, we share should not count them (gives us a bit of slack)
• This says “A Day = A Point” (a normalized Story Point)

To scale up, we will use:

• Total people capacity for a 2 week period is Number of people - Named roles (for example in SAFe implementation this would include number of RTE's, PMs, etc)
• 11 weeks in a quarter (a quarter is 13 weeks we will remove 2 weeks per quarter to account for holidays and vacation over the period)
• Total Quarterly capacity = Total people capacity * 11
• Total Half-yearly capacity = Quarterly capacity * 2

Determine Percentage of Capacity That is Plan-able

Assumption going in is that this work is:

• Probably not represented in Epics for the most part
• Probably some chunk capacity will be in categories such as “Keep it Running” category or “Sharpen the Saw” category
• Probably some part of investment in automation and monitoring

Activity is that we need a discussion to validate. Get percentages of “not Plan-able items”. Say using the categories above and then decide that we want to allocate some additional capacity for investment in automation and monitoring. Then:

• Plan-able Half-yearly capacity = Total Half-yearly capacity * (1 - not Plan-able items)

We expect to use:

• Business value (BV): how much value to item produces when complete - money coming in, cost savings etc
• Time criticality (TC): what is the impact of delaying the delivery of this business value

Note: this is not the part where we talk about how big the item is

Assumption is that we need to refresh ourselves on what we will regard as criteria. I think the best way of doing this is by doing a couple of pairwise comparisons based of the criteria and then capture relevant parts of the conversation.

Activity

• Pick 3 representative Epics from our list.
• Then ask to order these items based on BV.
• Then ask why and capture some of the reasoning.

Repeat for TC.

Create chart with no numbers on it:

• Horizontal axis: “Little BV” to “Big BV”
• Vertical axis: “No Time Criticality” to “Needs to Be Done Next Month (or whatever previous discussion gave you)

Do Play, Pass, or Move for each Backlog and WIP Epic. When complete, affinity map clusters, first on BV, then on TC. Magically call:

• Biggest items are call “20” group
• Smallest items are called “1” group
• Then group clusters in between these as 2, 3, 5, 8, 13

Numbers represent the BV and TC for each Epic. Capture results in “tool” (perhaps on sticky as well)

Need to understand the “bigness of the work”

This is not “duration” but is couched in terms of capacity the teams will take to do the work. Also this is “remaining work has to do”, not the total work we originally estimated.

Create chart with no numbers on it:

• Horizontal axis: “Extra small”, Small”, “Medium”, “Large”, “Extra Large”

Do Play, Pass, or Move for each Backlog and WIP Epic. Again, you should see clusters, and so affinity map to closest size on horizontal axis.

For the Extra-large cluster, ask someone to provide a view of “how many (man-)days of work does these Epics represent on average?” We will just use that as the number for the job size. Same for Extra-small cluster. Figure out in-between numbers.

Note: there will be a tendency to argue about how big something is. Resist! Resist! Resist!. Reality is that you don't have much more information at this stage, so we should not pretend that this is highly accurate information.

Numbers represent JS for each Epic. Capture results in “tool” (and perhaps stickies as well).

Explain WSJF as reminder:

• Idea is to schedule small value items before you schedule large less valuable items
• This version of WSJF takes BV and TC into account for value, JS for size of items
• Calculate WSJF of Portfolio Epics in spreadsheet - WSJF = (BV + TC) / JS
• Order list of Portfolio Epics based on WSJF

Using a cumulative total of JS compare to Plan-able Half-yearly Capacity Things below the cut-line should be stopped.

This is the end of the scripted activities, but I expect there will be some discussion (OK, I expect all hell to break loose). Point is that this the best economic way to do the work. But we will need to cast a brain over it. And we should try to treat the numbers as real - it’s the best data we have for a total view of the portfolio. Expect it to be wrong (most portfolios still kick off too much work when they first do this effort). But it is better than nothing and forms a good basis for making these decisions going forward.