Don’t Let Your Agile Sprint Become a Mini-Waterfall Project

Scrum sprints can be tricky. Agile teams often fall into the trap of turning their Scrum sprint into a mini-waterfall. In other words, they take on work and save testing until the end of a Sprint, which tends to create more carryover than truly done work. Learn how to combat the mini-waterfall pitfall and save your Scrum sprint by swarming as a team, breaking work down, and tasking effectively.

David Hawks lays out his tips and tricks on escaping the mini-waterfall and achieving “Done Done” as a team in this video. Read more about mini-waterfall warning signs with our article, Your Sprint May Be A Mini Waterfall If… (https://agilevelocity.com/scrum/sprin…)

Video Transcription (has been slightly edited for brevity and clarity):

Mini-Waterfall, A Common Problem

Hi, my name is David Hawks with Agile Velocity, and today I want to talk to you about a common problem that we see with Scrum teams. The notion is that we don’t want our sprints to be a mini-waterfall. And we see this a lot. Let’s say we had a team that was 4 developers and 2 testers. We planned a sprint and pulled 4 user stories into our sprint. We’re doing a 2-week sprint and over that 2 weeks, we’re trying to get these 4 user stories done. The common trap that teams fall into is they have user story1, user story2, user story3 and user story4—what’s the most efficient way to assign this work? They say, “we’ll assign developer 1 to take the first story. Then developer 2 will take the 2nd story and developer 3 will take this story.” Developers kinda like this because developers don’t really like people—kidding—but developers like to go off and work and knock something out and put on their headphones and get something done. It’s kinda nice to be able to say, “I’m gonna go work on this, they’re gonna go work on that. I’m not going to be interrupted for eight days. At the end of the 8 days, I’m going to throw it over the wall to my QA person. QA 1 will take 1st two stories and QA 2 will take the 2nd two stories.”

How do you think this will end up at the end of this sprint? QA starts working on this and finding bugs and gets to the end. What are the chances this will carry over and not get everything “done done”? Will we have all the bugs addressed in this sprint? There’s a high likelihood that we will end up carrying over some of this stuff. If we look at a burndown chart for this sprint of stories complete, it would be flat until the very end and maybe we get something signed off and maybe we have a gap of not getting everything done. So while this is better than working on something for 3-4 months, the idea here is that we are shrinking it into two weeks which is better, but this isn’t how we want to work.

How to Avoid the Mini-Waterfall Trap

This isn’t what we want teams to do. We want to get teams out of their silos and into more swarming. In order to swarm, we have to break down into smaller chunks. We might want to break User Story1 into UserStory 1A, IB and IC and figure out as a team how to task this out into small parts where developer 1 and 2 work on that. How can we get testing involved earlier? Maybe it’s automated testing? What can we do to get it done earlier so that we can get something signed off earlier in the sprint not waiting for the last day? Which means we might have a swarming with developers 3 and 4 and QA 2 on something and trying to get it done. The question we’re challenging our teams with is what would it take to get something singed off by like day 3 or day 4? Then we’re going to continue to work on smaller things along the way but we’re swarming. We’re trying to get as many people to get user story 1 as a whole signed off, how can we do that? In our burndown chart, we’re seeing a little bit better progression throughout our sprint and reduces our risk of finding everything late and running out of time and gives us better predictability throughout our sprint. it also reduces the risk that the highest value item will carry over and reduces the risk of carry over all together.

That’s the challenge that we’re trying to push our teams to: How do you get out of a mini-waterfall? The skills here are how to break work down, how do we task and how do we swarm?  Hopefully this will help you become more successful with scrum.