Timeboxing can be a useful time management tool within software development – or any industry. Timeboxing is the act of defining the length of a sprint and its associated events – planning, daily stand-ups, etc. Put simply, it gives team members and other stakeholders an idea of the expectations placed on their time throughout a project – from sprint planning meetings to gathering for the sprint retrospective. Individual team members can also choose to apply the concept of timeboxing to their own tasks.
Every member of a development team, from product owner to developer, can benefit from understanding the key benefits of timeboxing for themselves and their teams. For product owners, implementing timeboxing can be an important part of planning the sprint. Some of the main benefits of timeboxing, aside from defined expectations on team members’ time, include decreased risk of longer-than-needed meetings and a better development flow. In software development, the sprint backlog can feel long while the days feel short. Timeboxing can help boost motivation by setting boundaries around a specific set of tasks to accomplish.
This motivation isn’t imagined either, the temporal motivation theory posits that, among other things, humans typically discount future rewards for immediate ones – but the level of discount is tied to a person’s sensitivity to delay. While some people may not be as sensitive to delay and thus more likely to focus on immediate rewards at the expense of future ones, i.e. procrastinating others see delay as a reason to discount future rewards less so they are not as caught up in immediate rewards. If given more time to complete tasks, some developers may push them off to focus on more immediate rewards like reorganizing their desk or cleaning out their inbox. However, if given less time, say with a shortened sprint, many developers will feel sensitive to that delay, or amount of time, and forgo the simpler pleasure of inbox zero in order to accomplish the tasks and experience the future reward of a completed spring.
While some people may not be as sensitive to delay and thus more likely to focus on immediate rewards at the expense of future ones, i.e. procrastinating others see delay as a reason to discount future rewards less so they are not as caught up in immediate rewards.
Timeboxing fits into this theory by taking a long period of time – a one-month sprint for example – and turning it into several smaller time periods in which even the most delay-tolerant person finds motivation. It’s not as easy to put things off when an extended period of time is cut short.
Of all the best examples of timeboxing, the one that struck me happened in my college literature course freshman year. My professor divided the major milestones of research paper writing in an effort to instill best practices in her class of newly minted college students.
Rather than set one due date almost four months in the future to turn in a final draft complete with bibliography and thesis statement, she set four. One for an annotated bibliography three weeks from the first day of class, another for a thesis statement, a third for rough draft, and the fourth for a final complete paper. It was difficult to delay in the face of sequential deadlines with specific tasks assigned to the timeboxes between.
Scrum versus other development processes
Scrum is one of several planning processes that fit within the agile philosophy. Agile is one way to approach project management that relies on an interactive process whereby stakeholders, including clients, are involved throughout. This stands in contrast to other philosophies such as waterfall, which with roots in manufacturing relies on a sequential process where the next step is not taken until the previous one is completed. Kanban is another philosophy in which workload is constantly measured alongside the work in progress – giving teams a degree of flexibility not found in other approaches. The scrum framework is lightweight and particularly receptive to the practice of timeboxing because the different phases can easily adjust to accommodate stakeholder input, unexpected changes in workload, and project direction changes due to client needs.
What is timeboxing in scrum?
Timeboxing in scrum applies a definitive time limit to the phases, meetings, and oftentimes tasks involved in the scrum methodology for agile project management. Scrum is timeboxed by default – but there is no default for the defined set of time, or ‘timebox.’ The length of the sprint is chosen by the product owner and sets the tone for the length of other scrum events, as you’ll read below. The sprint length takes into account the goals decided on in the sprint planning meeting and the capacity of the team. Aside from defining the distance between goal posts, timeboxing in scrum gives each team member an opportunity to use the timebox at hand to divide up tasks. With order stemming from a clear picture of tasks to be completed in the timeframe, team members can feel more motivated in their work.
Timeboxing for scrum events
Within the agile methodology of scrum, timeboxing packages each scrum event in neat even sets of time. It acts as a strong foundation for one-time and recurring scrum events by clearly setting expectations for every team member’s time.
Starting with the sprint itself, the scrum team including the product owner, scrum master, and development team should choose an appropriate length of time relative to the number of backlog items. For the sake of this article, let’s assume a three-week sprint for delivery of an app iteration that fixes some common bugs reported in user stories. This is the sprint goal.
With a team assembled, it’s time to plan out the sprint based on the sprint goal. While the example shared above focuses on a new iteration for an app, sprint goals can range from a small section of backlog items to a new product yet to hit the market. The length of this planning meeting can be determined by the length of the sprint. For an easy formula based on recommendations from the Scrumguides.org, assume a max of two hours for every week of a sprint. With a three-week sprint, this equates to a max of six hours spent on planning all the three weeks.
This is the most brief of sprint meetings and can be accomplished in 15 minutes per day. Also known as the daily standup, the timebox on this meeting means your team looks for brief overviews that fall generally into three categories of updates: what happened, what will happen, and roadblocks on the path.
Following a ratio similar to the sprint planning, the sprint review meeting can be timeboxed as a max of one hour per week of a sprint. For a three-week sprint, this equals a three hour sprint review. Sprint reviews put the deliverables to be demonstrated for inspection by stakeholders.
Reviews dig into the deeper details of what went well and what didn’t that were discussed in daily scrum meetings. This allows teams to make adjustments for future sprints. Since teams have intimate knowledge of members’ day-to-day thanks to the daily scrum, these meetings do not need to be lengthy like demonstrating deliverables for clients or planning an entirely new sprint. Plan for 45 minutes of meeting max for every week of the sprint. In a three-week sprint, this looks like a maximum of two hours and fifteen minutes.
Timeboxing takes the most daunting of projects and boils them down into manageable pieces. It’s a part of scrum, but the parameters – like spring length – are unique to each project. Like many productivity tools, it can work with what is known about human psychology – specifically how people find motivation with clearly defined deadlines – to support goal achievement. Each scrum event can be timeboxed and individual team members can use the same principles to define their time dedicated to tasks each day.
One of the most useful features of timeboxing is its simplicity. You don’t need a fancy tool to get started on the practice of timeboxing and when you’re ready, it fits easily into any number of project management tools. Consider an app like Clockwise that supports both timeboxing for teams and individuals through analytics to assess team bandwidth and an emphasis on focus time for team members to accomplish tasks without interruptions. Whether you’re taking this article to your next team meeting or testing out the method in your own day-to-day, take timeboxing for what it is: a part of the larger productivity puzzle.