Is There Any Value in Estimating if You're Using Kanban?

The benefits of estimating in Scrum, whether using story points or ideal days, are pretty clear. Once the team commits to the work to be done during a Sprint, at its end, depending on the work completed, the velocity of that team is determined. Thus, velocity is the total number of story points the team was able to complete during that fixed duration of time. The benefit is that the team's velocity will determine when the team will be complete with a release, for example. In this context, the duration of a release is larger than that of a Sprint. A release typically has a horizon of three to nine months, a Sprint one to four weeks.

In Kanban, things are different. The concept of a fixed duration, iteration or Sprint is not as relevant as it is in Scrum. This is because Kanban uses a Kanban board which enables one to visualize the teams' throughput, i.e. what is waiting for the team to pick up, what the team is working on now, and what is done.

Example of a Kanban Board:-

Hence, when one item moves to the right from one column to the next, it gives room for something from the column to its left to take its place. In that way, the flow of items from the left to the right never stops as items are pulled on demand. Since the first free member of the team immediately picks an item (from the left column), the concept of committing to the scope of a Sprint does not exist. Therefore, without this commitment that we see taking place at the beginning of a Sprint in a Scrum, and with the absence of the Sprint concept itself, how do you determine velocity? Since you cannot determine velocity in that way, the question is, is there really value in estimating in Kanban?

Yes, there is. There are two reasons one estimates. While one reason is to know how quickly one can meet a release or project deadline, the other is to use an estimate as input to determine the order of work to be done, i.e. the priority. Along with business value, including answering questions, such as what population will be affected by the change, an effort estimate also affects the priority of the change, as it is an indication of the complexity of that change. Therefore how complex the change is, helps in determining when to do it, i.e. its priority. A complex item can be deferred and a simpler item with a similar value to the business can be given higher priority. Since in Kanban you still need to prioritize your work regardless of the "pull on demand" theory it employs, the answer to the question whether effort estimation is required is yes, it is.

Yet another reason to estimate, regardless of which Agile methodology one is using, is to help the Product Owner determine whether an item needs further grooming prior to the team picking it up and start working on it. The sort of grooming I am referring to is not the one done with the team during grooming sessions, but the grooming the Product Owner does alone without the team prior to sharing that work item with them. Here, the first round of estimation, long before an item is picked up by the team, is done using a group estimation technique, like planning poker. After the high-level discussion about the items, an estimate is attached. This estimate is an indication to the Product Owner what work he or she needs to do on the item prior to it being available to be pulled for the team to work on. For example, if, in this high-level release planning meeting, one story is determined to have 5 story points and another to have 20, that is an indication to the Product Owner that the second item needs some "private" grooming before the team can pick it up.

Therefore, to conclude, as in Scrum, estimating also has its benefits when using Kanban but it is important to know exactly why one is doing it in both cases. In Kanban estimating with the team is not done for the exact same reasons it is done when working with Scrum teams.