Why We All Use Timeboxes

Added to Process

I’ve been a project manager/program manager and have taught project management and program management since 1992. I have the gray hair to prove it.

One of my secret tools was timeboxing. Oh, it wasn’t such a secret, because I asked people to timebox their work. I timeboxed my work. I taught about timeboxing. I found that limiting the time that people worked on a task helped them focus.

I am not talking about hacking 20% off a schedule for people to feel “pressure.” I’ve never found that to be useful. But using timeboxes? Wow, so useful for me.

Here’s how I have used timeboxes:

  1. When I have work I don’t know how to start. Have you ever wondered about a specific task you need to do? You sit there and say, “I have no idea how to start this. Maybe I should check email.” I use a 10-minute timebox to gather myself and write down how I could start this work. I limit this timebox to 10 minutes because I want a long-enough period of time to make progress, and short-enough period that I can see where I am at the end.
  2. I find it helpful to reflect on my work every so often. I like to think about how I can work better. I happen to use a one-week timebox to reflect back on the previous week and plan my next week’s work.
  3. When I have deliverables at a certain time. I have clients, books, and teaching deliverables. Yes, I have more than one project underway at all times. That’s because I’m a consultant. I create small timeboxes to make progress on all my work. I work on one thing for an hour, get that piece to done, and decide what to do next. While I am in that timebox, I concentrate on just that work.

You’ll notice I haven’t said anything about “agile” here. Agile uses timeboxes for many things, including my examples.

When a team doesn’t know how to start, they do a spike. The entire team learns together, for anywhere from an hour to a day. The team decides on their timebox and understands what the rest of the deliverables are by the end of the timebox.

Many teams use two-week iterations as their team cadence. They have a rhythm then for demonstrations and retrospectives. They do exactly what I do: reflect and use their current data for planning the next chunk of work.

I prefer that teams work on only one project during an iteration. For many teams, this is impossible. In that case, I ask the Product Owner to make sure the features are small, so the team can see the flow of work (that they make progress all the time) and that they manage the interruptions.

Timeboxes are not new to agile. They are an old project management “trick” or tip.

If you find yourself under pressure, consider your deliverables. What can you focus on now--and not interrupt yourself for a short time--to then deliver? You have found the secret: deliverables in short timeboxes.

Regardless of your project approach, consider timeboxes in some way. You don’t have to be agile to use them. And, if you are agile, maybe explain how you use timeboxes. Maybe I can learn from you!

About the Author

Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development.Johanna is the author of more than ten books, including: - Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver - Agile and Lean Program Management: Scaling Collaboration Across the Organization - Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, 2nd ed. - Diving for Hidden Treasures: Finding the Value in Your Project Portfolio (with Jutta Eckstein) - Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Schedule or Cost See more of Johanna’s books and writing on http://www.jrothman.com, and http://www.createadaptablelife.com.

This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.

  • Joshua Kerievsky

    Thanks for this article, Johanna. There are actually many people throughout the world who practice agile/lean without fixed-length time boxes. I think the reason may come back to the question of what is essential to agility and what is just an implementation. I happen to think that the lean concept of “small batches” is essential to agility, whereas fixed-length time boxes are just one of several implementations. For example, flow-based systems work really well and don’t involve time boxes. They work best when the stuff flowing along fits the category of “small batches.” As for stopping to reflect or demo your work, you can still do that on some regular cadence when working with a flow-based system. Hope that helps.

  • Johanna Rothman

    Joshua, thanks for your comment. When I teach agile, I teach the ideas of lean so that people understand seeing the whole, small batch size, and considering how to use the entire team to get a story to done. Even when my clients use “just” lean, they often use timeboxes for spikes as I described above, especially if they are new to agile approaches.

    This post is one of a series about why the PMI and the AA is collaborating on the Agile Practice Guide. My perspective was to show–regardless of a team’s approach to their project–that timeboxes can be helpful. Notice I barely discussed the idea of the iteration as a larger timebox. I certainly don’t believe in just iteration-based agile to be agile. I also wrote this article: https://www.techwell.com/techwell-insights/2016/01/agile-does-not-equal-scrum-know-difference, because I find that too often people think that their approach is the One and Only Approach to Agile.

  • Ebenezer Ikonne

    Except one works in a context where time is unbounded, time-boxes are present. A “box of time”. Now how you use these “boxes of time” are where it gets interesting.

    • Johanna Rothman

      Ebenezer, thanks for articulating the difference between some orgs (time is unbounded) and other orgs (when we use timeboxes). I have always worked in orgs where we had bounded time. Maybe that’s the difference between Joshua’s experience and mine.