Kanban to organize development of new software [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

In our team we are evaluating to use the kanban board as an organization tool for software development. The development phase will take about 6 months with a team of 5. We have as input all the functional requirements agreed with the client, business rules and use cases - in other words, macroscopic requirements. We will convert these rules in stories to be "atomic" process units for the kanban board. The kanban itself will be used as a performance evaluation tool and progress roadmap. The Kanban "prescribes" to have a fixed amount of stories for each stage, but as the software is new and complex, the "stories" will be probably some hundreds - so I guess that putting all the stories in the backlog at the beginning of the development wouldn't be a smart move.

What would it be the best practice for this case?

Answer 1

First, few teams set limits for backlog. Kanban advises work in progress (WIP) limits. Items in backlog are rarely considered "in progress."

Second, considering you, more or less, know the scope of the project it wouldn't make much sense of forcing yourself to artificially limit number of items in backlog.

At the same time you're right that putting a few hundreds items in backlog makes no sense. The board would be overcrowded and its usefulness would drop significantly.

Typical strategies to organize backlog is such cases include:

• Keeping epic stories/features in backlog and splitting them into detailed stories/tasks only when you start working in them. This way you have far fewer items, while you're still able to deal with detailed tasks on development stages.

• Stacking stories which are going to be a part of the same part of an app. If you already split your scope, there's no point in artificially hiding this information. You can, however, stack work items that are connected or will be done at the same time. It makes backlog cleaner and, once you start building the items, you can unstack them totally easy.

• Staging backlog. If you have a rough plan how your development will be going you can have a couple of stages of your backlog. Early one which is a box where you store all the features you will build (it can be even a physical box attached to the board) and later one which shows only work for the very next time period. This way you see fewer items on the board, yet still, technically all the work is there.

Of course mixing all these ideas is possible, and even encouraged, whenever it seems reasonable.

BTW: You can see visualization of a couple of these techniques in this presentation (slide 21).

Answer 2

I must disagree: limits in backlog is a possibility. Probably not in the input column, but for instance if process has some prioritization columns, highest priority column can contain a limit thus saying that one may not push to many high priority tasks, because WIP cannot maintain such pace and they will be hanging dead there.

Kanban board looks like this

Answer 3

Henrik Kniberg in his free book about Kanban describes how setting WIP limit to backlog helps focus on most important functionality first.

I think this is good strategy especially for product owner. Backlog contains only stories to be developed in upcoming period while other stories might be in mind map or 'wishlist'.