Sprint 0 is The Best Way to Prepare Your Agile Product Team for Sprint 1

DSRUPTR - Joe Smiley

I mentioned in my post Developing a Digital Product Strategy and Roadmap, that Strategic Product Planning is the optimal method to begin the process of developing a digital product, because it guides the development of the product strategy, business plan, and design direction. These are all required to lead your Agile team in Sprint 1 and beyond.

Now that you’re done with Strategic Product Planning, I recommend implementing a Sprint 0, and here’s why…

img - agile development phases sprint 0

What is Sprint 0?

Sprint 0 is an awesome way to continue preparing an Agile product team for Sprint 1, typically through a “mini” sprint (1 week) to get the team together, finalize the last few product artifacts, and start user research, design, and development.

The goal of Sprint 0 is to be fully prepared to hit the ground running in Sprint 1 with a prioritized backlog, a few user stories that have been validated via user research, and all of the business and design artifacts completed.

img - dual track discovery and dev2

If you utilize Sprint 0, then the priority should be on getting the deliverables (outlined in this post) completed and a few user stories validated and ready for development in Sprint 1.

Since Sprint 0 is typically 1 week, don’t worry about doing any development. However, if the team can validate a couple user stories early in the week, then consider developing those to completion just to get the team into the development rhythm. Typically the Sprint 0 velocity will be very low compared to other sprints – don’t worry, you’re still delivering a ton of value!

Also, I prefer more preparation than less, and recommend that teams take 2-3 weeks if necessary in order to be fully prepared for Sprint 1.

To simplify Sprint 0, I’ve provided detailed responsibilities for each team member…

title - stakeholders

Stakeholders should actively participate in the formation of new products.

They can discuss the new product directly with the Product Manager, add their ideas into the opportunity backlog, and provide inputs into the release plan.

Additionally, they can attend the Release Planning session and Sprint Review meetings to review progress and provide guidance.

title - product manager

The Product Manager built a solid foundation in the Strategic Product Planning process, by researching competitors and customers, developing the product strategy and business case, and creating the product roadmap and KPI’s.

Now the Product Manager will continue working on the following deliverables…

Draft the “Definition of Done”
Product teams should have a “Definition of Done” that defines a simple list of activities (writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.) that add verifiable/demonstrable value to the product.

These definitions bring clarity to the team through a shared understanding of what it means to be “finished.”

The “Definition of Done” can be developed for one or more levels:

  • Definition of Done for a feature (story or product backlog item)
  • Definition of Done for a sprint (collection of features developed within a sprint)
  • Definition of Done for a release (potentially shippable state)

When the Product Manager completes the draft definitions, he should socialize them with the team and ask for feedback. Once finalized, it’s great to display them on the wall in the team space and/or in the online collaboration space.

Develop & Prioritize the Product Backlog
Product Managers need to create the initial product backlog by developing user stories and acceptance criteria, which can be done both on their own and/or with the whole product team. There needs to be enough user stories for a few to be pulled in during Sprint 1, even Sprint 0 if your team has the time/capacity.

The Product Manager should setup a backlog grooming and estimation session with the whole team. Once the backlog is groomed and estimated, then the Product Manager will prioritize them and decide whether a few stories can get pulled into Sprint 0.

Create the Initial Release Plan
The goal of initial release planning is to estimate roughly which features will be delivered by the release deadline (presuming the deadline is fixed), or if the scope is fixed, to choose a rough delivery date for a given set of features. This information helps the Product Manager to decide whether or not the project will produce enough ROI to at least pay for itself, and informs his go/no-go decision.

Initial release planning meetings last 1-2 days, where the Product Manager presents to Stakeholders the prioritized features to be delivered along with rough estimates from the developers, and the team lays out a release plan by assigning features to the first few releases.

The meeting should spark conversations between the Product Manager, Developers, and QA, as they work through issues, dependencies, and risk in order to finalize the release plan.

title - design team

The Design Lead set a solid foundation in the Strategic Product Planning process, with the development of the UX vision & strategy, design principles, and style tile. Now the whole Design Team works together on the following deliverables…

Conduct User Research
Building amazing products requires deep knowledge and understanding of the people you are building the product for. The optimal method for gaining insights is to engage with customers directly: talk with them about their common tasks and goals, background, and influences, as well as have them provide feedback – capturing their feelings, likes, dislikes, and ideas – on one or more prototypes.

