kspe

If you are a software engineer, you and your team most likely use some board to manage your project. That board, most likely, has labeled columns, and each one of them contains tickets. That is what we used to as developers, but have you ever wondered why? Why we need those columns? Why we move those tickets around?

Lately, we've had an interesting discussion about whether we should merge some columns on our board or not. It was about combining the “Ready for Review” column with the “Code Review” one. Intuitively I knew we should merge them but was not able to provide a convincing argument. If there is one thing I hate during a discussion, it would be a lack of proper argumentation for my intuition.

I like to get back to basics when it happens, so I've asked myself: “why we need those columns at all?”. In the project, in the team, why we use the board at all? Can we have one column, and when a task is planned to be done, it is kept in that column. When it is done, it gets removed? A bit extreme to what we've used to but still, the question is valid. At that point, we would miss fancy reporting, graphs, nice board to show on standup but would it hurt our team to what it should do, delivering values to customers?

What would happen if we add “In progress” and “Done” columns and the first one becomes the “To Do” column? What is the benefit of having tasks in the “In progress” state? We can see what is being worked on but why we need to know it? Progress tracking? We can track progress by checking what is removed from the “To Do” as this means a task was done. With the “In progress” column in place, we can track the workload. We know what the throughput of our team is.

All right, that makes sense but still, what is the benefit of knowing that? If we are a team of five and all the time the “In progress” columns contains five tickets, from which two of them stay there for three days can we be proud of ourselves or not? For sure, we maximized utilization of human resources as this column maxed out. Is that a good thing? Hard to say, but it seems there is a benefit of having the “In progress” column.

What if we split that one up further, so we end up with “To Do”, “In progress”, “Code review”, “Done”. Now we end up having, most of the time, two tickets in the “In progress” and four tickets in the “Code review”. What if the opposite happens? Now we can see, like the last time, the throughput, but there is a piece of additional information on the board. Now we can identify bottlenecks. If tickets “get stuck” in code review, it means we have a blockage, and we should focus on that stage to improve it. How could we do that? We could split that column even further into “Ready for Review” and “Code Review” to see whether tickets are waiting for code review to start or they get stuck when the review started but taking too long.

Thanks to that thought experiment, I recalled all I've read about the Theory of Constraints and how Kanban shows resemblance to ToC (or the other way around, unsure which one was first).

That was my A-HA! Moment. So we need to indicate the process that we are going through to measure a team throughput (at least one column reflecting the “in progress” state). If we need to identify bottlenecks, we need to split that column further to be more accurate in pinpointing where we are getting stuck.

That makes sense to my inner me. We are getting back to the initial question of whether we should merge our two columns or not. I think we should, as splitting columns should happen when we notice that one of the columns becomes a bottleneck. If we do that prior, we are doing premature optimization. A number of columns should be minimized – not becoming a 1:1 reflection of all possible states in the process.