The Product Owner’s Checklist for the First Sprint

By Roman Pichler, 17th December 2014
Photo courtesy of Pexels

Scrum is a popular agile framework for developing a product with the right features and the right technologies. Unfortunately, it does not state the prerequisites for kicking off a Scrum project and for starting the first sprint. As a consequence, I find it not uncommon that product managers and product owners are unsure about the work they should do prior to the first sprint. This post offers a checklist to help you do the right upfront product management work.


The Essential Upfront Product Management Work

Scrum is agnostic about the work that has to be done before you can create an initial product backlog  and run the first sprint, be it for a brand-new product or for an existing one that you have just taken on. In fact, it doesn’t make any recommendations. But this does not mean, of course, that you don’t have to or should not do any work before you move into Scrum and kickoff the first sprint. As the product owner, you should do just enough work to have the following artefacts in place and be able to answer the following questions:

Artefacts Questions to Address
Shared Vision
  • What are the purpose and the motivation for developing, marketing, and selling the product?
  • What is the positive change the product should create?
Valid Product Strategy
  • What market or market segment does the product serve? Who are the customers and the users?
  • What problem does it solve, or which benefit does it provide?
  • Why would people choose it over a competing offer? What makes it special or desirable?
  • What are the business goals? Why should your company invest in the product?
Valid Business Model
  • How does the product generate the desired business benefits?
  • How is it monetised? What are the cost factors for developing, marketing, and selling the product?
  • What marketing and sales channels are used?
Realistic Product Roadmap
  • How is the product going to be delivered over the next 12 months? What are the release dates?
  • What goals or benefits do the individual releases provide?
  • What metrics are used to determine success?
Personas
  • What characteristics, attitudes, behaviours, and goals do the customers and users have?
  • Who is the primary persona?

The items in the table above form a checklist to help you assess if you are ready to apply Scrum. You may have to tailor the checklist to you specific needs. For an in-house product, a valid business model is typically less applicable than for a commercial one, for instance. Similarly, if you build a product for a client then the strategy should address the client’s business goals rather than yours.

You can use choose from a range of tools to capture the answers to the questions above. For instance, my Product Vision Board describes the vision and the strategy, Alexander Osterwalder’s Business Model Canvas defines the business model, my GO Roadmap captures the product roadmap, and my persona template helps you describe the personas. The point is not to use a specific tool but to ask the right questions and to answer them effectively. To put it differently, if you struggle with the questions then a tool alone is unlikely to help you.


Vision and Strategy Take Priority

Of the four artefacts listed above, the vision and the product strategy are particularly crucial. You should hence pay particular attention to them and create them first. Here is why:

If you don’t have a shared vision, then you lack an overarching goal and a reason for creating the product. You will consequently struggle to motivate, guide, and align the stakeholders.

If you don’t know who the customers and the users are and why they would buy and use your product, then you cannot make informed decisions about the user experience and the product features. Imagine writing a user story without knowing who the user is. You would have to speculate and dream up the story.

What’s more, collecting meaningful feedback becomes virtually impossible, as you are likely to ask the wrong people and receive unhelpful feedback. This would cause you to draw the wrong conclusions and make the wrong changes to your product; or you would conclude that the users don’t have a clue, that you should ignore their input, and that you know what’s best for them anyway. Neither approach maximises the chances of creating a successful product.

Finally, if you don’t know what the business goals are and why your company should invest in your product, you don’t understand the value that the product should create for your business. This will make it difficult to attract funding and to get the right people.


Business Model, Product Roadmap, and Personas Come Second

Having a vision and product strategy is great but not always enough to start the first sprint effectively. For commercial software products it is also important to understand how you can meet the business goals and how you can monetise your product. Otherwise you won’t be able to create a financial forecast, and your company is unlikely to be in a position to make an informed investment decision.

Similarly, a product roadmap details the product strategy and states how it will be implemented. Without a roadmap, you haven’t made explicit when major releases will happen, what benefits they should provide, and how you are going to determine their success. This will make it difficult to align the stakeholders including marketing, sales, and support, to staff the development team, and to show that you have done a great job and deserve a pay rise or a bonus. Take look at my post Getting Stakeholder Engagement Right find out how you can effectively identify and involve the stakeholders.

Without personas I find it difficult to discover the right user interaction, the right user interface design, and the right functionality. Who do the user stories serve and why do they add value for the users? And without a primary persona, I find it hard to prioritise and decide, for instance, if a story or scenario should make it into the release or not and if it can be postponed or only partially provided. This makes managing the product backlog very challenging.


Do Just Enough Upfront Work

While you don’t want to rush into the first sprint, you don’t want to spend more time and effort then absolutely necessary to answer the questions in my checklist above. A great way to carry out the upfront work is to employ a Lean Startup-based approach, as the picture below illustrates.

ProbemValidationAndProductDevelopmentThe diagram above shows two key steps, problem validation and product development. The first step iteratively creates a shared vision, a valid product strategy and business model, a realistic product roadmap, and helpful personas. This is likely to require some research and validation work, for instance, direct observation, problem interviews, and developing minimum viable products (MVPs). The second step leverages Scrum and builds the actual product, a product with the right features and the right technologies. It starts with creating an initial product backlog and finishes with the launch of the new release. I describe the two steps in more detail in my post “New Product Development with Lean Startup and Scrum”.

How much upfront work is needed depends on how many risks your strategy and your business model contain. The more risks there are, the more time and effort you typically have to invest. The risks in turn are related to your growth strategy and to the technologies used to build the product. Developing a new product for a new market carries significantly more risk than updating an existing product for an existing market and therefore tends to require more upfront work, for instance. As a consequence, the amount of effort you may have to spend varies. It can range from a few days for a straight-forward product update to a few months for a diversification effort.

As the product owner, you should lead the problem validation effort and you should shape the vision, the strategy, the business model, the roadmap, and the personas. If that’s not the case then make sure that the necessary prep work has been carried out, that you know the answers to the questions stated in the checklist above, and that the appropriate artefacts are available. If that’s not the case you should consider delaying the start of the first sprint and carrying out more research and validation work.

Summary
Article Name
The Product Owner’s Checklist for Starting the First Sprint
Description
Learn which product management artefacts should be in place before you move into Scrum and start the first sprint.
Author

Learn More

You can learn more about the necessary upfront work with the following:

Source: http://www.romanpichler.com/blog/the-product-owners-checklist-for-the-first-sprint-in-scrum/

RSS Feed

Tags related to this post:


5 comments on “The Product Owner’s Checklist for the First Sprint

  1. Ash Ganatra

    I found this extremely useful thank you very much 🙂

  2. Ben Maynard

    Really useful as always Roman, many teams have asked the question “what has to be in place prior to sprint 1” and its great to see a check list that focuses on the (often overlooked) product management aspects.

    As an aside I particularly like your comment on the point being not to use a specific tool but to ask the right questions and getting effective answers, I feel this is a common problem across many aspects of product development & delivery.

    • Roman Pichler

      Thanks a lot for your feedback, Ben. I am glad that you find the post helpful.

  3. Sarah

    Thanks Roman, this is exactly the info I was looking for. I’m about to start building my first app and while it’s exciting, it’s pretty daunting too.

    • Roman Pichler

      Thanks Sarah! Good luck with your app!

Leave a Reply

Your email address will not be published. Required fields are marked *