It has been proven that the more work in progress a person or a team has, the more time it takes to close tasks. On the one hand, if we are doing several tasks at the same time and we deliver them at the same time, the delivery time will be the sum of the time of doing the two tasks. However, if we work on the tasks in sequential order, the first task will be delivered earlier, and the average delivery time will also be lower.
In addition, multitasking can lead to inefficiencies that do not occur when working on a single task. One of these inefficiencies occurs when we make context switches between tasks, it has been shown that our brain needs time to adapt to the context of the new task, and this time is not productive, it is inefficient. There are times when we get stuck with a task and decide to jump to another task, so as not to lose the flow and see if we get the enlightenment that unblocks us. This may be a good approximation in some cases, but it’s important to be aware that we will now have two contexts to keep in mind.
When working in a team, this problem remains and can even be exacerbated. For example, if we are working on two tasks in two different branches, and the team makes changes to the code, we will have two branches to update. If, in addition, our code is compiled, we may have to recompile every time we change branches, adding unproductive time. If we calculate this time and multiply it by the number of developers in our team, the time lost per month can easily reach the order of working days.
In Scrum, for example, work in progress (or WIP) is limited by setting the scope of the Sprint and protecting it from injections. If the Sprint is two weeks, we know that during those two weeks, if all goes well, there will be no new work injected. The problem is that two weeks of work is already too much if we don’t manage the WIP well. Scrum does not prescribe practices to limit WIP within a Sprint, nothing prevents a developer from working on several tasks in parallel. Also on the sprint backlog dashboard it is not so obvious to see how much work in progress there is at any given moment. This is why for some time now tools such as Jira or Clickup have included kanban board visualisations for Scrum sprints. Using these dashboards is highly recommended because they give good visibility of WIP and bottlenecks that appear within the sprint, in real time, without having to wait until the end.
But kanban boards are not the only mechanism available to improve workflow within a sprint. The ideal is to incorporate the whole Kanban methodology, which through visualisation of the workflow and limitation of WIP, makes the team aware and take ownership of the production chain. This allows the team to work on quickly unblocking bottlenecks as soon as they occur, and to have a very good feeling of how the workflow is working, so that it can be continuously reviewed and improved it.
When Kanban is combined with Scrum, we have what is called Scrumban, which mantains the ceremonies and sprint work of Scrum with the observability and workflow improvement of Kanban. If you see that Scrum in your team is giving decreasing and mediocre performances, considering Scrumban may be a good alternative to change the trend.