How to Survive Your First Agile Sprint | David Tzemach
Updated: Mar 3, 2022
If you are about to make a transition to Agile and decide to use Scrum as your preferred framework, it is vital to know the benefits of using “Sprint Zero”, and how you can use it to initiate the project. It is for you to choose whether to use it or not, but you must know it’s there.
In Scrum, there is no standard way of naming sprints. I used to work with organizations where the sprint naming convention was the sprint goal ( “finish integration with infra team”) or giving it a unique identifier ( “Core Team (CT1)”) or simply using the end-date of the sprint (the “10th of July sprint”). Still, the most common version was starting with sprint 1.
Some organizations will use the practice of having sprint zero as a “dry” sprint before the project starts. By having a “dry run” sprint, the organization gets the chance to tie up the remaining loose ends, such as assembling and training Scrum teams that are less experienced in Scrum and resolving technical issues like software tools or hardware to be used by the team.
Sprint zero can also be used to populate the project backlogs with epics, features, and stories that will be the input for the teams as part of the sprint planning meeting of sprint 1. In addition, sprint zero allows the team to get a real idea of the work ahead and build confidence that they can handle it.
Why People Resist the Concept of Sprint Zero?
I will say that sprint zero is not part of the official Scrum guide. During the last few years, it was established as part of a common understanding that you cannot simply start a Scrum (or any other) project without establishing the core pillars such as Roles, Goals, Backlogs, etc.
It just makes sense that organizations will want to plan their projects before starting them, based on a theoretical concept of Agile. There is a considerable difference between the theoretical concept and the actual implementation process in the real working environment, making it even more essential to have preliminary planning.
So, if it makes sense, why are people still resisting the concept of sprint zero? Let’s review the three major claims:
As I already said, sprint zero is not part of the official Scrum Guide, and people that do core Scrum will find it difficult.
Scrum or waterfall? Another complaint is that sprint zero is more relevant to the traditional methodologies and not relevant to Scrum because the activities of sprint zero are very similar to the planning and design phases of the waterfall model.
The use of sprint zero goes against a core value in Scrum by not adding real value to the customer at the end of the sprint.
What Should Be the Length of Sprint Zero?
Sprint zero should follow the same rules we have in all Sprints. It should be timeboxed to a minimum of one week or a maximum length of 4 weeks. Using the same Timebox for sprint zero adds excellent value because it is the first time you can test if the sprint length works for the team or should be changed to achieve better results.
When Can We Start Sprint 1?
There is no real need to wait before starting sprint 1, but as I learned over the years, it is a good idea to allow your team to clear their minds and prepare themselves for future challenges by having the slack time of a day before starting the first project sprint.
The Main Activities of Sprint Zero
There are many activities associated with sprint zero; as you will see below, they focus on the infrastructure that will support the project.
Create the product backlog
Creating the product backlogs means determining the requirements to be delivered through the project. This is done by both the Product Owner and the team, working closely to ensure that the product backlog is ready.
Let’s clarify the meaning of 'Ready':
There is a clear and agreed decision on the Definition of Done.
The PB items are prioritized for at least two sprints forward.
The PB items contain all the information the team needs to start working.
Ensure team readiness
One of the main activities of sprint zero is the creation of the new Scrum teams. This usually includes resolving many HR issues that arise, roles definitions, and approval from the team that they are ready to start the project.
Define the goals and vision
The Product Owner determines and reviews his vision for the product and the main goals he wants to achieve.
Infrastructure readiness
This is usually in the context of the team's physical, hardware and software aspects during the development effort. For example:
Preparing the physical working environment.
Defining the coding and testing standards.
Automation Framework readiness (CI/CD and Automated Testing Frameworks).
Defining the tools, systems, and logistics used by the teams to conduct different activities.
Training activities
Training will ensure that the team is ready for the challenges of the development and testing activities. This training is critical to both the team and the project. Training activities focus on different aspects, methodology including:
Development and testing tools.
Development framework and process.
Testing framework and process.
Domain knowledge.
Testing Activities in Sprint Zero
As part of sprint zero, testers collaborate with the rest of the team to promote the following testing activities:
Define testing metrics for the development cycles.
Define test environments to support the testing goals.
Define the testing tools to be used.
Define high-level test strategy at the feature and story level.
Assist the team in determining the quality items added to the general Definition of Done.
Collaborate with other team members to define the acceptance tests of stories.