A few weeks ago, I took a look at six steps for successfully scaling Agile
in large companies, a process that TestTrack can greatly simplify
. This time around, I’m taking a closer look at the first three steps in the process: the Kanban feature flow, Traditional Portfolio Scoring, and the roadmap document. I’ll be devoting a blog post to each of these topics, starting today with 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 a Kanban Board?
A Kanban board is a good way for management teams to organize all these ideas. I 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. Take a close look at the example below, which shows all the features that are currently being processed by a team. 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.
The 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.
[caption id="attachment_17958" align="aligncenter" width="750"]
This is one type of Kanban board, but you may need different columns, or stages, to manage proposed features.[/caption]
Two additional things are worth noting about this board. 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. Clearly, if you try to investigate dozens of ideas simultaneously, you will bring the process to a halt, and the development teams further down the line will have no approved features to work on. WIP limits expose bottlenecks as soon as they occur.
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. This level of insight is a benefit of using an ALM solution like TestTrack to provide a single source of truth.
Now let’s examine each stage 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. Also, 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 TestTrack as an example, but you should tailor it to suit your specific needs.
[caption id="attachment_17962" align="aligncenter" width="750"]
This template in TestTrack prompts the user for the required information when submitting a new idea or feature request.[/caption]
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, and will move to the Deferred stage or be rejected entirely. Others, however, may need further analysis before a decision can be made, and 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.
[caption id="attachment_17966" align="aligncenter" width="750"]
This template prompts the user to provide the business case information for the feature.[/caption]
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, which is the end of the first of our six steps. 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 and Completed Columns
Although Step 1 ends at the Backlog stage, our sample Kanban board continues with the Construction and Completed columns. These two columns allow the management team to track the progress of features even after Step 1 is finished.
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. Likewise, it will move into the Complete column once the team marks it as complete on their Scrum board.
Moving to Step 2
The next step in scaling Agile is Traditional Portfolio Scoring, where the high-level backlog from Step 1 is prioritized. I’ll discuss Traditional Portfolio Scoring in greater detail in my next blog post, but for now, suffice it to say that this process may be done by the product manager in conjunction with the rest of the leadership team.
Again, you can watch my recorded webinar, Six Steps for Scaling Agile
, if you want an overview of the entire process. If you have any questions, please leave them in the comments.