Is Timeboxing a Sprint necessary?

Co-written by Shalom Chin and Kaitlyn P.

Out of the five Events in Scrum, Scrum practitioners would spend the least time elaborating much about the Sprint. It is usually written off as a timeboxed Event which can last from one to four weeks. It acts as a container for the other four Events. The merits of timeboxing are worth some mention since timeboxing is fundamental to Scrum and its Events.

Nir Eyal, the author of “Hooked”, writes on his website , that timeboxing is “the most powerful time management technique you’re probably not using”. The Pomodoro Technique is all about timeboxing so people are able to effectively manage their time to work on tasks without distractions.

In the context of Scrum, timeboxing is also about focusing our efforts but the focus is to achieve the Sprint Goal. When timeboxing is too long, there is a tendency to forget about the purpose or why we are doing all the work. Having shorter time frames for a timebox helps to keep the goal in our short-term memories at the top of our minds.

Besides focus, we want to be able to manage the risks of delivering a product that does not satisfy the customer. With waterfall project management, delivery of the product to the customer happens at the end of the project lifecycle. This risk substantially increases the longer we delay putting the product in the field for testing. The key is to study how our customers interact with the product so that we can get feedback each time the product has been deployed. This also reduces the risks of failure in any integration among different components.

By trying to fit our work in a Sprint, we have to break the work down into small batches. With small batches of work, people can start work and finish it quicker, so that the lead time of each work can be reduced. This enables faster deployment of small chunks of value. The more frequently the product is launched, the faster we can detect quality issues. Although rework is something we wish to minimize before launch, there are times in which defects can be better detected when we can observe the product being used by our customers live in action. Although the product may be incomplete and lack every feature desired by the customer, the frequent piecemeal delivery to the hands of the users earns the trust of both our customers and stakeholders.

Timeboxes also allow Scrum Teams to have a breakpoint to stop and reflect on the changes they need to make towards continuously improving. The end of the Sprint is an opportunity to review the work, the customer value, the happiness of the team, and the internal processes. This allows the team to think of a plan to address the challenges within the team and with the Product. Experiments for the product and the team’s processes can be developed for the upcoming Sprint to test assumptions. Moreover, timeboxing limits the cost and time that can be spent on the experiment to derive a conclusion.

Finally, timeboxing acts as a self-constraint to choose your battles wisely by prioritizing what matters first to the customer because it is ex. With limited time, resources, and people availability encapsulated within a timebox, the Product Owner will have to choose the most important items to work on. Once those backlog items have been pulled by the team into the Sprint Backlog, there can be no changes during the Sprint unless new information comes up to show that the goal is no longer relevant in bringing customer value.

In conclusion, the Sprint comes with many benefits and can work well in the context of developing products. Adjusting the length of the Sprint would depend on the nature of the product.

For the Mandarin version of this article, visit here .