Startup Sprint

The Startup Sprint (Sprint Zero) will contain enough analysis, enough environment and enough team training for the team to do something real. Agile development is all about delivering valuable Results early and often, in order to receive and incorporate feedback as soon as possible. Many of the Organizations I coach are convinced that it will take months before they can write any code that produces value. Is this a reasonable fear? How do we get past this fear? How do we get a Team writing code and delivering value as quickly as possible? And how quick can that be? Let me describe the Startup Sprint pattern, which many coaches have used (and are using) successfully to get a Team up and running quickly. The idea is simple: Take an initial Sprint (called the Startup Sprint) that has the following goal: ‘Be up and running the first day of the next Sprint’ and the following three Backlog Items:

• Place some quality items on the Backlog’;
• Create a minimal environment dedicated to the writing of Clean Code’; and
• Write a piece of real code, no matter how small’.

• And, of course, make the Startup Sprint as short as possible. In my experience, this Sprint can be as short as one week, which is what I recommend. I think one week is good because it applies pressure on the Team to achieve the three Items listed above quickly and efficiently – I don’t want the Team to do any gold-plating or unnecessary work in order to get to that first real code. Of course, there is continued work on environment and the Product Backlog in future Sprints, so we don’t delude ourselves that we’re finished in this Startup Sprint. In fact, we don’t even delude ourselves that we’ve achieved the 80% solution, or even the 50% solution. We’re just getting started… That’s the point of the Startup Sprint. Get started, but do real stuff as you start and ramp up. So what does the Team actually do in the Startup Sprint? Well, it works on the initial Sprint Backlog (Stories) shown above. Since the Team has this Backlog, the conversations that we call Backlog Refinement and Sprint Planning can begin. Firstly, we elaborate