This is a short description on the key difference between scrum, kanban and lean kanban.

With scrum:

From a product backlog of items, usually user stories, you deliver a potentially shippable increment, made of user stories that are “done”:

  • The user story arrives in your sprint backlog
  • We split it into tasks that we may want to estimate in hours (or not)
  • We implement all the tasks
  • When all tasks are complete and the product owner has accepted the user stories, then the user story is done: at this stage, we have not delivered any value yet.
  • We still need to go through the release process to finally delivery your product to customers, that could be lengthly depending on your DevOps process and tools
  • Only then, the return on investment is triggered.

 

With Kanban:

We are going to make our workflow explicit making all activities visible. More importantly, we move away from splitting user stories into tasks into slicing user stories into smaller user stories to maintain a flow of user stories.

  • The user story arrives in your sprint backlog
  • Instead splitting your user story into tasks, we slice it in smaller user stories because we want user stories to flow smoothly through your workflow: this is a key difference between scrum and kanban
  • Then, we start working on limited amount of user stories to keep “Work In Process” small and avoid costly multi-tasking
  • The goal is to go to production as fast as possible for a given small user story.
  • When the small user story has reached the production environment, then the return on investment is triggered

The speed you are going from the point you start working on the user story to when the user story is in production is your cycle time.

 

With Lean Kanban:

Keeping the flow-based system introduced with kanban, we look at the whole value stream, from concept to cash, optimizing value delivered to customers, taking a system thinking approach.

We also want to get feedback from customers to make sure we are building the right product and we are building it right.

So:

  • Upstream, we are going to go as far as we can in our workflow making it explicit we need to get feedback from customers.
  • Downstream, we are going to visualize the whole product backlog workflow (and that depends how you create your product backlog and manage it: it could be a user story mapping board, a design thinking board etc… As along as this is visible)

Here we are not creating processes, we are just making things visible and explicit as anything implicit could hide issues. Making things visible and explicit allows us to put continuous improvement in place more easily.

 

In conclusion:

With lean, having an E2E view of our value stream, we are able to optimize the entire system and deliver what really matters to customers: we are interested in the business value I deliver rather than a number of story points.

With kanban, by slicing user stories into smaller user stories and reducing “Work In Process”, we are able to move faster and better.

Focus on business value, Outcome over Outputs.

Advertisements