This is a chapter from Amplio Development: The Path to Effective Lean-Agile Teams 

Timeboxing is looking out to the future to see how much work you can do in the timebox.

Flow is looking at the next piece of work and getting it done as soon as you can. While you can put flow inside a timebox it is not that same as flow on its own

While Agile suggests long-term planning is not effective, it doesn’t mean planning isn’t essential. It just needs to be done for a short period. This is evident by the gradual shortening of the planning interval. When Scrum was first introduced the common planning cycle was 30 days. Common practice now is 2 weeks, with many planning weekly.

Timeboxing is the practice of planning out for a specified period of time and seeing how much you can get done in the time period. In other words, instead of saying deciding on the functionality needed and deciding on how long it will take, you determine how much you can get done in a pre-determined length of time.

The reasons for planning are:

  1. Create a goal for the period
  2. Determine will be worked on over a short period. This helps create alignment of the team by providing a common goal
  3. Encourage the decomposition of the work into small items (the shorter the time-box the more encouragement occurs).
  4. Determine how this goal will be achieved
  5. Create a focus on working on the planned work and not be interrupted by requests from outside the team
  6. Establish a cadence (the end of the period) to reflect on how well the team is creating value

Each of these reasons is important. But planning with time-boxing is not the only way to achieve them.

An alternative approach is to use flow. Flow has items of value pulled by the team and done to completion at which point another item is pulled. Flow may be done with many items in play or only one. This latter approach is called “one-piece-flow” which is often popular in manufacturing but not recommended as a general rule.

If value can be delivered with each small item, the product backlog merely needs to be sequenced by importance. But if a collection of items are required to get value, these need to be grouped together on the backlog. Minimum business increments can be useful for this. 

The decision to use timeboxing, as in Scrum, or flow, as in Lean and Kanban, is an important one. It is often a good decision to make early as it creates the context for many other practices and is often the basis for how roles cooperate with each other. However, it should not be considered a one-and-done decision. Timeboxing requires fewer concepts to use, but flow can often be more efficient. Flow is also less wasteful if we have a high degree of uncertainty on what to build since we can adjust as we learn.

Many times, starting with timeboxing makes the transition to Agile easier. After the team is familiar with Agile, shifting from timeboxing to flow makes it more effective. 

Hybrid approaches are also possible as follows:

  1. Pure timeboxing. Decide on what work will be done within a certain pre-determined period of time and don’t worry about the order the work is done within the timebox.
  2. Timebox the work, but do the work selected in a flow-like manner. That is, try to keep as few items in play as possible without slowing the team down.
  3. Timeboxing within flow. In this case, an “item” to be worked on can be worked for a particular amount of time. You’re still thinking flow but have decided that each item is provided only a certain amount of time to complete. working on a certain amount of value for a certain period of time. This is useful in knowledge work where you are investigating ideas.
  4. Pure flow. No timeboxing of work, just work on items of the highest importance but do have a cadence for coordination.

If you’re going to do timeboxing, it is recommended that you do flow within it.  This speeds up the completion of individual items and therefore speeds up feedback and the delivery of value.

The choice of using timeboxing or flow is not always a clear one. Many factors are often involved. Some of these factors predispose a team to choose flow or timeboxing. Many times, however, this choice will best be made after going through the required objectives and seeing how to best meet them.

It is suggested you make a tentative choice early. As you proceed through this book, look to see how your choice stacks up. Be ready to reconsider as you go through all of the capabilities required.

Reasons to timebox

  1. The team is already familiar with timeboxing. They may have experience with Scrum already. But be wary of proponents of timeboxed-based approaches claiming teams new to Agile should always start this way. That’s more marketing hype than truth.
  2. Either due to familiarity or how the team likes to work, timeboxing would be an easier transition for the team.
  3. The team is clear about what needs to be built and releases will likely take a few sprints (timeboxes) to be completed.
  4. Releases typically take more than one iteration to build.

