On Planning in Kanban

February 26, 2021

The "backlog refinement" time is the planning time to see what we should be working on next. This is like sprint planning except there is no idea of commitment and it's just planning what's ahead without dealing with when things should be done because we acknowledge that things will take what they take - we try to be as fast as possible and seek to continuously improve.

To plan effectively in Kanban one has to make good use of the this time. You can use it to:

  1. Plan out what the next month might look like at a high-level
  2. If the refined column is running thin, talk about some upcoming stories so there's enough in there that we're maintaining a continuous flow of work
  3. Use that time for a technical discussion related to some work that's upcoming
  4. There are no rules as to how you might use that time, it's just up to the team to use it effectively. This flexibility can be scary.

I have no problem against Scrum. We're just very poor at meeting commitment and we over-commit to things and complete nothing because we have too many things in progress. Some of that is due to external dependencies, but most of it is trying to jam everything into a sprint. We used to complete less than 50% of our stories when in Scrum and wasted so much time planning for stuff that we didn't even get to, that it was quite wasteful.

So a Kanbanish system helps with that by forcing you plan "just in time" (hence the WIP limit on the refined column). You can do this in Scrum too, but here it's more explicit. Scrum emphasizes commitments, Kanban flow.

If planning is the what, where do we plan the how? Is it when the developer picks up the story?

It sounds like you're talking about how you might want to break up the work related to the story that appeared in the "Refined" column because you want to work in small pieces and perhaps split work.

Just because a story is refined doesn't mean it can't be split. Developers can chat after refinement and split the work further into more stories (or just sub-task it) after refinement. There is no need for a PO to be present in this discussion as they've already prioritized the 'what' part. Developer can after talk in small groups to split/organize the work accordingly without any input from PO. If we discover something during this splitting and it changes the 'cost' of the feature, then let the PO know of this new information.

I'd even make the phrase "the developer picks up the story" optional. It happens whenever the developer realizes that the story needs to be broken down. This can happen after they "pick it up" and move it to "in progress" OR even if it's in 'Refined'. The moment to do it is when you learn you need to.