Time boxing

Time boxing is quite a simple concept. You specify an activity and duration and you’re done. The only basic rule is that you do not perform the activity longer than the specified duration.
In agile teams, time boxes are used everywhere. In Scrum, stand-up meetings are restricted to 15 minutes, sprints are time boxed, just as the planning meeting or the sprint review. When using planning poker, discussions are usually limited to a few minutes at a time and programming pairs switch roles or even programming partners after some predefined period. I’m sure you can add a few more examples yourself.

So what is the reasoning behind all of this? Why are time boxes useful?

One reason is the ability to focus. If you’re anything like me, you sometimes are easily distracted by an incoming email, a question from a colleague, the sudden urge to use the washroom or anything else that is not directly related to the task at hand. In many cases, the task is interrupted and we give in to those distractions. The reasons are obvious, just look at the example with the incoming email. We don’t want to forget reading this email, what if it’s important and urgent and needs immediate attention? Alternatively, not dealing with this email will keep it in the back of our minds, to remind ourselves that it still needs to be done, and that way continuously shifting our focus between the task at hand and the reminder that we need to deal with that potentially important email. Time boxing can help in this case. When you know when the current time box finishes, you know when you can deal with that email, so there is less anxiety to forget about it or deal with it in time. A quick note on your to-do-list or a sticky note on the wall is all that is required before you can go back to focussing on what you were working on. The Pomodoro Technique is a great example of how to use time boxes to improve your focus.

Time boxes also prevent us from going down a rabbithole once in a while. Have you ever been working on e.g. a design that you were never quite happy with? The design worked, supported all features we needed at the time, but something wasn’t quite right? How many times have you continued working on that design to, a couple of hours or even weeks later, end up with a design that was only slightly better or not better at all than the first one? How much value did you actually get from spending that extra time? Especially with activities like planning or designing, we tend to want to make things perfect before we continue with the next task. The problem is that we usually can’t make things perfect because we don’t have all the information we need. In fact, we usually can only get that information by making the abstract concrete: execute the plan or implement the design. Time boxes force us to accept the version of the design we come up with within the time available as the best version at the time. Not only does this allow us to implement the design faster, it also allows us to get feedback faster and to improve the design.

There are more benefits to time boxes, but I wanted to stick with the most concrete ones for now. Also, you might get benefits from using time boxing other people haven’t even thought about, so feel free to add some suggestions in the comments!