One of the most frequent Scrum questions I get in my travels is this:

“How can we improve our Sprints so that we don’t run out of time for testing?”

The answer is simple. Stop treating your Sprints like a short waterfall. You run out of testing time because team members are still working in silos and think that testing comes after coding. Instead, we want to use Agile and Lean principles to improve our Sprint flow, reduce risk and get more done with less effort. 

A default work pattern for new Scrum teams is shown in Figure 1. In this simplified example, four stories are selected during Sprint Planning. (A real scenario would have 2 to 4 times more stories.) Joe says “I’ll do the first one”. Sam says “I have number 2”. Sally takes number 3. Jose takes the last one. They all run off to their cubes to start coding. Testers Jan and Pat sit there wondering what to do.

Figure 1: Mini-Waterfall


Does this sound familiar? It describes a mini-waterfall. The work is phased. Team members work alone. All of the risk is back-loaded because validation does not start until near the end. The Team is not really collaborating. They just packed all of the old habits into a shorter time frame.The developers proceed through the Sprint, reporting progress each day. The testers sketch out some test plans from the Story acceptance criteria. With three days left in the Sprint, ScrumMaster Peter reminds everyone that demo time is near. The developers hurry to finish their stories and pass them to the testers with two days left. The testers do not have enough time to test. When they find something wrong, there is not enough time to fix it. Most of the stories will not get done.

Lean Principles to the Rescue

Figure 2 shows a healthier Sprint flow. It illustrates a number of powerful Agile and Lean concepts. In this scenario, Joe says “I would like to work on Story 1. Who wants to do it with me?” Sam volunteers. Jan says “I will do the testing. Let’s get going.” Sally signs up for story 2. Jose pairs up with her, looking at the middle tier tasks first while determining the data design. Pat starts automating the acceptance criteria.

Figure 2: Single Piece Flow


Single Piece Flow: Work items go from start to finish as quickly as possible. Lean tells us that it is better for the people to wait than for the work to wait. More will actually get done when the flow is smoother.The Lean concepts are:

  • Smaller Batch Size: Queuing Theory tells us that a smaller batch size will result in more work completed per unit time. In Figure 1, the batch size is 4. All four things are still in progress at the end of the Sprint. This is analogous to having two many cars on the road. They have to compete for space while watching out for collissions. It takes longer to get where you are going. In figure 2, the batch size is 2. Fewer cars on the road means more mobility and shorter travel times.
  • Less Work In Progress (WIP): At any one time, only two stories are in progress. No other story is started until one is finished. This reduces risk, spreading it evenly through the Sprint. Only the last story is in danger of not being finished. The Agile practice of Kanban specifically limits WIP to achieve maximum throughput.
  • Swarming: For all of this to work, team members must work closely together. No one person owns a story. No one person can work on it. Developers can work on separate tasks of one story. Developers can work together on a single task. This is called Pair Programming, a powerful technique from Extreme Programming. Developers and Testers can work together on a task to produce more testable code and to choose the right test cases.
Figure 3: A Lean Sprint Flow


How do we break out of the waterfall mode and create a more Lean flow? Work together. Switch off often so that everyone knows as much about the product as possible. Work on the minimum number of stories at a time. Don’t start a new story until one story is finished. Aim to have the first story done by Sprint Day 2 or 3. And when you see too much piled up in the “In Progress” column, start the Daily Scrum with this reminder:

“Stop starting and start finishing.”

Print Friendly, PDF & Email
A Sprint is Not a 2-Week Waterfall!

8 thoughts on “A Sprint is Not a 2-Week Waterfall!

  • Pingback:Testers in a New Scrum Team, Get A Bad Deal | Alexander Brown

  • June 12, 2015 at 6:06 am

    Excellent explanation of the proper way to work stories Roger. Sometimes I fall into my old habits and have the team members select one story each. Thanks for this important reminder on how agile story processing is supposed to work.

  • August 11, 2015 at 10:09 pm

    With almost every line I read I was jumping for joy – you’ve distilled beautifully the essence of a problem I’m dealing with at the moment. “A sprint is not a 2 week waterfall” is a phrase that is going to stick with me! Thanks!

  • October 14, 2015 at 2:08 am

    I have to thank you for this excellent post! The article captures the essence of the thoughts have been brewing in me for the last couple of months. This is what the “self-organising” team means!

  • February 29, 2016 at 3:27 am

    Interesting title, especially as I’m constantly telling my teams the exact opposite!
    I find teams, especially those made up of inexperienced devs, use agile as an excuse to do very little preparation, often not even bothering requirements gathering.
    I describe each sprint as a “mini” v-model project to try and ensure there is at least some requirements gathering, up front design, build and test.
    I do stress there is a need for multiple forms of testing, i.e. good software engineering, so haven’t had this problem, but I’ll keep this post in mind in case I ever do.

    • April 6, 2016 at 5:56 am

      New to Agile but I understand that the team takes a story off the backlog during a sprint to prepare it for the next sprint, i.e. requirements gathering is done in sprint X for the stories to be worked on in sprint X+1?

      • April 6, 2016 at 9:58 am

        Hi Anthony,

        There are many variations on when product Backlog items (previously known as “requirements”) are defined and elaborated. The most common scenario is that the Product backlog is initially defined at the start of a series of Sprints in a Release Planning meeting. Items are described at a very high level, often in the form of User Stories. Then the items are elaborated just in time, a Sprint or two prior to when the items are accepted into a Sprint. Since we don’t know for sure which items will enter a Sprint until the Sprint Planning meeting, a common rule of thumb is that the Product Owner keeps ahead of the Development Team with 2 to 3 Sprints worth of Product Backlog elaborated. That elaboration is part of Backlog Grooming, a Product Owner responsibility. You can find descriptions of all of these activities in many places online.


Leave a Reply

Your email address will not be published. Required fields are marked *