Sprint Zero for Product Owners
Sprint Zero for Product Owners
This is the second in a three-part series of blog posts addressing the biggest challenges faced by business analysts (and product owners) on agile teams.
The concept of “Sprint Zero” or “Iteration Zero” has been around for decades. It serves as a container for all those activities that need to be done before the first sprint or iteration is begun. Typically, these activities will include team on-boarding, infrastructure setup, location logistics and the like. Rarely does this “sprint” actually deliver a releasable product.
It’s a very contentious subject. Many authors have argued that Sprint Zero is detrimental to the agile process. In some cases, it may lead to the watering down of team commitment to each sprint’s releasability (see Bowes, Cohn and Leong). In other cases, it might lend itself to the development of a team hierarchy that is inconsistent with agile’s traditionally flat organization structure (Prakash). It is often inconsistent with Lean JIT principles (Leong again). The arguments go on, and I won’t rehash them here.
Whether or not we like the concept of Sprint Zero, however, we can all agree that there is usually work that must be done to prepare for the first iteration that doesn’t quite belong in that first iteration. Whether we call it “Sprint Zero” or the “Project before the Project” or even just “pre-work,” it’s important to get it done.
Unfortunately, almost all of the writing on this pre-work phase is oriented towards development team members. “What about me, the product owner,” you may ask? Don’t worry; this blog post is for you.
While the team is conducting all its pre-project tasks, the product owner needs to focus on doing five key things. Here they are:
#1: Develop the Product Vision
If you don’t have a solid vision of the product, how it will improve the firm’s standing and what value it will provide to the marketplace, then it’s not a good idea to start the first sprint. Whether it is done intentionally or not, your first sprint will indeed have some implicit vision, and it’s best for it to be one that is purposely developed.
Just remember not to invest too much in this initial vision, either with time or emotional commitment. Early visions are almost always wrong to some extent, and it will be your job as the product owner to ensure that the team is building the right product for the market. This will often demand that you set aside your initial assumptions.
#2: Socialize the Product Vision
Once you have the initial vision in place, it is critical that you socialize it among your key stakeholders. In a simple environment, this might only include various customer representatives and technology implementation stakeholders. If you are in a scaled environment, you will also have a product management team and many other functional teams that you’ll need to work with in lockstep.
Why is this work so critical? Because soon the project itself will begin, and by then you won’t have time to defend the product’s vision to cantankerous stakeholders with their own opinions. If you end up in this predicament, it will become supremely obvious to other stakeholders, your management and, most importantly, the team. You must maintain their respect for your product ownership, and socializing the vision will be one of the easiest ways to accomplish this.
#3: Truly Understand Your Stakeholders’ Problems
At face value, this task sounds enormous. Can we ever truly understand their problems to the extent that we’d like? No, of course not. But, it’s still imperative that we understand them well enough at the beginning to start delivering a product that will meet their needs. After all, you’ll soon be making decisions on their behalf.
What does this bare minimum of understanding consist of? I’d suggest the following:
- An understanding of who your customers (or end users) are, the various categories they fall under and how you expect them to interact with your product
- An understanding of their motivations for buying (or adopting) your product, how and why their needs have been unfulfilled so far and how similar products fall short
- A good idea of what they value and how they see themselves
If you can have an intelligent conversation about the above, you’re in good enough shape to start your first sprint. Remember to continue to learn about your stakeholders as time goes on.
#4: Generate Some Ideas for the Sprint One Product
Determining the scope of any sprint is the job of the team (at least in Scrum), and there is good reason for this: If we product owners determined what was in scope, every sprint would be a year-long project. Instead, we let the team do this, and that’s good because they’re the ones who know what they’re doing. But every team must start somewhere, typically with the product backlog, and you need to have some list of items on the backlog so the team can figure out what can be delivered.
What you need prior to your first planning meeting is a collection of small ideas (please) that will provide some minimum level of value to the business on their own…
#5: Write Just Enough User Stories to Support a Probable First Release
… And, once you have that list of small ideas, pick a few and turn them into user stories. You’ll have plenty of time to elaborate on these stories later, but if you have a few picked out and written up, you’ll be in a great position to have a solid planning meeting when the sprint begins.
A few tips here:
- Don’t go crazy with stories. It’s a good idea to meet with the team before you spend any significant amount of time on them.
- Keep them short, sweet and not overly detailed. You’ll flesh everything out with the team later.
- Don’t worry about bigger topics (such as story maps or road maps) at this stage. You won’t have enough content to fill them, and that lack of content will induce you to make more content, which at this point would be a bad thing.
Performing the above activities will help you to have a solid first iteration of your new agile project. As always, maintain an agile mindset as you do them.
What about you? How have you been preparing for new agile projects? Let us know in the comments below.
comments powered by Disqus