Shrinking Time Box

Timebox all things. A “timebox” creates a strict deadline, a finite amount of time to complete tasks. You stick to the timebox and go with the results you have, whatever they may be at the time. Although you might usually think of iterations as timeboxed development cycles, the concept of a time box extends to meetings, the amount of time to be stuck on a bug before asking for help, and more.

Pain Points

  • Product deadlines that never end
  • “Death March” projects
  • Lack of product quality, lack of innovation
  • High-risk long term, multi-month or multi-year deadlines
  • Finding out too late that you built the wrong thing


  • A time box for a meeting ensures that you reach a decision, instead of languishing in (often paralyzing) indecision
  • A time box for team members who are stuck ensures that they‘ll seek help, and not remain stuck indefinitely, wasting more valuable time
  • A time box for development should be long enough to accomplish a small set of tasks/features, but short enough such that all the work is easily replaceable (to minimize risk)


  • Any timebox shortened over time (Significant Boost)
  • Working, tested, features shipped and development timebox length not changed (Boost)
  • Any time box consistently padded with too much time (Setback)
  • No one requests help when stuck (Significant Setback)
  • Any timebox lengthened or canceled (Significant Setback)


✓ Critical ❑ Helpful ❑ Experimental

Meeting timebox Adoption Experiment

Steps to first adopt this habit:


  1. When scheduling a meeting, specify the result: the decision or the desired outcome, and the absolute maximum length of the meeting


  1. Run the meeting at the scheduled time, and at the end of the time box, conclude the meeting with the best alternative reached so far. It may not be the best answer—but it’s the best answer at the moment

Evaluate Feedback

  1. Did a firm deadline force the discussion to the essential points?
  2. Was the team able to proceed faster with a decision in place?

Development timebox Adoption Experiment

Steps to first adopt this habit:


  1. Set the time box length to two weeks. Note this is the beginner value, over time the duration will shrink to become infinitely small and flow becomes continuous
  2. Based on business priorities, the team chooses which working, tested features they will ship during this time box. The development time box includes all activities that the team needs to perform. These activities will address ThreeTrackAttack items as well as any maintenance, bug fixes, infrastructure setup, etc.
  3. The team works only on these items during the time box


  1. The team works on the items they’ve selected
  2. The team delivers the working, tested, features and items during the time box. Items that weren’t completed are put back for prioritization, which often means they will move into the next development time box
  3. Continue for 2-3 time boxes at a minimum

Evaluate Feedback

  1. Did the team ship all the working, tested, features that they chose to work on? If not, reduce the amount of work pulled into the next time box to compensate
  2. Are the working, tested, features actually working, and tested, and in a shippable state? If not, fix that for the next time box
  3. Using SmallBitesAlways and StorySlicing how much can you reduce the timebox? The goal is continuous flow

“Stuck” timebox Adoption Experiment


  1. Set a time limit for anyone to be “stuck” on an issue (a bug, design decision, requirements question, priority) of two hours.
  2. At the end of two hours, if you are still stuck, ask for help. At the end of another hour (three hours total), if the issue persists, call a timeboxed team meeting to discuss.


  1. Make sure everyone knows the rules for getting unstuck (note, this idea is not for developers only)
  2. At the TeamSync, discuss any stucks and things discovered or learned

Evaluate Feedback

  1. Did the team request help when stuck during the time box? Reinforce the need to follow the rules for getting unstuck
  2. Did the team evaluate a course of action for stucks? Are stucks discussed and resolved?

What Does it Look like?

One of the biggest problems with old-fashioned, plan-based software projects is the long periods of time with no feedback. In those dark times, teams typically coded like mad. Then just before an impending deadline, they’d start holding demonstrations only to learn they had overlooked key aspects of users needs, or that those needs had changed.

Early Agile methodologies discovered that shorter feedback loops enabled teams to adjust their aim and actually hit the target the customer wanted them to hit. Instead of arguing with the customer to convince them they wanted what we’d delivered, we showed them our work and discovered what they really wanted.

