Design a portfolio Kanban board

Print this topicEmail this topic

Why do you need a portfolio Kanban?

How’s your portfolio working today? Do you know what’s 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’s tricky to answer these questions well. Using a portfolio Kanban (or two) might be just the ticket to speed things up and optimize the flow of your portfolio. You’ll deliver higher value work faster by focusing energy on the most important work.

What’s a portfolio Kanban?

Kanban systems work in part because they’re so simple. At its heart, a Kanban system is just a visual board that’s 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?

Just being able to quickly visualize the current state of your portfolio gives you so much value, but there are two powerful tricks used by clever Kanban users to get way more value out of their system than the average company.

  • 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.

We’ll talk more about how to use those tricks later.

How to design a portfolio Kanban

Agile organizations can use Kanban systems at many different levels. For example, an initiative Kanban can feed a feature Kanban, feeding a team’s story-level Kanban:

Here are a couple you might consider starting with:

A Kanban full of initiatives or projects

If you’re just starting out with using Kanban to manage your portfolio, we recommend working at the initiative (project) level. At Rally, 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 along the way. Each development team will probably want their own Kanban board, too.

Key benefits of using Kanban at the initiative level:

  • Most organizations go slower than they could because they’re working on too many projects simultaneously. A Kanban at this level can help solve this problem.
  • If you’re constantly doing resource management and trying to get the right people shuffled around to keep projects moving, managing your initiative WIP can make this activity dramatically easier.

A Kanban full of features or enhancements

If you’re releasing frequently, as we do at Rally, you might benefit from an additional level of Kanban below the initiative to track the enablement process for each marketable feature. Here’s part of the board we use at Rally:

Organizations who use Kanbans at this level find that:

  • It’s 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 keep track of 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 kick off 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.

Get started

There are three key things to think about 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, get together 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’re not sure if they’re 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’re in similar states.  

These states will be the initial columns on your Kanban board. At Rally, we’ve got six states on our Initiative board: Backlog, Initial Customer Validation, Assessing, Ready, Building, and Collecting Evidence.

Rally 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 just pay lip service to 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 you do want to 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
Exit Criteria
Pull when ready
Exit Criteria
- Story Backlog defined
- Estimated
- Value and Benefit clear
- Is there a P&P impact?
- Website changes needed?
- High level designs, if appropriate
- Arch council check-in
Exit Criteria
- 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. But after a few months they realized that this didn’t reflect how they were actually working, so they updated the policies to reflect their real process. Some things to note:

  • The early ones are really 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 lightweight, with the goal of creating an initial backlog for the initiative.
  • The business case isn’t created until after someone has spoken with some customers.
  • The policies are really short and readable, and can be used as checklists.

Eric Willeke, agile coach at Rally, recommends that you attempt to capture your existing policies first, and only commit to the ones that you actually do now.

You won’t get the policies (or the columns, for that matter) right on the first try. A Kanban board is a living system that changes as you learn about what’s 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 go past five items, you reduce the odds people will really understand the policy. At Rally, 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 doesn’t require a fixed rhythm of meetings in the same way a batch-based process does. But given scheduling challenges it may be tough 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 on the same page 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, you’ll want 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.

How to use the portfolio Kanban to accelerate

The key to successful Kanban use is limiting work-in-process (WIP). In short, 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’ll go faster if multiple teams work together on initiatives, but it is normal for a team to be finishing up one initiative as they start on another one.

What if I don’t have stable teams?

Many organizations aren’t in a position where they’re flowing work across cross-functional teams. In this case you’ll 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’m way over WIP?

Congratulations! You’re staring right at the number one reason projects take forever. 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 very visible, your project pileup has been hidden. Speeding up the system doesn’t help at all. 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.

But how do I get the system back under control? 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 simply focus on the items that can be finished the quickest, regardless of business value (see Don Reinertsen’s book, The Principles of Product Development Flow, p131, for more on this).

We’re back under WIP. What’s next?

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’s 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.


Please send us your feedback regarding our help site. For feedback regarding the Rally product, click here to open a support case or click here to submit a new feature request
By submitting this form, you accept the Mollom privacy policy.
© 2014 Rally Software Development Corp | Legal