Scaling Agile, Step 1: The Kanban Feature Flow
Adopting Agile can be difficult. How can you be successful with your Agile adoption?
Scaling Agile might be the answer.
In an on-demand webinar, we covered "Six Steps for Scaling Agile."
Here, we're taking a deep dive into the first step — Kanban feature flows.
What Is the Kanban Feature Flow?
So, what is the Kanban feature flow used for?
When the management team begins to plan a new product (or a new iteration of an existing product), there are many competing ideas as to what should be developed.
Obviously, not every idea can or should be developed. So, you need an efficient way to capture all the good ideas and assess them correctly — without wasting time investigating ideas that are non-starters.
Why Kanban?
A Kanban board is a good way for management teams to organize all these ideas.
We call them “features,” but you may call them “epics,” “projects,” “work requests,” or some other name. The important thing to remember is that we’re talking about large-value, large-effort work items.
You also need to capture the smaller work items. But those are probably best captured and implemented when development begins — at the Scrum team level — as new user stories. User stories would be tracked on a separate task board that the Scrum master would maintain.
The Kanban board is a great way to monitor the current status of all features that have been proposed, and make that information visible to everyone.
A Kanban Example
The following Kanban board shows all the features that are currently being processed by a team. 
There are two things are worth noting about the Kanban board above.
Work in Progress (WIP) Limits
First, it has “Work In Progress” (WIP) limits. The WIP limit is noted in the white bubble in the column header. For example, the WIP limit for the Investigation column is five, of which there is currently one in play — hence the “1/5” in the column header.
The idea behind WIP limits is that they stop bottlenecks by making it very clear when you are exceeding your capacity at any stage in the process. If you tried to investigate dozens of ideas simultaneously, you would bring the process to a halt. And the development teams further down the line would have no approved features to work on.
WIP limits expose bottlenecks as soon as they occur.
After a Feature Is Approved...
The second thing to note about this board is that it doesn’t stop after a feature has been approved — even though the main purpose of the board is to aid in feature planning. Instead, it also shows you when features have moved into Construction and also when they are completed.
More Tips on Setting Up Kanban Boards
This is one configuration of a Kanban task board, but it’s certainly not the only way you can set it up.
Some teams have fewer columns, but the idea is that each column represents a stage in the life of a feature as it is either rejected or processed through to completion.
A Kanban board is really good for that purpose, because it makes the status of these features highly visible. It’s also easy to manage the features by simply dragging them to the correct column — assuming you have the proper authority.
The columns are part of a defined workflow in which you control who is allowed to move items between columns, and to which columns. This safeguard prevents users from bypassing the Investigation and Approval stages to sneak their pet feature straight into the Backlog column.
You may need different columns or stages to manage proposed features.
Kanban Steps
Now let’s examine each Kanban step individually, moving left to right.
The Draft Stage
Sometimes, it seems like everyone has an idea for a new feature for your product — developers, testers, sales reps, customers, upper management, and so on.
It’s a good problem to have, especially when most of the ideas are valuable features to add to the product. You don’t want to limit feature requests and ideas, because you might miss some really good input.
However, if you try to investigate (much less develop) every idea that comes along, you’ll be swamped. And some ideas may conflict with others.
So, you need to capture all ideas in a manageable way, and that’s what the Draft stage is for — capturing all of the proposed feature ideas and storing them for later investigation and prioritization.
At this stage in the process, the person submitting the idea or feature request needs to enter enough information to allow for a thorough evaluation. To ensure the requester provides more than “a lot of customers have requested this,” you should provide a template to prompt them for details.
Below is the default template from an agile lifecycle management tool (Helix ALM) as an example, but you should tailor it to suit your specific needs. 
This template prompts the user for the required information when submitting a new idea or feature request.
The Deferred Stage
Although the next column is the Deferred stage, it’s not the next stage in the process.
Once a feature leaves the Draft stage, it moves into Investigation. At the end of the Investigation stage, the decision is made to either develop the feature or save it for later.
If it’s saved for later, it’s placed in the Deferred column, usually with a note as to why it should be delayed. Also not on the board at all are rejected features, which stay in the database but are removed from the visible board.
The Investigation Stage
Once you’ve captured all feature requests and big ideas in the Draft column, you need to make sure that they are correctly processed and prioritized.
Some will clearly not fit. Those will move to the Deferred stage or be rejected entirely.
Others, however, may need further analysis before a decision can be made. That is what the Investigation stage is for.
A lot of effort goes into analyzing a feature’s business case — gathering high-level estimates, doing a cost-benefit analysis, analyzing risk, defining the high-level scope, and so on. That’s why this stage has a WIP limit; if you have too many features being analyzed, the process bogs down.
As in the Draft stage, a certain amount of information about the feature should be required before it can move into the Investigation stage.
Below is an example of a template to guide the user and ensure the right information is supplied. You may want to include different topics, but remember that this is Agile—keep it lightweight. 
This template prompts the user to provide the business case information for the feature.
The For Approval Stage
Once the feature is investigated, it moves into the For Approval stage and waits for a decision-maker (or often a board of decision-makers) to review the business case — and agree that it’s a worthwhile feature and should be developed.
The For Approval stage has a WIP limit for the same reason the Investigation stage does. Decision-makers can only review so many business cases without becoming a bottleneck.
The Backlog Stage
Once approved, the feature moves into the Backlog stage. This backlog is for high-level features, and not the user story backlog that the Scrum teams will use when they begin development.
I have included only new features in the example above, but in the real world, you have to strike a balance between the need for new features and the need to evolve the product architecture. Major architecture changes or major changes to existing features should therefore be added to this backlog, so that their cost and benefit can be assessed along with new features.
The Construction Stage
The Construction stage allows the management team to track the progress of features.
If you’re using an application lifecycle management (ALM) system, the feature will automatically move from the Backlog column to the Construction column when the Scrum team begins work on it.
The Completed Stage
The Completed stage also helps the management team track the progress of features.
Likewise, it will move into the Complete column once the team marks it as complete on their Scrum board.
Scaling Agile, Step 2: Traditional Portfolio Scoring
The next step in scaling Agile is traditional portfolio scoring, where the high-level backlog from your Kanban board is prioritized.