How we transformed our Scrum with Kanban (part 3)

  1. Defining and visualising the workflow
  2. Limiting work-in-progress (WIP)
  3. Actively managing the items in progress
  4. Inspecting and adapting your workflow.
  5. Having feedback loops
  6. Make policies explicit.

Feedback loops

If you want to be a Scrum team that uses Kanban principles, all the Scrum events still stand, including the sprint itself. Each Scrum event is designed for a specific purpose. They give the team the chance to inspect and adapt each of the Scrum artefacts. Inspection and adaption drive greater transparency.


Having clear policies helps the team when they come to define and visualise the workflow. The policies will always be unique to the team and their context. When we came to design our board, these are the policies we used:

  1. Product backlog item (PBIs) types: Kanban sometimes call these ‘classes of service’. Our team has four different PBIs: fixed date item, non-fixed date item, accelerators and expedite. Accelerators are usually linked to a significant business objective or KPI and are still either fixed or non-fixed date. We use that label as the work will show up as a different colour on the board, and we’ll use the daily Scrum to call those items out specifically. Expedite items have a particular swim lane on our board, and the team will usually drop whatever they’re doing to work on that. Our current average lead time for expedite PBIs is one day. Expedites are for emergencies only, and we have a policy on what when we can use them. The team were rightly worried that any stakeholder might come along and insist their PBI should be prioritised as an expedite.
  2. Workflow: these cover each of our disciplines within our development team. They focus on what a PBI is and the refinement process before it is accepted, along with a clear definition of done. For example, our UX policies include clear requirements about user goals, data we should be considering, related design principles and more. Another example around a definition of done for our developers is ensuring certain test conditions and the relevant sign-offs before going into production.
  3. Visualisation policies: are linked to both points above. These are simple standards we have put in place to ensure everyone understands how our PBIs work and the relevant policies at each stage of our board. For example, each class of service is marked by a different colour. We have clear pull policies on how PBIs should move through a system and what needs to be in place before a team member pulls an item across the board. Having these policies means the right conversations happen, with a good amount of knowledge transfer.
  4. WIP limits: are essential to Kanban. I spent some time in a previous blog post explaining them. Our WIP limits are displayed on our board at the top of each column. We try always try to keep our WIP limits at capacity as that encourages a healthy flow. The number turns red if the WIP limit is breached, usually serving as a talking point at the daily Scrum.

A final note on tools

You may have noticed I haven’t talked about the tools we use to build our Kanban system. That’s deliberate.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Agile Alex

Agile Alex


Hello! I’m Alex, a product manager based in the UK. This is my blog about product and agile.