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


  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




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

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How to Use Terraform with GKE: a Step-by-Step Guide to Deploying Your First Cluster

Why My Future is Serverless in the Microsoft Cloud

Error “Accelerator mode is not supported through the S-Function API” when calling set_param in…

Here Are The Locks A Master Locksmith Couldn’t Figure Out How To Open

Phase III Progress Report — New functionality — High score

LibGDX — Exploring Scene2D

6 Ways to Apply CompTIA Security+ Material with Python

Error-free installation of Owncloud Server on Windows 10 within 30 minutes using WSL!

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.

More from Medium

Improving Sprint Predictability in Agile Scrum

Agile Scrum 101 — Every detail covered in less than 5 minutes

Using miro for Market of Skills

3 tips to convince the Client to use Agile