Timeboxing

Avi Siegel

•

5 min read

What is timeboxing?

Timeboxing is a time management technique used on Agile teams. It involves setting a specific, maximum amount of time for a given activity, by which point either a conclusion is reached or the team members involved move on to the next activity. The purpose is to ensure that work remains focused and does not take more time than it’s worth.

What are the goals of timeboxing?

The primary goals of timeboxing are to:

  • Avoid spending too much time on a given activity

  • Allow some time to be spent on a given activity, especially under circumstances where it’s unclear how long it would take from start to finish

  • Ensure that the teams stay focused on the task at hand

What is involved in timeboxing?

The core of timeboxing is simply the act of spending only a maximum amount of time on a given activity. This can be broken down into the following steps.

Decide to timebox

The ever-important initial step is to recognize that timeboxing an activity would be useful in the first place. This is generally helpful when there is a desire to allow some time, but not too much time, to be spent on said activity.

Examples of activities that may be worth timeboxing:

  • Meetings and ceremonies: Meetings are the classic example of timeboxing, as they are set on a calendar to occur within a specific time window. Still, it isn’t uncommon for meetings to run over when conversations go long. On Agile teams, especially during official ceremonies, the time limit becomes much more strict. For instance, when a standup is timeboxed to be 15 minutes long, that is quite explicitly the maximum amount of time that should be spent in the ceremony - else the team tends to get too in the weeds regarding their work, going against the goal of having only brief updates during standups. The same applies to other ceremonies like Sprint Planning, Backlog Grooming, and Retrospectives, albeit with longer timeboxes.

  • Discussions-within-discussions: When a subtopic comes up during a meeting, you want to be careful not to waste too much of the team’s time, as not everyone may be needed for the conversation. In these situations, it may be worth spending 2 minutes on a conversation to try to reach a resolution, while any more time would warrant pushing the rest of the discussion to a separate meeting with only the most relevant team members invited, so as to not waste the rest of the team’s time.

  • Bug fixes: Before looking into a bug, it may be unclear if it is a quick fix or something that could upend an entire part of the codebase. As such, it could be worthwhile to give an engineer, say, a 1-day timebox to try to fix the issue. If any more time were to be necessary, it would be beneficial to consult with the product manager or engineering manager to confirm whether or not it’s worth continuing to invest time.

  • Spikes: Spike tasks are designed to give engineers space to look into how to perform a given set of work, without requiring that the end state be that the work itself is complete. For example, it could be useful to spend 2 days documenting a technical implementation plan which would provide understanding as to how long the work would take - in that way, the core work could be prioritized (or not) depending on how large the effort would be. A timebox would work well here to get enough information documented, without necessarily documenting all possible scenarios and edge cases.

Set the timebox

Once the decision is made to timebox an activity, the next necessity is to state how long the activity will be timeboxed. Of course, the answer to that is context-dependent.

  • Meetings might be timeboxed to 15, 30, 60, or 120 minutes

  • Mini-discussions might be timeboxed to 2, 5, or 10 minutes

  • Tasks might be timeboxed to a small number of days (or based on task estimation)

Pro Tip: Generally, timeboxing becomes less useful for larger sets of work. For instance, it could be useful to aim to spend no more than 3 sprints on a given feature. But, the reality is that if the feature still needs more work, the team isn’t simply going to move onto the next feature, thereby losing all the time and effort they put into the incomplete feature. That said, you also wouldn’t want development of said feature to go on without end, so being transparent and vocal about appropriate time investment is still useful - it’s just not necessarily an apt use case for strict timeboxing.

Perform the timeboxed activity

When it is known how long should be spent on the activity, the team member(s) involved can move forward with it.

It is important during this step to keep an eye on the clock or calendar (depending on the length of the timebox).

  • For activities measured in mere minutes (e.g., discussions), you’ll need to be more vigilant so you don’t go (too much) over the allotted time.

  • For activities measured in days, the time to check in on status would be during standups.

Pro Tip: For shorter activities (those on the order of minutes, not hours or days), consider using a timer to stay true to the timebox limit. This will take the pressure off of someone needing to stare at the clock. But also, note that this takes away some of the flexibility you could otherwise afford yourself (not to mention how jarring it may be for an alarm to go off).

End the timeboxed activity

Ending a timeboxed activity is different from ending a non-timeboxed activity in that the end doesn’t necessarily mean that the activity has been resolved.

As such, when the timeboxed amount of time has been spent on the activity, if a conclusion has not yet been reached, you’ll have a decision to make. You can opt to do one of the following:

  • Immediately call an end to the activity

  • Allow a reasonable (but minimal) amount of time to quickly resolve the activity

  • Officially extend the timebox by another timeboxed amount of time (i.e., go back to the first step)

Pro Tip: Don’t be too strict; give yourself the flexibility to make the decision that makes the most sense for the efficiency of your team. For example, if you set a 2-minute timebox for a conversation, but it feels like with 1 more minute you’d reach resolution, you might choose to try to naturally close out the discussion. That would likely be much more efficient than scheduling an entire separate meeting to discuss the topic at hand.

Best practices for timeboxing

  • Use realistic timeboxes. Participants should be able to conclude a meaningful amount of the activity without going too long. Underestimating will lead to frustration, and overestimating defeats the purpose of timeboxing.

  • Be flexible when reasonable. Remember that the overall intent is efficient use of the team’s time. It’s not necessarily going to be the best use of time to schedule a follow-up meeting simply because you refused to allow for an additional 30 seconds to close out a 5-minute timeboxed conversation.

  • Be strict when you have to be. Adding a small amount of time is one thing; letting 1-day tasks linger for 2, 3, or more days only serves to enable the very inefficiencies timeboxes are meant to eliminate.