It’s critical when developing an app that your team is hyper-efficient right from the very start! During the development process, it is especially important that things are executed flawlessly. Following a framework such as agile or scrum should always be at the heart of that development process, and at the heart of agile development is the concept of the sprint.
What is a sprint
Think of a sprint the same way you would think about running. Imagine you are a marathon runner with those looming 26 miles ahead of you. The marathon represents your project and each mile within that race is a sprint. All sprints (“aka miles”) should take the same amount of time. It’s important to measure how you do at the end of each mile during a sprint and not at the end of the race.
Kevin Schlabach compares agile development to the way a good marathon runner approaches their task. He shares that it is essential for the runner to check their pace as they go. He/she must strive to hit a 5 min mile on the first mile if they desire to average 5 min miles over 26 miles. “Good runners take great care to know whether they’re ahead or behind of their goal throughout the entire race; and further, care to know whether they are keeping a “sustainable pace”, quite different than the approach of a “sprinter.”
During a sprint, a development team is given a set amount of time to complete a specific amount of work. They must move decisively and quickly. A sprint defines an interval – (1 or 2 weeks) – in which a team agrees to take on a set of work that they think they can deliver fully to completion.
The goal of each sprint is to complete the user stories that the team agrees to take on. The development team must then create production-level software that meets 100% of the requirements as specified in each user story.
The importance of the sprint
The big advantage of the short time frame of a sprint is that developers focus on pushing out small, incremental changes rather than larger ones. As a result, far less debugging is required.
A sprint sets a cadence for how quickly work is completed. It allows for proper testing and at the end of the process produces a quality product. Over time, sprints can be measured in trackable units which helps the team maintain a rhythm over a long period of time, and deliver high-quality software the entire way.
Before the first sprint can begin, however, there needs to be additional planning. This ensures everything is in place for the dev team to operate at peak efficiency, which is where Sprint Zero comes in. Think of Sprint Zero as the preparation you put in weeks before you run that marathon. During your prep, you would take time to get quality rest, eat the right foods, stay hydrated and fueled up, etc.
What is Sprint Zero
It’s easy to recognize that in order to run a marathon, you must be well prepared and the same goes for any dev project. Sprint Zero is the preparation you put in before the project begins. It is all about looking at the overall development plan and considering what needs to be in place for the team and the process to be successful.
Here are the 3 key things that happen during a Sprint Zero:
- Story grooming – the project manager (PM) and the developers go through each and every user story meticulously to ensure there is a clear understanding and no gaps.
- Project Setup – the team makes sure all key project accounts are set up including the Git Repository, Dev & Staging Environments, 3rd party integrations, etc.
- Building a Sprint Plan – the PM and Tech Lead partner together to map out a full sprint plan for the project by selecting which stories will be tackled within each sprint.
The overall goal of Sprint Zero is for the development team to be as productive as possible and to prepare as much as they can. It’s all about gaining an understanding of which direction you want to head and preparing for that. The expectation, in the end, is still to get to a minimum viable product or MVP.
This sprint should always be kept lightweight and relatively high level. It focuses on gaining an understanding of where you want the project to head while keeping velocity low. Sprint Zero is shorter than a traditional sprint and on average should last about a week but could be shorter.
What else happens during Sprint Zero
During Sprint Zero you will:
- Review and agree on a process, especially around standards for user stories (e.g., how are the requirements written including acceptance cases, designs, etc.).
- Create a prioritization of features or a list of stories.
- Ensure any potential roadblocks, whether organizational or technical are accounted for.
- Review how user stories are accepted into the sprint and determine what it means to be complete.
- Define the QA process. How will bugs be handled? Ideally, any bugs found are fixed immediately.
- Ensure all tools and infrastructure are set up, where the code will be stored, and determine if there are there build machines and which tools you will utilize for the build.
- Determine a meeting schedule – ideally daily standups, weekly client sprint reviews, and demos at the end of every sprint.
- Prepare for all third-party vendors (push notification, text prov, email prov, CRM’s, staging environments, dev end, hosting, and any additional PM or communication tools that would need to be used in development).
- Create a usable piece of code, however small, and encourage a minimal environment for writing code.
Why Sprint Zero?
The main benefit of Sprint Zero is that it allows a team to organize and plan for the work of writing code before any code is actually started. This will help provide clarity immediately. By avoiding any delays or obstacles impacting the project, Sprint Zero offers an opportunity to plan a framework for success and ensure a sprint environment is set in place first.
In essence, Sprint Zero makes sure you’re ready to run that marathon before you even step foot on the starting line!
Trying to race to the finish with your own app-development project? Let’s do it! Schedule your fee free consultation.
