Are Kanban Explicit Policies and the Scrum Definition of Done The Same?


This is a common assumption that I come across when running my Kanban System Design Class.

Scrum defines the definition of done as: A formal description of the state of the Increment when it meets the quality measures required for the product.

Kanban defines it as: How work is done at each step of the process, how it is visualized, how decisions are made, and what the appropriate relationships are, both within the service organisation and with its customers.

So there are similarities, they are both interested in delivering value to the customers and ensuring that the quality is high.

But for me, explicit policies just go that one step further. Rather than just being mindful of the ‘Done’ state, it also considers the journey and states that the work takes to get you there. We ultimately want to be able to optimise the flow of work to be able to get the work done in a fit for purpose way.

Benefits of Explicit Policies

  • Understanding of how work gets done – Promotes transparency
  • Expectations are understood
  • Improved quality of output
  • Ownership – The team/org owns and defines them and changes them
  • New people know how we operate, and what they should be thinking about when they join

Examples of Types of Policies

Policies on Waiting States

On our boards we have columns that might be waiting states. Waiting states effectively impact your ability to deliver and how long it takes. It’s not in our interest to have work hanging around for long periods of time. So we want a way to encourage the movement of this. One of the first waiting states you will come across, and everyone has, is the Product Backlog. I often work with organisations and I see hundreds of tickets waiting for many years to be delivered. Let’s be honest with ourself, if it’s been on there longer than 6 months…you are probably not going to get your work done! We need to keep our Product Backlog moving and so we want to be reviewing this regularly and discarding anything that is unlikely to happen. So I often have a policy here that says ‘If a item is older than 6 months, discard, discuss with the raiser and archive’.

Another example is your blocked, waiting or on hold column. These columns are bad! The name of the game is to get work done, and so realistically we need to work on our upstream scheduling to ensure we have dependencies or other teams lined up. Equally if we are missing information, then what could we do differently next time in terms of getting this ready before we start. So maybe we need explicit policies around the readiness of work or maybe we have a policy on what to do if something has been blocked for more than 1 week.

So have a look on your board at the waiting states, and see what policies the team might need to agree to, to get things moving and organised.

Policies on Expedites or Class of Services In General

Organisations might call these different things such as major incidents or P1’s. Ultimately they are bad for your system. Check out this blog where I tell you why. So we need to be really clear about the impact of these on our system, how many we can deal with, and what truly makes an expedite.

I often see teams get many expedites as stakeholders know this is the fast lane. Some of them are important, others are just trying to push their luck. So we need to get a handle on this.

Our policy here might be a definition of what is an acceptable expedite that a team would take in, and a work in progress limit (WIP) to say we can only work on one of these at a given time.

There are other classes of services you can do this with as well, such as the Intangibles. Think of these as improvements to the system. You might have a policy that says you will keep 15% of the teams capacity to work on improvements.

A policy on a fixed date class of service might be that there truly is an impact if this thing is not done. Impact here could be financial or other.

So you have lots of options. What would your expedite policy look like?

Policies on Types of Work or Different Customers

If you are a team that does lots of different services eg project, support, small change then you are going to have lots of different types of work that you need to juggle. Maybe you need an explicit policy to ensure that each of these types of work gets done. Sometimes we call these ‘Capacity Allocation’ and have these as work in progress limits on the horizontal swim lanes. Not many tools allow you to have limits on these, and so a agreement needs to be put in place verbally and recorded.

This would work the same if you have a team with many different customers. Maybe marketing can have a WIP of 2 and Finance can have a WIP of 5. That way, all customers get served.

Policies Between Column

So here we articulate what needs to be done as we move between the columns. Sometimes these are called ‘Entry’ or ‘Exit’ criteria. This is closer to the definition of done as it details the ‘Done’ needs. I suspect many of you have this already, but wanted to include here for completeness.

Policies On Ways of Working

It’s during the retrospective or problems that teams normally come up with these. So let’s capture these on a team ways of working board. It might be things such as ‘No laptops during planning’ or ‘Work has to be peer reviewed by 2 people’. You don’t want to forget these things, so capture them.

The World Is Your Oyster!!

In fact! there is even more types of explicit policies you can have. Below is an abstract taken from Kanban plus. It documents the different levels of organisational maturity and the types of policies to be thinking about at the different stages. Hopefully this image will give you even more inspiration.

A Word Of Warning

There is a temptation to write policies for everything, and they end up really big. What happens then?

No one will bother reading them as they are too large. There is a fine line between explicit, but not war and peace. You have to find the right balance. Document them and review them regularly, aka every 3 months or when the nature of your work changes.

In Conclusion

Scrum and Kanban are very different methods, but they are complimentary. Try some of the above with Scrum or Kanban implementations. Whatever you decide, now is the time to get people back together and refresh those policies.