Kanban Portfolio View

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

Do you know what projects your Team is working on?

Do you know what the Teams around you are working on? Does everyone in your organization know?

In almost every organization that I visit, the answer is a resounding no. Scrum may have been implemented at the Team level but nothing is being done beyond that. Is there any dark work being done?[1] Is it a high priority?

Without a clear picture, individual Teams and Team members don’t know what the overall priorities are, so they won’t know if a favour that someone asks for is in scope and valuable, or an expensive distraction. As a result, a lot of lower priority work is completed and causes unintentional damage to the project.

Kanban has three core rules: visualize your work, limit your work in progress, and measure and improve.

1. Visualize your work

Our first goal is to find a way of visualizing your work in a structure that your Team and your peers will understand immediately.

Some examples:

Create Your Initial Kanban Wall

Gather enough of your peers and build a consensus overview of your work. Write down all of the steps in your world of work: from the moment an idea comes up, until it can be deployed. You can do this with the formality of value stream map or you can just write down an ordered list of the steps. Since we’re creating a portfolio view, the minutia of what happens inside a single development Team is probably just going to be a distraction.

For the Teams at the “World’s Smallest Online Bookstore”, the list of steps looks like this: Idea -> Idea Accepted -> Product Backlog -> Sprint Backlog -> Done -> Online Help Done -> Deployed -> Translated

Turned into a Kanban wall for two Teams, it might look like this:

Track the Work

Once the board structure is complete, work with each Team to find out the current state of their work. To keep it simple and high level, consider tracking chunks of work that are ~1 week in size per Team (if you’re doing Story Point estimation, imagine that these items are around a 13, 20, or larger in size). This way everyone can see a high level without getting lost in the minutia of a specific User Story. To identify which Team is working on a given item, either use swimlanes as above, or a separate coloured card/post-it note. Once a week, walk the wall from beginning to end with the Teams and update with the current state of work.

When we get more sophisticated, it often helps to track roughly how many days each work chunk stays in each state.

Visualize Blockages

Now that we’re tracking the flow of work, it will quickly become apparent that there are places in our system where work either piles up or becomes blocked. We need to understand where the work is getting blocked and what is blocking it.

Are our challenges caused by a lack of people able to help at one stage (e.g. Technical Writers for Online Help)? Or issues outside our current span of control (e.g. deployments by a manual security audit by our webhosts)?

Visualizing this can be as simple as putting a tick mark on an item for every day/week it’s stuck, or creating a separate “waiting for” column in all places where these blockages occur. Either way, our goal is to understand where the blockages occur and work with our peers to resolve them.

At the World’s Smallest Online Bookstore it’s apparent that…

… we have a lot of work that is getting blocked at the stage of online help. Before we focus on improving the development Teams’ performance (i.e. their ability to build features) in the short term, it would be best if we addressed the systemic issues that are stopping previously completed features from being deployed.

This leads us nicely to the second rule of Kanban: Limit Your Work in Progress. In the next post in this series, we’ll discuss how blockages can be quickly identified and strategies implemented to overcome them, without anyone waiting around unproductive or, just as bad, overwhelmed and stressed out.

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.