Foxbox performs application development as a service for our clients as a core business offering. These applications are of a known scope, and therefore should executed on a fixed timeline and within a fixed budget. Traditionally, this type of contracting work has used (and arguably gave birth to and fed) the “waterfall” approach to project management. Foxbox has embraced Scrum as our agile (i.e. non-waterfall) project management methodology. However, as an agency, part of our core value proposition is that we can accelerate the start of a project in ways our clients cannot – we can bring a team, infrastructure, and processes which allow us to deliver more value, faster. At Foxbox, this starts with Sprint Zero.

The Scrum Alliance, provided the following working definition for sprint zero:

1. Sprint Zero should be used to create the basic skeleton and plumbing for the project so that future sprints can truly add incremental value in an efficient way. It may involve some research spikes.
2. Minimal design up front is done in Sprint Zero so that emergent design is possible in future sprints. This includes putting together a flexible enough framework so that refactoring is easy.
3. For minimal design up front, the team picks up a very few critical stories and develops them to completion. Since these are the first few stories, delivering them includes putting the skeleton/framework in place, but even Sprint Zero delivers value.

This same article also identifies some things that are not necessarily part of Sprint Zero:

1. The team needs to be assembled in Sprint Zero.
2. Organization and logistics need to be set up in Sprint Zero.
3. Consider planning, product backlog setup, and design.

At Foxbox, we start every project with discovery. Ideally, this is a Design and Discovery service we are contracted to perform to help our clients refine their product and business vision. Sometimes this is part of our exploration process as we learn about a potential client and the work we are looking to perform. If we are unable to complete this work before we officially start an application development project, this is done in Sprint Zero. Regardless of how this Design and Discovery phase is coordinated, it meets this definition of Sprint Zero keeping us in line with this definition and Scrum’s tenants.

Even though every client is different, this is not our first rodeo (so to speak). We have already established processes so they can be tailored and repeated. We have defined an organization structure which allows us to drive continuous improvement. In other words we can maximize the value of the right side of the Agile Manifesto while continuing to value the items on the left more.

So what can we do during Sprint Zero that our clients can’t? We can assume that they can do the things that Sprint Zero should include, so let’s explore this under the above examples of what Sprint Zero should not be but definitely could be.

Foxboxers Assemble!

So according to the Scrum Alliance, the team does not need to be assembled in Sprint Zero. But what if the team is assembled? Our ideal teams have a mix of experienced Foxboxers and newer joiners and even some members who worked together on previous projects. This allows us to bring in the best of Foxbox and inject diverse viewpoints to provide the team empowerment that is a key to successful Scrum. While we do value responding to change, our clients value predictable pricing based on a clearly-defined staffing plan. Setting this upfront gives our clients and our business a baseline that we can adjust for success as we execute the project.

The Line Between Disorder and Order

According to Sun Tzu, “the line between disorder and order lies in logistics.” Another way to say this is that logistics is the line between disorganization and organization. While it isn’t necessary to have an organization or logistics to start a Scrum project, plugging a team into an organization and having logistics from the start is a huge advantage.

From the very beginning, we have tools like Slack, Zoom, Google Workspace, Miro, and Figma to help us in our Design and Discovery projects. During Sprint Zero, we can add tools like Jira, GitHub, and TestRail as well as best practices and automation around public cloud management. Our teams have support structures beyond their immediate project to answer questions around technology, processes, etc. Even when the the client brings their own processes and tools or organization, we are able to draw on our past experience and best practices act as a trusted advisor to help make sure our joint project is successful.

Plans are Useless, but Planning is Indispensable

This quote from Dwight Eisenhower is one of my favorites when talking about Agile. In Agile, you don’t simply throw away the concept of planning entirely, you embrace the fact that no amount of planning can prepare you with the reality of what you will face. Again, our clients are trusting us to deliver some result for some fairly-predictable amount of money. We are transparent on the risk around the scope of work, our understanding of it, our technical abilities, etc. but the client will always expect some degree of predictability. This requires at least some macro-level planning. We want to enter Sprint 1 with a high-level plan that we can measure our progress against. Ideally this will capture all of the major milestones, but more importantly allows us to add new scope and communicate the impact to our clients. All of our progress needs to be tracked to this plan so our client knows the definition of done for the project and where we are on the roadmap to get there.

TL/DR;

At Foxbox, our definition of Sprint Zero is simple: complete the work required to start Sprint 1. As a company, we already completed a “Foxbox Sprint Zero” to determine how we are organized, how we work, etc. We continuously improve that over time while adding our preferred tools and best practices. As a result, we can now follow a repeatable process to exit Sprint Zero at a higher level of readiness which means we can deliver more value in Sprint 1.