Reasons to use flow

  1. You are building a new product and working in a discovery mode with Minimum Viable Products. Flow makes more sense here because you can’t plan very far ahead since you are not sure what the product is.
  2. You are doing a significant of maintenance work (including being mostly a support organization). This means the time spent working on new functionality will be interrupted by maintenance items.
  3. As maintenance work increases the difficulty of planning new work becomes more difficult.
  4. The team is continuously interrupted by management or other teams.

From a mechanistic point of view flow typically gives better results. The reason is that with a flow model you focus on releasable items to build and work on fewer items. It also makes it more likely problems will be solved immediately instead of waiting for the retrospection. Since teams should release when work is ready, not necessarily at the end of the timebox, planning beyond a release that will occur in the next iteration makes sense.  That said, it’s important for the team to decide what they are more comfortable with.

The difference in how timeboxing and flow shows up in work

When timeboxing is being used, especially if it was selected because the teams were not experienced, there is a tendency for teams to open too many stories. The focus is on getting the sprint plan accomplished and the means to get there is often not clear. While there may be an intention to release part of it early the commitment is to the sprint, not the early release. This often results in many stories being open throughout the sprint and many get closed towards the end of the sprint. This is not an efficient way of working and delays getting feedback to the end of the sprint.

When flow is used the focus is on what is being released next. This prevents opening up stories that relate to what will happen after the release. This focus tends to prevent too many stories from opening and increases cooperation. Note, however, that this attitude can be used even when timeboxing is used – and it should be.

A potential problem with timeboxing and management

A common challenge teams face is management asking to insert a new request into the mix. This is very easy for them to justify when timeboxing is used because it just adds one more thing to the pile. Working a little harder is expected.  When flow is used, work is clearly sequenced – we work on items in order of value. It is easy to show management that injecting this new piece of work into the sequence slows everything else done. That doesn’t mean management will abide by this, but it does make it clearer that there are consequences. This also sets the stage for making work interruptible, a useful technique.

How to start and move forward

In whatever way your team starts, you can move forward and change as appropriate. Regardless of which approach you take you always need to have a cadence. This enables the coordination of different teams and roles.

A decision table for timeboxing or flow

Situation. Put a 1 in the appropriate column for each question.FlowTime-box
Are people more familiar with Scrum than Kanban? Y=Tb. N=Flow
Would using timeboxing be an easier transition for the team? Y=Tb. N=Flow
Is the team clear on what needs to be built? Y=Tb. N=Flow
Do releases typically take more than one iteration? Y=Tb. N=Flow
Are you building a new product and using MVPs? Y=Flow. N=Tb
Are you doing more than 20% maintenance work? Y=Flow. N=Tb
Is planning new work difficult? Y=Flow. N=Tb
Are you continuously being interrupted by other teams? Y=Flow. N=Tb

Remember, the decision to use timeboxing or flow can be changed

As you work through this book you may learn concepts that have you change your decision. There are times when how you work changes as well. For example, you may start working on a new product and decide you want to use flow. After a little time, you understand what needs to be built and you shift into a time-boxing mode. After it’s released, you may end up being more in maintenance mode and shift back to flow. The key thing, however, is to stick with the method you chose during the time period you chose it for. Also, even when you are using timeboxing, you will also be doing flow within the timebox.


Go to Amplio Development: The Path to Effective Lean-Agile Teams 

Go to Being a Professional Coach



Latest Article

Going From Scrum to Flow/Lean/ToC to Amplio

Start Reading >>

Latest Presentation

Intro to BLAST and How To Solve Challenges in the Workflow

Watch Video >>

Upcoming Event

An Introduction to Amplio - A Pattern Language (Free)

Register on Zoom >>

The Amplio Community of Practice (Free)

Learn More >>

New Workshop

The Amplio Development Masterclass

More Info >>

Latest Presentation

Intro to BLAST and How To Solve Challenges in the Workflow