Recently my brother took it upon himself to teach me Scrabble. On our first try I played the word timeboxing. By the numbers on the top of the tiles I could tell I was to be a winner. He challenged the word, and pulled out a dictionary. And that is how I got zero points on that turn.
Clearly my brother and the authors of the dictionary he used are agile noobs! Will you not join me in educating them?
What is a time box?
In the simplest terms. A time box is a fixed period of time allocated for carrying out a planned activity.
We all have used time boxes in our life. When you schedule to do your morning 30 minute run, that is a time box. When you have a 2 hour meeting, that is also a timebox. A three month semester, still a time box!
The concept of timeboxing is all around us.
In agile software development, timeboxing appears all over:
- Sprints
- Sprint planning meetings
- Daily scrum meetings
In fact as a schedule oriented practise, scrum explicitly seeks to cut the scope to fit the schedule rather than adjust the schedule to a bloating spec document.
Why time box?
Scrum has basic principles that power it: Visibility, Inspection and Course Correction. The 3 core principles of scrum.
Timeboxing is the meta principle.
When you time box, then certain qualities come into play:
- You meet deadlines. No more extending the date, if it doesn’t fit it’s chopped off. This then means there is time for Inspection and Course Correction.
- Incremental progress. By timeboxing, you can only do limited amount of work at any one time box. As such the project gains Visibility and has natural breakpoints to allow for Inspection by all stakeholders.
- Prioritization: Faced with short time windows, the client and the developers have to prioritize what is to be done, effectively reducing any waste on the project.
- Engaged developers: In my experience, I have come to find that more than money, challenging project or even a good client, clear sign of progress to a big goal is the biggest motivator. While not a core scrum principle, you really can’t do much with burnout devs.
How to time box
We already know how to time box, just schedule a time to do stuff. The challenge is actually sticking to the time box.
Here are some of the tricks I have found to work:
- Insist on wholesome adoption of Scrum. That way you can point to its rules when someone wishes to violate the timelines.
- Assign estimated time to tasks to be done and ensure to never put in more tasks than can fit the time window
- Don’t delete suggestions, put them in a backlog. No one likes to have their ideas thrown in the garbage can (even if it deserves it). So instead put ideas that can’t be executed on this time box in the backlog to be reviewed in the next planning meeting
- Adapt. It will take some time to figure out the time box size that best fits your team. Don’t fight the learning process, instead play with the time. Whilst I advocate for 3 week sprints, there is nothing wrong with a 1 week sprint or even a 5 week sprint. One of the most senior developers I know leads her team using 5 week sprints and they are a super effective team.
I trust that you will be implementing time boxing in other areas of your life! Say to keep it all in balance?
Do you use timeboxing regularly? Get to me on my twitter @ jchex or on the comment section below.
