Welcome to my new blog series, in which I will explore “20 Controversial Topics of Debate in Agile“ that I regularly debate with other Agilists. These topics [still] seem to come up repeatedly whenever I join or launch a new Agile Scrum Team.
Here is a preview of the debated topics I will discuss in this series:
- Can you use a Sprint 0 in Agile?
- Do you need Documentation in Agile?
- Is there a “right” way to write User Stories?
- What’s the best way to write Acceptance Criteria?
- How long should your Agile sprints be?
- Should all your Agile teams be run the “same” way?
- Which “flavor” of Agile is best?
- Can agile co-exist with waterfall?
- Story Size – What’s an Epic, Theme, Feature…?
- Can the Scrum Master be a team member, too?
- Can distributed Agile teams work?
- How should you estimate in Scrum & Agile?
- Is it OK to add items to the current Sprint?
- How should you manage your Agile backlog?
- Can an Agile team have more than one Product?
- What is the optimal size for Agile teams?
- Should Agile teams stay together?
- How should you handle defects in Agile?
- Can a hybrid of Waterfall and Agile succeed?
- What are the official roles on an Agile Team?
I hope you will join me on this journey and give me your opinion about each of these debates. The first debate is one that continues to rage on in Agile circles, and it is…
Debate #1 – Do you need a Sprint 0?
Sprint 0 is heavily debated amongst Agile practitioners. The 2017 version of the Scrum Guide implied that there should be no special sprints that were longer or shorter or that did not deliver value via a done increment. However, the newest version of the Scrum Guide is less prescriptive.
So, should you have a Sprint 0, or not? Here are some arguments for and against having a Sprint 0:
Yay
- It helps team members to understand the work to be started
- Boosts developer confidence for tackling the work
- Allows the developers to figure out the best way to deliver the project
- Gives team time to form and get to know each other
- Provides a solid foundation on which to build
Nay
- It establishes a precedent that certain sprints or sprint types have unique rules
- If the work is like work done previously, it’s a waste of time
- There’s nothing potentially shippable at the end of it
- Doesn’t usually result in an increment valued by the Product Owner
- It’s misused to describe the planning that occurs before the first sprint
Establish a Technical Foundation
Personally, I am not a fan of having a Sprint 0. But others do; like most debates about Agile, it depends. If a technical foundation is needed to start development, it’s likely a Sprint 0 will be used. This is especially true of projects that require hardware, software, or infrastructure setup.
Preparing and organizing for sprinting
Sometimes a team needs time to get set up and organized. The length of such a sprint may be longer or shorter than a normal development sprint would be. This could include activities such as:
- Establishing a Product Goal
- Defining the Product Vision
- Having a User Story Mapping workshop
- Creating an initial Product Backlog
- Setting up the Scrum Team
- Having a kickoff meeting
- Creating a Release Plan
- Etc.
Dig out of technical debt
Other times, this first sprint is used to dig out of technical debt from other projects before work can begin. You can’t start building a valuable product on a huge pile of tech debt.
What do you think?
While a Sprint 0 is not generally advocated for the reasons listed in the “nay” column above, many organizations still use this approach. Depending on what type of project you are doing, it may not be needed, but sometimes organizations feel that it is.
Now, it’s your turn. Do you typically include a Sprint 0 when you start work on a new project or product? Why or why not? Please share your thoughts either for or against having a Sprint 0.