The three primary development models used today are a sequential model (e.g., Waterfall), a timeboxed iteration model (e.g., Scrum) and a continuous flow model (e.g., Kanban). The blog https://kanbanmentor.com/why-do-companies-still-use-waterfall-today/ focuses on the sequential model. This blog focuses on comparing a timeboxed iteration to continuous flow model. It focuses on the waste inherent on most scrum teams moving work back and forth between the product and sprint backlogs – an activity that simply does not exist when executing under a continuous flow model. This is one important consideration for those who are comparing Kanban vs Scrum.
Let’s assume a Scrum team is executing 2 week iterations (i.e., scrum sprints). Every 2 weeks, the team holds a planning meeting to determine what product backlog items to move to the sprint backlog. The team uses their best guesstimate to determine how much work to pull in to the sprint. Typically this guesstimate is derived via a combination of considerations. First is how much work this team completed in past sprints (i.e., the team’s velocity). Then any nuances of the upcoming sprint are considered. For example, any planned vacations or any holidays that happen to fall within the sprint. And finally, the gut feel from the team is used as a sanity check. It is not easy to accurately predict exactly how many items will become 100% complete.
Any unfinished work remaining in the sprint backlog at the end of the sprint, moves back to the product backlog. If these items are still the highest priority, the team moves them once again to the next sprint’s backlog. These items will hopefully complete in the next sprint. If these partially completed items are no longer the highest priority, they remain in the product backlog for the team to move to some future sprint.
This difficulty to accurately predict an upcoming sprint’s workload is further exacerbated by the fact that work is not deemed complete unless it is 100% done by the end of the timebox (i.e., developed and tested). Let’s assume a team has both developers and QA/testers. Often towards the end of the sprint, developers are done coding and unit testing all items forecast for the sprint, and the final sprint items are being tested by QA. At this point, developers must decide what to do. They can help the testers test these final items. They can do something not planned for the sprint (perhaps working on lower priority items such as a low priority bug list). Or they can anticipate what items will be added to the next sprint and bring new work into the sprint knowing that it will not get completely done. If they choose the latter, which is often the case, this work will move back to the product backlog at the end of the sprint.
All of this forecasting of work for each and every sprint; the movement of items back and forth from the product to sprint backlog and potentially back again; the potential inefficiencies of developers towards the end of the sprint; and the fact that unfinished items remain on the product backlog if priorities change are all examples of waste when comparing to a continuous flow model. In a continuous flow model, work does not move back and forth. The team continues to pull the highest priority items to work on. There is no forecasting of work for the next 2 weeks because there are no timeboxes. There is no point every 2 weeks that the developers must decide what to do since work continuously flows. Moreover, no partially completed work moves back and forth. Work flows smoothly as long as no bottlenecks occur. See https://kanbanmentor.com/what-do-i-do-if-my-team-hits-a-bottleneck/.
Kanban vs scrum – waste removal
One of the big focuses of Kanban is removing waste. A continuous flow versus timebox model discussed in this blog is just one example. See https://kanbanmentor.com/the-emperor-has-no-clothes-why-do-we-estimate/ for yet another example of a common waste – estimation!