As regular readers know, Get Agile Right has a different editorial process compared to most agile blogs.
Instead of coming up with topics our authors want to write about, we research the questions that agile practitioners are actually asking in search engines and on forums—then take our time to write the best answers.
In my research this week, one of these questions turned out to be…
Is agile timeboxed?
Agile is an iterative approach to building products, solving problems, and managing projects that uses timeboxing. Timeboxing is a time management technique that works by taking the total time available, and breaking it down into boxes of time called “cycles” or “iterations.”
Agile is also incremental. Agile teams don’t create detailed and comprehensive project plans from start to end. Instead, they work in short cycles and ship in small chunks called “product increments.” A product increment is a usable, valuable, and working version of the product completed in a single iteration.
With this iterative and incremental way of working, agile teams are able to better-control risk by keeping their plans nimble and embracing change at any stage of their projects. This is why agile is an especially effective approach for projects in volatile, uncertain, ambiguous, and/or complex (VUCA) environments.
Agile works in sharp contrast to waterfall project management, the de-facto project management approach in the 20th century. Waterfall teams work in a linear and sequential way, planning out their projects end-to-end and scheduling tasks from start to end, committing to “big bang” key milestones and deadlines.
In a linear and sequential approach to project management, the goal is to make a big design up front and plan all in advance—then protect the time, scope, and budget from change as the delivery of the project progresses.
Let’s see how timeboxing helps agile teams to manage their time and control change more effectively than using waterfall methods.
How Timeboxing Works
Timeboxing is an agile practice for managing time.
When you take the total time you have available and break it down into small boxes of time of any length that works for you, you’re practicing timeboxing.
According to Scrum Inc., “Timeboxing is allotting a fixed, maximum unit of time for an activity. That unit of time is called a time box. The goal of timeboxing is to define and limit the amount of time dedicated to an activity.”
Timeboxing may sound like something completely new to you, but you’re actually more familiar with it than you think.
In fact, you’ve been practicing timeboxing ever since you learned how to read the clock and use the calendar. The seconds, minutes, and hours on the clock are essentially timeboxes. And so are the dates, weeks, months, and years on the calendar.
High-Level Planning With Timeboxes
Once an agile team has decided on the length of its timeboxes, usually two steps follow: iteration planning and budget planning.
Iteration planning helps the team and its stakeholders to determine how their timeboxes are reflected on the calendar for the given year. Budget planning determines how many iterations a team can have based on the number of team members, their average cost of work, and the financial constraints.
I’ve made a public Google Sheet that you can copy/paste into your own account and inspect/adapt for your own needs after reading this article.
How to Plan Iterations Based on Timeboxes
Some agile teams practice timeboxing based on the business planning cycle of their organizations. In this case, the biggest timebox is usually the fiscal year, which gets broken down into smaller timeboxes like quarters, months, iterations, and/or weeks.
Though a fiscal year can start on January 1st, and end on December 31, some organizations connect their fiscal year to their core business. For example, universities often start and end their fiscal years according to the school year (instead of the calendar year).
For the sake of simplicity, let’s say that Company Inc.’s fiscal year starts on 1/1 and ends on 12/31. Most calendar years have 52 weeks. If an agile team works in one-week iterations, that means they have 52 iterations (or timeboxes) in a fiscal a year. If the team’s members decide to work in two-week iterations, that gives them 26 iterations in a fiscal year.
Here’s a Google Sheet that I made to show you how timeboxing based on calendar works. Feel free to copy/paste and inspect/adapt for you needs:
How to Budget Based on Timeboxes
Some agile teams timebox based on the budget that they have available. In this case, the total amount of timeboxes that the team has available is capped to the budget constraints that they are faced with.
For example, say that we have an agile team with a total people budget of $72,000. The team consists of a Product Owner ($75/hour), a Programmer ($50/hour), and a Junior Programmer ($25/hour).
All team members work as Full Time Employees (FTEs) of the team. The average hourly rate for our agile team is therefore $50 ([$75 + $50 + $25] / 3 team members = $50/hour on average).
There are 8 working hours in a business day, so we take the average hourly rate and we multiply it by 8 to obtain an average daily rate ($400/day * 3 team members = $1,200/day).
There are 5 days in a working week, so we multiply the average daily rate by 5 to obtain an average weekly rate ($2,000/week * 3 team members = $6,000/week).
Our team has decided in two-week iterations, so we multiply the weekly rate by 2 to obtain an average rate per iteration ($4,000/iteration * 3 team members = $12,000/iteration).
Finally, we divide our budget by our rate per iteration ($72,000 / $12,000 = 6 iterations) to calculate that we ultimately have 6 two-week iterations for a three-person time with the available budget.
Since this model doesn’t take into account holidays, vacations, and sick leaves, it’s accurate “just enough” in a way that allows us to calculate how many iterations we can sponsor for our agile team based on the total budget that we’re working with—albeit with some fluctuations.
Here’s how this looks like in our example spreadsheet:
Why Is Timeboxing Used?
Timeboxing is used because it helps the organizations, teams, and individuals that practice it to stay focused on getting work done and delivering value.
A timebox is a time constraint that forces you to think about being effective (working on the right things) and efficient (doing the things right).
Temporal motivation theory goes that if you only have “this much time” to build a product, solve a problem, or deliver a project, you and your team members will be more selective about the things that you do (and those that don’t).
Timeboxes help you avoid falling victim to Parkinson’s Law. Parkinson’s Law is the old adage that work expands to fill the time allotted.
Simply said, the more time you allot to an initiative or task, the more work you’ll find to fill that time with. And you (or someone else responsible for the decision) will always find a reason to add that work to the scope. The term was first introduced by Cyril Northcote Parkinson in a humorous essay that he wrote for the Economist in 1955.
If you only took one thing away from reading this article, let it be this: Timeboxing is there to keep you accountable and focused.
Who Determines the Timeboxes
The agile team responsible for the delivery of a product or project is best-suited to determine the length of its own timeboxes (iterations).
If there’s a “best practice” or “rule of thumb” for the length of timeboxes in the organization, the agile team should nevertheless have the final say.
In most organizations, agile teams tend to work in iterations between 1 and 4 weeks long, with a preference for the shorter timeframe.
How Agilists Get Timeboxes Wrong
True to its name, a timebox is simply a box of time. Nothing more, nothing less.
Just like the hours on the clock or the dates and months on the calendar, every timebox has a start and an end. When a timebox starts, you and your team can use it in any way you see valuable. When it ends, it ends—no matter if you used it well, or not.
We’re all human. Sometimes, when we don’t achieve our goals, we have a natural tendency to try and “cheat the system” to make it seem otherwise. Some have that tendency more or less than others. I’ve seen this happen mostly in Scrum Teams in an early Tuckman stage whose members aren’t necessarily experienced with agile or the Scrum framework.
When they fail to achieve the Sprint Goal or don’t deliver the Sprint Backlog as intended, they sometimes feel tempted to extend the Sprint (timebox). As I wrote in “Can a Sprint Be Extended in Scrum?”, extending the timebox because you failed to deliver isn’t really a good idea.
If you fail to deliver value in one or multiple timeboxes, don’t try to change the timebox. Try to pinpoint and weed out the problem that’s causing you to fail in the first place. Agile leaders and teams should aim to achieve a sustainable pace of delivery in the long term.
The Bottom Line
Agile is an iterative (an agile team works in short cycles) and incremental (an agile team ships value in small chunks) approach to building products, solving problems, and managing projects.
The iterative aspect of agile is possible thanks to the agile practice of timeboxing. Timeboxing is the practice of breaking down the total time available into boxes of time called “cycles” or “iterations.” With timeboxing, agile teams can better-manage time and introduce a time constraint, which helps them to focus and stay motivated on getting things done.
