The idea behind “Sprint 0″ is that software development teams should spend some time at the beginning of an agile project doing analysis, design and other preparation tasks. I’m not referring to small projects — a few people for a few months. I’m thinking about enterprise projects involving multiple teams deploying to multiple servers.
At the lowest level, good software is good software. The tools and techniques used are analogous regardless of the size of the resulting system. At the highest level, good design at a small scale does not translate into good design at an enterprise scale. New problems appear at scale. Those problems demand new ideas and unique solutions.
Sprint Zero Gets a Bad Rap
I think many people despise the idea of “Sprint 0″ because they envision a bunch of managers and technical hotshots hanging around trying to manage every last detail of the project. They also interpret the Agile Manifesto too literally in assuming that only delivered software has any value — everything else is fluff.
If it was possible to dive in and create an elegant enterprise system design by simply writing code, I’d be all for it. Why do extra work? Let the code drive the design.
That may work for small systems but in enterprise systems, it flops. The resulting code always requires rework — often to the point of being discarded and re-written. That leads to the second Manifesto misinterpretation. Redesigning code does not qualify as ‘refactoring‘. Look it up. Refactoring changes the internal structure of code not the external behavior.
If the design doesn’t scale, refactoring won’t help. If you have to start over after one or two sprints, skipping Sprint 0 was a bad idea.
We need to do some analysis and design at the outset of big projects without getting sucked into creating gantt charts, requirements specifications and technical design documents. Here are some questions to answer during sprint 0.
- What is the scope of the project (vision)? What are the key goals?
- Who will be involved in the project? Do we have a sponsor, stakeholders, user representatives and key members of the software build team?
- How many simultaneous users will the software system have to support?
- How much data will be processed each hour, day, week, etc.?
- How secure does the system need to be (authentication, encryption, etc.)?
- How fast does the system need to respond?
- When will test data be available? (Not just contrived data elements but real world information that can be processed by the new software.)
- What software and hardware tools will we use? Are they already in house or must they be procured?
- What are the greatest risks we face? What can we do to mitigate them?
- What constraints exist and what assumptions are we making? (This would be a good time to write some exploratory code to test assumptions or evaluate risks.)
- What system interfaces are we dependent upon? Are they internal or external? Do they exist yet? (Another area where exploratory code may be helpful. If an interface does not yet exist, you may need to emulate it.)
- What will the user interface (UX) be like? (This is a good time to sketch up some ideas.)
- How will we work? How long will sprints be? What is the definition of done?
- Do we have a product backlog? Is there a separate backlog for this release?
- When do we have to deliver something (minimal release, full release)? Are there critical dates we have to hit?
- How will we know when we’re done? What are the key measures (budget, target date, minimum feature set, etc.)?
- What metrics will we track and how?
- Is the software development environment available? If not, what needs to be done?
- Is work space available? Will all team members be together? How will everyone stay connected?
If the stars are in alignment for your project, you may be able to fly through these questions in a couple of days and begin writing code. It’s more likely, however, that many answers will be vague or missing. Apply lean principles. Think about the simplest way to answer the questions.
You may decide to put off answering some of these questions until a few sprints are done. That’s okay. Having gone through this exercise, at least you’ll know what’s ahead.