.st0{fill:#FFFFFF;}

Waterfalling The Timebox In Agile 

 April 8, 2022

By  Anthony Amos

“What does “waterfalling the timebox” mean in Agile context?
I have read at some places that “waterfalling the timebox” in an iteration should be avoided. a) What does it mean? b) How to avoid “waterfalling” in the iteration?

To avoid the lure of the waterfall, look for waterfall “smells” and address them during retrospectives. Some clues include delivery at the end of the iteration, stand-ups where everyone reports in to the Product Owner or Scrum Master, or phased delivery plans.

Tony Amos

People naturally revert to the familiar when learning new skills, even when the familiar works against our goal. Familiarity creates comfort which creates habit. Successful people lean into the discomfort and break through it, while many others continue to overlay prior unproductive habits, then wonder why they aren’t hitting their goals.

So, what is “waterfalling the timebox”? Generally, it means treating the iteration as if it were a mini-waterfall project.

Waterfall is a familiar practice, and with Agile, we are moving away from waterfall. Scrum defines a timebox as a fixed and maximum unit of time for an activity. The Sprint or Iteration is timeboxed, and so are Daily stand-ups, Sprint Planning, the Sprint Review, and the Retrospective. Waterfalling, however, usually only applies to the iteration.

So, to waterfall means to treat the work as a series of “gates” or phases to be passed in order to reach an end-state. For example, we may take a 3-week iteration and plan the first 4 days for design, then the next 8 days for development, the next 3 days for testing, then release. That is waterfalling. We take our familiarity with waterfall and apply it to the iteration, thus waterfalling the timebox.

One intent in Agile is to avoid targeting delivery at the end of the iteration. Instead, consider what feedback can be elicited quickly. And the only way to get feedback is to deliver something. But don’t guide the iteration so that all delivery is at the end. Create, get feedback, refine, and release when ready. Keep in mind that our goal in an iteration is to do the minimum work necessary to deliver value. The timebox facilitates that.

When waterfalling, we say we will deliver something at the end of each iteration. But Agile encourages an environment of continuous delivery and feedback. This is a different way of thinking. It does not necessarily provide a list of features and dates, but it does require trust and effective communication in order to work.

To avoid the lure of the waterfall, look for waterfall “smells” and address them during retrospectives. Some clues include delivery at the end of the iteration, stand-ups where everyone reports to the Product Owner or Scrum Master, or phased delivery plans. I’ll bet you can think of others.

Agile team members address each other at the stand-up and the PO or SM doesn’t interfere except to help clear blockers or resolve problems with requirements. Stakeholder reviews can happen at any time, and with modern DevOps tech, so can releases. If feasible, work towards continuous delivery if you’re not there yet.

The team does not have to turn on a dime. It’s ok to slowly make changes as each iteration passes. Too much change at once causes confusion, so gauge the team’s ability to absorb changes and incorporate them gradually, but consistently. You will see the difference in team morale and productivity as you move further and further from the waterfall.

Anthony Amos


Anthony started creating software in 1981 when he curiously picked up the programming manual for a Wang OIS Word Processor while deployed with the US Navy. He had never seen a computer before, but he taught himself how to write programs that made his Navy work easier and more accurate.
After his honorable discharge in 1986, he began creating financial and analytical software for diverse organizations including Verizon Wireless, JP Morgan Asset Management, GoldenTree Asset Management, NASDAQ, Prudential Insurance, AT&T Capital Corporation, Lehman Brothers, Ernst & Young, and Blue Cross & Blue Shield of New Jersey.

Demonstrating his commitment to the principles and values of Agile Software Engineering, Anthony is a recognized SAFe® version 5 Program Consultant and holds many of the most challenging and difficult to attain Agile certifications. His practice is grounded in Agile Frameworks as he leads clients to implement Scrum, Kanban, Scrum with Kanban, Scaled Scrum with Nexus, and Scaled Agile Framework. He believes in using the framework that best fits the organization's cultural and business direction while maintaining disciplined processes.

Tony Amos

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our Agile newsletter