How are boundaries established in Kanban?

Question

If we just take stories to the 'to-do' column when we have capacity, imagine the situation where the PO keeps on feeding more and more requirements. In Scrum you do the planning and define what stories to work on for the next sprint. How do you plan this in Kanban?

Answer 1

Kanban is a pull system. Your PO can push how much they want into a TODO column, but it's still the people doing the work that will have to pull from the top of that column once they have capacity.

When work is pushed, what can happen is that "too much" work is pushed. If it exceeds the capacity of those doing the work, things will start to be delayed while waiting to be worked on, or because a lot of context switching is introduced that only makes everything take longer (maybe also introducing defects because of lack of focus, defects that then need to be fixed, adding even more time to completing the work).

So, in Kanban you pull work based on what you know you can handle, and you also make that visible with WIP limits.

In your comment above you say that:

[...] sometimes the customer keeps on asking more and more features, add this, change that

Well, they can do that. Kanban is Agile, which means it welcomes change. If the customer realized something, they can ask for changes to better solve their needs. Often, people see something and realize they needed something else. That's why Agile says to deliver working software frequently, so that you collect feedback and validate what you are building.

Obviously, there are changes and there are changes. There needs to be a balance between the customer putting an effort on deciding what they want before you build them something, and making changes after you've built it. If you have a very large number of changes demanded after the fact, then maybe you need to sit down with the customer and find a way to make the whole process more efficient.

You will still need to respond to changes (this is not about forcing the client to provide very detailed upfront requirements), but not so much changes as to completely ignore the fact that the customer needs to think about what they want to be built.

Answer 2

The Kanban Method defines the whole notion of Upstream Kanban, which is the application of Kanban to upstream processes, especially backlog prioritization and grooming. The process of prioritizing stories is a continuous one in general. However, Product Owners can choose to prioritize the next set of stories in sync with the dev team's delivery cadence.

In our own product development, we have an upstream Kanban board which is our Roadmap Planning board - where we prioritize Themes and Epics and break them down to User Stories on a continuous basis. But twice a month, we hold a Replenishment Meeting where we prioritize (or reprioritize) the stories that are of most importance at that point of time. We plan for up to 4 releases upfront - and after each release (we do releases twice a month), the next set of user stories is provided to the Dev Team's board.

Here's how our roadmap board looks - the top two lanes are for Themes and Epics - the bottom lane is for Stories that are grouped by priority in the various columns. The rightmost column is the "Next Release" column, the ones to its left are N+1 to N+3 release columns.

During the next release planning, our Dev team pulls the appropriate number of stories into the Dev board - which is a separate board shown below -

The process that your POs follow (along with leadership) of identifying and prioritizing themes, epics, and user stories (or whatever your terminology might be) can be mapped on an upstream board. The process - and frequency - of moving cards from the roadmap to the dev team's "Ready" column is something you need to define in collaboration with your PO, the dev team, and your stakeholders, based on how often do you need to replenish the Dev Ready column so the Dev team is not starved of work, nor overloaded with work.

You might find this writeup on Upstream Kanban useful.

Ultimately, the Kanban Method starts with visualizing what you do today and then improving incrementally based on bottlenecks observed across the entire system (ToC principles). So, you should feel free to experiment with various Kanban board designs to arrive at what works best for your system.

Hope this helps.