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:
We assume that people in the room have a common set of assumptions:
The following items are needed as an input into the day's events:
The following sections provide a brief view of the facilitation for the day.
Set the stage with:
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:
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:
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:
To scale up, we will use:
Determine Percentage of Capacity That is Plan-able
Assumption going in is that this work is:
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:
We expect to use:
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.
Repeat for TC.
Create chart with no numbers on it:
Do Play, Pass, or Move for each Backlog and WIP Epic. When complete, affinity map clusters, first on BV, then on TC. Magically call:
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:
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:
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.