The rule of thumb is to test each opportunity with at least 15 end users in order to see a trend in the feedback data.

It’s important to listen intently to everything your customers say. Take a lot of notes. Record these interactions if possible.

img - empathy map

Engaging with users will allow you to empathize with them, where you’ll be able to understand – and document using the Empathy Map above – their needs, thoughts, emotions and motivations.

Develop User Personas
The purpose of User Personas is to create reliable and realistic representations of your key audience segments to help guide your team through key product decisions. Your Personas should be based largely on qualitative research, so get off your butts and go talk with your users!

You can also gain insight into users with quantitative user research via surveys, analytics, etc., but it’s preferable that you talk with users directly.

img - persona

I recommend creating Personas for the primary target audiences for the product, focusing on the 2-3 most important segments. The goal of Personas is not to represent all audiences or address all needs in the product, but instead to focus on the major needs of the most important user groups. The key aspects of a Persona include:

  • Fictional name (e.g. Bobby Browser, etc.)
  • Persona Group (i.e. customer segment name)
  • Job title and major responsibilities
  • Demographics: age, education, ethnicity, and family status
  • The goals and tasks they are trying to complete using the product
  • Their physical, social, and technological environment
  • A quote that sums up what matters most to the persona as it relates to your product
  • Photo or drawing that’s representative of their group

One last note worth mentioning is that the best type of Personas can be quantitatively measured in your product once it’s launched.

Design the UX Framework
This step is optional, but I recommend developing a UX Framework if you have a complex product and need a good starting point. Utilizing the analysis from the user research in Sprint 0, the Design Lead can develop the highest priority user flows as well as a few UX templates (e.g. Home page, Content page, etc.) that the UX team can use as a starting point for the digital product. It provides guidance on broader user experience by encapsulating the essence of the UX Strategy & Vision, as well as the Design Principles. It will serve as the initial user experience hypothesis, that the design team can utilize for design iterations and testing, where it can include a few of the following: content layout and structure, navigation, user flows, etc.

img - quote product personality

Create the Product Personality
This step is also optional, but personality is becoming more critical in today’s digital world where voice user interfaces (VUI) and artificial intelligence (AI) are becoming more prevalent, where your product’s success will quickly unfold within the first few minutes a user interacts with your product.

To create a unique product personality, start by reviewing the Product Strategy & Vision and Personas to get inspiration. Next, imagine your product is human, and select a specific archetype from the list below that best reflects the character you want to reflect (or develop one of your own):

img - personality brand archetypes

Next, choose the personality attributes that best match the archetype, where you should consider aligning one or more attributes with your Personas:

img - product personality

Use these guiding questions to help narrow your attribute selections:

  • What does this product represent?
  • What kind of attitude does it have?
  • What tone of voice does it use?
  • What causes does it stand for?
  • Who or what does it NOT like?

Create a list of the personality attributes that your team creates. Review them and resolve any conflicting attributes. Narrow the list to the top 3-4 attributes, and prioritize them accordingly.

Read more in my post about creating a unique product personality.

title - dev team

The Dev Lead set a solid foundation in the Strategic Product Planning process, with the development of the Product Architecture, design documentation, and setting up the development environments. Now the whole Development Team meets to work together on the following deliverables…

  • Review and groom the product backlog with the Product Manager or whole team
  • Discuss the user stories and create high-level estimates for the higher priority stories
  • Code, test & QA user stories (if possible)
  • Develop estimates for each user story that is pulled into Sprint 0 (if any)

Conclusion

Sprint 0 is especially important for teams that are new to Agile, or for products with a lot of complexity that require further exploration before Sprint 1. Or simply to give teams a chance to get to know each other and collaborate on something smaller before diving into the full sprint cadence. Just remember that if you don’t have a Sprint 0, then all of the deliverables mentioned above need to be completed in the Strategic Product Planning process.

With everything completed in the Strategic Product Planning and Sprint 0, your product team should be ready to hit the ground running on the first day of Sprint 1!

Any chance there’s a faster way to implement a new product concept?

Yes! I recommend using a Design Sprint.

Leave a Reply