How much of your work are you willing to throw away?

How much of your work are you willing to throw away? Make that the length of your development time box. The popular notion of a two to four week “iteration” is too long. You want feedback faster. You can’t work any faster than the feedback you receive.

But in the beginning you might want to stick with the common approach that dictates “no requirements changes” within the timebox, and “one big release at the end.” However, those are not “responding to change over following a plan.” If you’re transitioning from much longer release cycles (months or years), however, start with a two week time box with a release at the end.

This short, artificial boundary forces the team to do just enough analysis to understand what the larger task looks like, and how to decompose that work into smaller units. Studies show that development efforts have higher success rates when tackling smaller amounts of work. We take advantage of that.

The timebox also provides a mechanism to identify teams with problems early. If a team struggles to complete working, tested, features within the time box, perhaps it’s a random, one-time issue (yes, problems like that do still crop up). But if a team consistently can’t make significant progress after multiple time boxes, while other teams can, that’s good feedback to indicate which team needs help. Instead of waiting six months or a year to discover that a team is struggling, you’ll know in a few weeks, and can work with the team right now.

Timeboxes also boost morale. There’s something inside of us that likes to succeed. We love to cross finish lines. We can harness that desire to win and provide a finish line every two weeks. It’ll help everyone learn more quickly when we fall short, and build momentum quickly when we succeed.

But after developing this way for a while, you want to begin to “shorten the timebox” by relaxing the big ceremony at the end. Instead of one release at the end, release several times within the time box period. Address changes as they occur rather than waiting, if it makes sense to do so.

The goal is to continuously deliver value and user abilities.

Remember, a development timebox is a starting point, aimed at helping the team transition from a 6-12 month (or longer) release cycle to trunk-based development with continuous integration and deployment.

Shrink the time box until delivery becomes continuous.

In order to accomplish the tighter feedback loop, we recommend adopting the TracerBullets habit to enable key features to be demonstrated as early as possible during development.

What about unplanned work? How best to handle emergency bug fixes, maintenance tasks, and so on that come up?

A trade-off exists between responsiveness vs. productivity. If you insist on stopping the team to respond to an issue, you ruin productivity. If you never let the team address unplanned issues, you ruin responsiveness. What you need is a compromise: buffer the unplanned work to some degree. (see TeamWideInteruption)

Defer unplanned work to later the same day, later the same week, or in the next development time box, depending on the severity and priority. Don’t drop everything every time an issue comes up, and don’t ignore critical issues for weeks either: time box your response to emergencies, so that other parties have confidence that you’ll address the issues within some known period without becoming completely interruptible.

Shorter development time boxes force you to ruthlessly automate tasks such as build, test, deploy, and database adjustments.

Warning Signs

A bad technical lead or manager will tell the team what work they must take on during a development time box. This is a very “command and control” approach, and removes the team’s ownership of the work. It also means the team has no reason to scrutinize the work description, acceptance criteria, etc. That violates our concept of bi-directional transparency and accountability.

If the team is consistently getting 10% to 20% of their work done, the team is over-committing. Enabling the team to consistently over-commit enables dysfunctional behavior. A good team averages between 90% and 110% of their commitments.

Growth Path

What else could you apply a time box to? What else has a lot of unknowns, a lot of risk, and no end in sight?

How To Fail Spectacularly

  • Meeting timeboxes so frequent and recurring that no time remains for actual work
  • Meeting timeboxes with no goal or outcome specified
  • Extending the development timebox until the all the work is complete
  • Restating your work at the end of the development timebox to make it appear you completed all your work
  • Vary every development timebox length. 1 week. Then 2 weeks. Now 1 week. Let’s try 3 weeks…
  • People stuck in a development timebox, not requesting help

  ←Prev (StorySlicing.txt)(Set Team-wide Interruption Protocols) Next→

Follow @growsmethod in the Fediverse, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.