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 on as it creates the context for many other practices and will be the basis for how roles cooperate with each other. However, it should not be considered a one-and-done decision. Many times starting with timeboxing is a good one to make the transition to Agile easier. Once basic Agile practices are underway, going to a flow model can further the transition. But just as often a flow model may be better because it can be much less disruptive. In this section,n we’ll discuss how to make this decision.

Timeboxing (also called using sprints or iterations) is when a team decides what they will build over a particular length of time. It is the common practice of Scrum and SAFe to use timeboxing. Scrum tends to use 2-4 week timeboxes they call “sprints.”  SAFe uses 2-3 month timeboxes they call program increments.

Flow is when items of value are 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.

There are two extremes (#1 and #4 below), and hybrid approaches are possible. These are:

  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. Flow with timeboxing. In this case, an “item” to be worked on can be work for a particular amount of time. You’re still thinking flow but have decided that working on a certain amount of work within a short interval.
  4. 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.

When it’s not clear, it’s often best to choose the practices that appear best and make a choice after going through the list of roles, events, artifacts, and rules and using the practices chosen. Regardless of which practice is chosen, the focus should always be on value delivered and keeping work-in-process as low as possible while not impeding workflow.

However, sometimes the choice is clear right upfront. These are the factors that may have you decide upfront which approach to take:

Reasons to timebox

  1. Timeboxing is more 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 being continuously interrupted by 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. 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 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.



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







 This is just a preliminary decision

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@Teams: The Path to Effective Lean-Agile Teams 



New Workshop

More Info >>

Upcoming Events