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.
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.
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.
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.”