Agile Development

Sprint Zero: The Starting Line for Agile Success

I had an interesting exchange with a friend of mine the other day about the Agile methodology. His impression of Agile was very different than mine, and I think it’s because he’s never seen a team that properly organized itself for a project using sprint zero.

“I’m working on a project using Agile, are you familiar with that?” I asked.

“Oh, sure,” he said. “That’s the methodology where the coders try to incorporate every little change into the project whenever the client suggests them, resulting in complete chaos.”

I blinked. Were we talking about the same methodology?

My friend explained further. “I know that’s exactly the opposite of what Agile is supposed to be, but in practice that’s what you get,” he said matter-of-factly.

It was at that moment that I realized that my friend, who works with a fair number of programmers, has never seen an Agile project which started on the right foot . . . one that included a sprint zero.

[2]Sprints are the very essence of Agile projects, and they are well-named: they’re designed to be short, fast, and with a clearly-defined finish line. That finish line is a specific, usable stage of the product. Just like runners on a track, the team is all moving in the same direction toward that goal. No changes are made to the requirements during the sprint, because that would be like a runner deciding to make a sharp turn and head off into the stands instead of pushing for the finish line.

That’s all well and good in theory, but not at all what my friend has observed. What went wrong? They tried to hit the ground running, instead of starting off on the right foot. The way we do that with the Agile methodology is by using a sprint zero.

Let’s put the running analogy aside for a moment to better explain how sprint zero can make the difference between a flailing bunch of coders and a serious Agile project.

The reason it’s called “sprint zero” is because it sets the tone for the entire project. While each sprint has the basic goal of creating a working piece of code by following the steps of design, infrastructure, process improvement, implementation, test, and validation, sprint zero is used to ground the entire project in those principles. For newer Agile teams, it can be used to set up the physical coding environment or get the team used to the focused goals of a sprint. More experienced Agile coders can use sprint zero to orient their clients to the process, and elicit the requirements needed to create a wireframe of the entire project. No matter the level of experience among the programmers or clients, sprint zero is critical for communicating expectations.

In either case, sprint zero puts the client and team on the same starting line (oops, there’s that running analogy again) and points them all in the same direction. This is particularly important when you’re working with a client who is new to software development; otherwise they might not understand the value of the sprint concept. Namely, requirements do not get changed during a sprint for any reason!

Requirements are locked in until the sprint is finished. This keeps the team focused, controlling costs and ensuring that deadlines are met. If there’s a change that needs to be made, it’s included in a future sprint rather than having it implemented on the fly. The goal of each sprint is to produce a workable product, so incomplete requirements won’t be delivered. Instead, they are reviewed and returned to the backlog, to be included in a future sprint.

Sprint zero helps the client and team work together, reducing the chances that requirement changes will necessitate returning items to the backlog. It starts the project off on the right foot. Yes, requirements do change, but a disciplined Agile team isn’t going to try to react to those realities during a sprint, and a well-informed client isn’t going to expect them to, either.

In short, sprint zero supplies the planning and orientation that will ensure that the entire project runs as smoothly as the Agile methodology intended.

That’s what my friend didn’t get, because he’s never worked with real Agile professionals [3]. If you’ve heard that Agile isn’t helpful for software development, think again; then, check out the difference an experienced Agile team can make to your project.

Read the source article at Offshore Outsourced Software Development

Leave a Reply

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