Using a Kanban board as visual control for your Scrum project

Agile software development, is at the end if the day, a set of actions that take place to add value to a customer from the initial request through to delivery. This value stream begins with an initial concept and envisioning, moves through various stages including development (where most Agile methods begin), and on through final release and support.

It’s important we reflect this no matter what agile approach we are using. Scrum is a great framework, but people don’t always use lean principles and practices to further enhance it. I think there are a lot of lessons from kanban that can be applied to a Scrum development approach, it isn’t always as black and white a decision to use one approach rather than the other. It is also possible as Corey Ladas shows us to transition from Scrum to Kanban progressively.

Let’s first look at the five Kanban principles:

1. Visualise Workflow
2. Limit Work-In-Progress
3. Measure and Manage Flow
4. Make Process Policies Explicit
5. Use Models to Recognise Improvement Opportunities

For the purposes of this blog I will look at the first 2, principles, I’ll review the other 3 at a later date, if anyone would like to read it!.

Many Scrum implementations fail to visualise the value stream at any stage, never mind end-to-end. As a result I have seen periphery activities get lost even if we keep an overhead as part of capacity for Sprint planning. These activities include Grooming the product Backlog and product support / defect fixing.

Agile software development puts the emphasis on the Product, rather than the short term project; as such many development teams take on support and maintenance aspects for the Product they are incrementally developing. These product support activities, along with technical, team and environment activities need to be prioritised and managed.

Preparing Stories for the next Sprint, otherwise known as “Grooming the Product Backlog” should, rule of thumb, be around 10% of Sprint overhead in terms of effort. But how do you track it is around 10% and who is working on those activities? Rather than assuming we are on track, we need a control mechaism to track outside the sprint backlog. Serge Beaumontdefines Grooming activity flow from ready, iterate to Done, which breaks down as follows:

Fig 1: Flow for Grooming The Product Backlog

Already this starts to look like a value stream, by turning this on its side and assigning WIP, we can start to create a Kanban style (ok a value stream) visual control. Grooming the Product Backlog becomes part of the Value stream, those activities that take place prior to the downstream Sprint, while product maintenance and additional activities can be managed via an expedite lane; a class of service for high priority defect fixes (probably defects that require resolution in less time than the timeframe of the Sprint).

Fig 2: Kanban-syle Scrum Visual control board

Additional comments and notes on use of the board:

• The Work lane is the standard item class of service lane, for Sprint Backlog items. Based on team capacity, this should have a sprint WIP limit, probably based on Overhead Hours Allocated; as per the Expedite lane.
• Use an Expedite lane to track defects that need to be fixed if use an overhead in your Sprint to track and work on defects if your team support the product in operation as well new development
• As Mike Cohn points out the human brain can only deal with a finite amount of items, do you really want your backlog to be more than 120 items?! Limit the overall amount of individual items  in your Release you are working on; i.e. look to break your release down and deliver working software often.
• Limit Release points in progress (including those that are Done but not yet in Production) this enforces Release planning, which should be done at least quarterly
• Use the Ready column for Rolling Planning, pull an item from here if you finish sprint Backlog with time to spare.
• I’ve used Entry criteria rather than exit criteria at each stage, as this is a kanban-esque pull system! I’ve only included a couple of examples here, the context of your environment will define what these are. I’ve also included the Definition of Ready concept; a contract between users and developers.
• Evolve your Sprint stages and limits to reflect the way you work, keeping in mind core principles and values. I have only used a Development lane as an example, add to it to reflect how you work (not how you think you work !). Include value add activities such as Test. The board is not a sequential set of lanes. Maybe limit number of tasks per story, total sum hours of tasks in progress at any one-time, number of avatars to limit amount of work any one person is working on at a time. If you have Working Agreement statements such as only work on one work item at a time, and don’t pick up a new item unless you are blocked; you already have WIP limit rules, albeit written in textual format.

The most important thing is that this is an example based on the Scrum framework. Use it as a basis but evolve it to suit your process and team. There is no one-right Kanban board. It is a reflection of how you work. You may want to think about splitting the board into 2, as it can get a bit busy. The Release being “Ideation”, with the Sprint aspect containing more columns relating to how you complete work and conduct tasking.

I have called it Kanban style, as there is batching that goes on at the Sprint timebox level, which causes issues for time-stamping and cycle time, the stories in a Scrum framework are broken down and smaller and therefore there are more of them. The key is to visulise and map your workflow / Scrum framework and use restrospectives to improve your process.