“The heart of Scrum is a Sprint, a time-box of one month or less during which a ‘Done’, useable, and potentially releasable product Increment is created”
Each project starts with several strategic questions: how are we going to communicate? How will we manage the project and mitigate risks? How do we schedule the project phases so all releases will be on time and on budget? The answers to these questions depend on how clearly technical requirements and project documentation are defined. Obviously, less detailed requirements or inconsistent documentation lead to difficulties in estimating labor costs and elaborating a project plan and increase the time spent on communication with the customer and the engineering team.
The goals of the responsible R&D service provider are to minimize the costs for the customer, organize work most efficiently, and reduce excessive customer involvement in the project. The most common problem we encounter is that initial customer documentation (such as proposals or statements of work) usually describes mainly business requirements and says little about how they should be implemented, contains vague technical information, and does not consider all factors, while the architecture is not mature and needs to be improved. It all sounds rather bleak, but we have a proven solution that has been successfully applied to numerous cases.
Sprint zero – what it is
To solve the above-mentioned problems, we use a special sprint, which we call “sprint zero.” This sprint allows us to:
- set up the core team, distribute roles, and arrange an onsite initial workshop for the key engineer/PM for knowledge transfer regarding the product and requirements (coming back, he/she will share the information with the rest of the team and facilitate their input into the project);
- describe the architecture and design of the application (HLA and HLD) as well as the technical requirements in detail;
- make high-level assessments of the main components of the system and put together a product backlog; and
- deploy CI/CD, prepare equipment, clearly define the required technology stack, select hardware, install software to work on the project, and purchase the necessary licenses.
In other words, sprint zero for a software developer is like a recipe enabling a chef to prepare everything for the next culinary masterpiece. It is an essential part of the process. An impromptu meal can turn out excellent, but it will require much more time, effort, and stress.
What does the Scrum Guide say?
Sprint zero is the time to prepare a team for a project. In our practice, this usually takes about two weeks (depending on the complexity of the project, customer requirements, and other factors). According to the classic definition of sprint in Scrum, it is a toxic sprint that comes from a lack of understanding of the fundamentals of the methodology, and it should be discarded because it does not add real value to the product. All these procedures should be done during sprint planning. The theory perfectly explains what should be done and how, but is it applicable to real-life projects? Let me provide some examples from my experience.
Three years ago, I had a project involving developing an app for a call center of a large international company. The customer insisted on the classic Scrum and tight deadlines; after all, everyone knows that Scrum helps develop a product quickly and efficiently. According to the methodology, we used the first sprint to create MVP and draw the architecture. Of course, we did not have enough time to think it over, but the customer did not mind or insist on allocating more time to architecture design because they were mostly interested in the functionality. We still had to do a lot, and quickly!
After six months of hard and productive work, we encountered real difficulties. The system worked slowly, some of the planned functions contained errors and did not work as expected, and some were very difficult to implement. The team lost motivation and the sprints turned into torture for all participants. It happened because the hastily designed architecture did not meet the product requirements. Finally, we convinced the customer to spend additional time (and money) on revising the architecture and re-engineering the system. Eventually, we were two months late with the delivery, the client bore the additional costs, and the relations within the team and with the customer were tense and adversarial. After such an experience, you would assume that Waterfall is preferable to Agile.
Another example from last year is a project in which we created a simulator of a medical device. Our engineering team spent two weeks figuring out what we should do, describing the architecture, and setting up all the necessary environments. As a result, we developed an action plan for the next six months, which, of course, evolved during this period, but this was predictable and transparent. The project was delivered on time with the expected quality. The customer was completely satisfied with the process in place, and they continue to cooperate with Auriga on other projects.
By the way, the Scrum Guide does not prohibit any preparatory work, and you can call it anything you like, so why not use the term “sprint zero,” especially when all the people involved in the project understand what it is and why it is needed?
Do you always need sprint zero?
Naturally, successful projects without sprint zero do exist. Does it mean that a project team can do without it completely? Maybe. But instead of guessing or challenging your gut feeling about this, let’s concentrate on the indicators of when it is definitely needed:
- when the architecture is poorly described, technical requirements and/or risks are assessed with large tolerances, and additional technology research is required;
- when it is necessary to quickly expand the initial core team and introduce new engineers to the project; and
- when there is no project equipment available at the moment, CI/CD tools are not configured, software is not installed, etc.
The last bullet is less critical than the first two but also very important, since it is impossible to start the project if you are sidetracked by those tasks.
To sum it up, sprint zero can be considered an essential part of pre-project preparation that allows the customer and contractor to update the business requirements, develop a clearer project plan (considering terms, budget, and scope of work), minimize risks, and, in general, deliver a better product. Do not blindly follow any methodology, no matter how attractive it seems. Each project, product, and customer is unique and, therefore, requires an individual approach.
