Design a Portfolio Kanban Board
How is your portfolio working today? Do you know what is going on with every project? Which ones are started? Which ones are stalled? Are projects delivering value as fast as possible? Are your teams always putting the most energy on your top priorities? Are you preparing just enough information to move forward steadily, with no waste?
With most portfolios, it is difficult to answer these questions well. Using a portfolio Kanban (or two) can help optimize the flow of your portfolio. You will deliver higher value work faster by focusing energy on the most important work.
Kanban systems work so well because they are so simple. At its heart, a Kanban system is just a visual board used to manage the flow of work. Many software teams use Kanban boards to manage their processes. You can use the same concept at the portfolio level.
What can you tell about this portfolio from looking at this board?
- Which projects have started? Which are waiting?
- Is there a bottleneck in the system? Which column is the slowest?
- Should Discovery work continue? Does this portfolio need more analysis done?
Quickly visualizing the current state of your portfolio provides so much value. Consider these two actions to get even more value:
- Limiting work-in-progress enables more valuable work to be completed faster
- Pulling items when ready to work (rather than creating large inventories of work) reduces waste
Design a portfolio Kanban
Agile organizations can use Kanban systems at many different levels. For example, an initiative Kanban can feed a feature Kanban, which feeds a team’s story-level Kanban:
Here are a couple you might consider starting with:
A Kanban full of initiatives or projects
If you are new to using Kanban to manage your portfolio, we recommend working at the initiative (project) level. At CA Agile Central, an initiative is a set of work with clear success criteria that can typically be completed in a few months. An initiative can be completed by one or more teams, and might release software in a few increments. Each development team will probably want their own Kanban board.
Key benefits of using Kanban at the initiative level:
- Most organizations go slower than they could because they are working on too many projects simultaneously. A Kanban at this level can help solve this problem.
- If you are constantly doing resource management and trying to get keep projects moving, managing your initiative WIP can make this activity much easier.
A Kanban full of features or enhancements
If you are releasing frequently, as we do at CA Agile Central, you might benefit from an additional level of Kanban below the initiative to track the enablement process for each marketable feature. Below is part of the board we use at CA Agile Central:
Organizations who use Kanbans at this level find that:
- It is much easier to understand what is shipping soon.
- If your teams ship features frequently (daily or weekly) to a SaaS or IT system, this level of Kanban can help track which features are toggled on for different groups of users.
- Enablement activities such as documentation, training, and marketing can be driven by feature availability, rather than batched.
- Visibility into features in the early stages makes it easier to plan external activities just-in-time. For example, if a new feature warrants a change to pricing or a website, this board can help start that process at the right time.
A Kanban full of implementation, content, or Professional Services projects
What do medical research and video game development have in common? Both can involve separate development of a core engine and implementation.
In the medical space, studies might be set up by a professional services group in a matter of a couple of weeks.
In the video game space, once the game engine is built, a large amount of content needs to have many repeatable steps applied to it such as animations, sounds, and so on.
A Kanban system at this level can help you:
- Accelerate the speed at which content or studies are completed.
- Reduce the coordination overhead by replacing cumbersome project management with a simple pull system.
There are three key things to consider when setting up your portfolio Kanban:
- Columns on the board
- Policies that must be met for items to move
- Meeting cadence that you’ll use to work with the board
To get a quick start on your portfolio Kanban, gather a few key leaders of your product management team or PMO.
Discover your initial columns
Brainstorm all the initiatives that you have in progress right now. For example, about projects that are:
- In active maintenance mode
- Have just shipped
- About to ship
- Being tested or fixed
- Mostly done but waiting for a specialized resource
- On hold or stalled
- Fully moving
- In an earlier exploration stage
- Are getting energy but you are not sure if they are worth pursing yet
- Are being done on the side or under the table
This is a great activity to do with sticky notes on the wall. Once you feel like you have almost all of the active projects listed, start grouping together the ones that seem like they are in similar states.
These states will be the initial columns on your Kanban board. At CA Agile Central, we have got six states on our Initiative board: Backlog, Initial Customer Validation, Assessing, Ready, Building, and Collecting Evidence.
CA Agile Central Kanban coaches work on-site to guide organizations through the process of designing your portfolio Kanban so you can see results faster. Learn more about how this offering has helped your competitors already.
Remember your current policies
You might have an extensive software development process already defined that prescribes what steps have to happen as projects advance through their life cycle. In many organizations, this kind of process is extremely detailed, and people ignore many of the steps. A simple process that people actually follow is more rigorous than a complex process everyone avoids.
In a Kanban system, simple policies define when items can move across the board. The simpler the policies, the more likely they are to be followed, but make sure truly critical activities are represented. Think of each policy as a simple checklist that needs to be checked off before an item moves. Here are some policy examples at the feature level:
|Backlog||Analysis||Ready for Dev|
Pull when ready
- Story backlog defined
- Value and benefit clear
- Is there a P&P impact?
- Website changes needed?
- High-level designs, if appropriate
- Arch council check-in
- Detailed designs for first stories
- P&P committee notified, if needed
- Dev pulls first story
This group started with a much more extensive, idealistic list of policies: the business case was defined before customer interviews and competitive analysis began and so on. After a few months, they realized that this did not reflect how they were actually working, so they updated the policies to reflect their real process. Some things to note:
- The early policies are easy to meet. Before you begin customer validation, you need to define a problem statement and list the hypotheses you plan to test. In many cases, this takes only minutes.
- The customer validation stage is also simple, with the goal of creating an initial backlog for the initiative.
- The business case is not created until after someone has spoken with some customers.
- The policies are short, readable, and can be used as checklists.
Eric Willeke, agile coach at CA Agile Central, recommends that you attempt to capture your existing policies first, and only commit to the ones that you actually do now.
You may not get the policies (or the columns) correct on the first try. A Kanban board is a living system that changes as you learn about what is working and where your bottlenecks are.
Does policy length really matter?
Up to ten simple bullet points per column are reasonable, but as soon as you have greater than five items, you reduce the odds people will understand the policy. At CA Agile Central, we experimented with a variety of policy lengths. At one point, policies lived in a spreadsheet that defined activities for different groups in each column—up to 15 or 20 activities. The result? Everyone ignored the policies and just moved items forward without discipline. A simple, brief checklist visible on the board is much easier to work with and much more likely to be followed.
Find time on calendars
A continuous-flow system like Kanban does not require a fixed rhythm of meetings in the same way a batch-based process does. Scheduling challenges may make it difficult to get your PMO or product management team together on short notice. Since items at higher levels may take weeks, or months, to move between columns, it can help to establish a cadence to check in on the board:
- At the initiative level, you might start with a monthly Portfolio Council to keep stakeholders in sync about that state of your portfolio, and a biweekly review and prep cadence with the product management team to ensure the board is up-to-date.
- At the feature or enhancement level, to align your review cadence with your release process. If releases happen weekly, you might want to get product owners and marketing together each week for 10-15 minutes a few days in advance of the release so enablement activities can be coordinated.
Use the portfolio Kanban to accelerate
The key to successful Kanban use is limiting work-in-process (WIP). Reducing the number of items in-flight enables items to be completed quickly.
Which column to limit first?
Most initiative or project-level Kanbans will contain one Building or In Development column where active development effort is happening. This column is a good candidate for a first WIP limit.
If you have semi-stable, cross-functional teams that pull new initiatives when ready, consider setting your WIP limit to the number of teams that you have as a starting point. In many cases you will go faster if multiple teams work together on initiatives, but it is normal for a team to be finishing one initiative as they start on another one.
What if I don’t have stable teams?
Many organizations are not in a position where they are flowing work across cross-functional teams. In this case you will need to start somewhere. Add up the number of developers, testers, and other team members you have and divide by 7 (as an average team size). Use this as your starting limit.
What if I am over WIP?
Your Kanban board is showing you that your system is out of control, just like the famous scene from I Love Lucy.
While Lucy’s chocolate pileup is visible, your project pileup has been hidden. Speeding up the system does not help. What does help is stopping the line. You need to stop more initiatives from entering the In Progress state. Generally, teams and leaders need to know that new initiatives can only be pulled when the system is below its limits.
Most of your projects are probably going slowly because resources are spread across too many projects at once. You need to set clear priorities in your Building column, so that people can focus their energy on clearing out items. Sometimes, the best way to start is to focus on the items that can be finished the fastest, regardless of business value (see Don Reinertsen’s book, The Principles of Product Development Flow, pg, 131, for more details).
If your In Development column is under WIP and all items are showing daily progress, you can start to look at other columns in your system. If you have a Ready column just to the left, where initiatives wait to move into development, that column might be a good candidate for a WIP limit. While it is often a good idea to have a few initiatives ready for teams to pull, this queue can imply a commitment to start on an item, which reduces your agility.