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.
The Challenge
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.
Implementation Questions
- 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.)
Process Questions
- 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.
photo credit: gatogrunge via photopin cc
Have you seen Sprint Zero really improve design and/or architecture decisions? I have found that sprint zero actually tends to make things worse. They give the allusion that because time is being spent up front that it will make things better.
Derek, I have seen this work. The key is to keep it lean. Teams will sometimes over-analyze or dig too deep into the design. When they do those things, they are effectively regressing to waterfall. That’s a trap! Sprint zero is about doing just enough to establish a clear direction. It’s not about implementing solutions. BTW, a month is far too long for Sprint zero. I’d limit it to one or two weeks.
My question is, how do you even know you should be creating some software? The hardest thing about software development is deciding what to develop…. and to be sure it is the right software for the problem/opportunity.
I just find your implementation questions are all over the map. What is the scope is an excellent first question; in fact it is more than a question, it is a key step that will guide the answers to a lot of your other questions.
Sorry, I appreciate that you see large enterprise projects as needing more first thought than small stuff, but I would expect more (not BRUF) when big dollars and bigger exposures are involved.
Every project needs a strong foundation regarding business case, vision and strategy. That’s why we like to call it Foundations in the DSDM methodology 🙂
From my point of view the term “Sprint 0” implies that you start from scratch in every project, regarding staffing and development environments etc. Unfortunately that is often the case in reality. Actually I like the bullets you address, but if you start from nothing in every project I’m afraid “Sprint 0” won’t be enough.
What enterprises really need is an Agile PMO and an Agile Enterprise Architecture that addresses strategy, vision, governance, portfolio planning and prioritization. And that is truly an iterative work as well and should be kept “enough up-front” to get the operational development teams going. I think that’s far better than a bunch of Sprint 0’s in the beginning of every project. And maybe that’s what you wanted to convey in this blog post?
Good points! I’m not a fan of PMOs though I like the ‘Agile Enterprise Architecture’ idea. There should be a ‘Center of Excellence’ dedicated to software architecture. I still believe that many projects will benefit from Sprint 0 because there are often project-specific items that need to be addressed before the team can begin building a solution.