Building a Product Users Want: From Idea to Backlog with the Vision Board
User Story Examples - Download Now!

Many of you will know Roman Pichler as the author of Agile Product Management with Scrum. For the last few years Roman has been working on various ideas to support envisioning and ideation. I’ve asked him to write a guest post here describing his Vision Board and how it connects to Scrum’s product backlog. I’m sure you’ll find his ideas very interesting.
—Mike

Vision and Backlog

Scrum is a great framework for building a product with the right features. It encourages the use of a vision shared by the product owner, the ScrumMaster, the development team, and the stakeholders, and it provides a product backlog that allows the team to move towards the vision by creating product increments.

Unfortunately, there is little guidance on how the backlog is derived from the vision. Once we have an idea for a new product or new features, how do we know which user stories we should include in the backlog? And how can we tell who should be at the sprit review meeting to help us understand if we are building the right product?

 

 

 

 

 

In the worst case, we could implement the wrong stories, get feedback from the wrong people, and build a product nobody wants and needs.

Four Questions

I have found it very valuable to answer the following four questions before stocking the product backlog:

  • Who are the users and customers?
  • Why would they use and buy the product?
  • What makes the product special? What are its key features?
  • What are the business goals the product should deliver and how are they met?

Without knowing who the users and customers are and why they would employ the product, it’s impossible to write meaningful user stories. Similarly, we don’t understand what should make the product special and stand out, it is difficult to make informed decisions about the product functionality, the user interaction, the UI design right, and even the key architecture and technology choices. And without being clear on the business goals and the product’s business model, it will be hard to justify the investment and attract a budget.

Enter the Vision Board

The Vision Board is a simple yet effective tool that helps agile teams capture their vision and systematically answer the four questions above. The following picture shows the Vision Board, and I explain its sections below. You can download the tool for free at: romanpichler.com/tools/vision-board/

Vision Statement is a concise summary of your idea that describes your intention and motivation.

Target Group describes the market or segment you want to address. You should state who the users and its customers are likely to be.

Needs describes the product’s value proposition: the problems and pain points the product removes, and the benefits or gains it creates for the users and the customers. The section should make it clear why people will want to use and buy your product.

Product summarises the three to five features that make your product stand out. These are likely to correlate to its unique selling proposition, and they should address the needs identified.

Value explains why it’s worthwhile for your company to invest in the product and how the business goals can be achieved. Sample goals are increase revenue, enter a new market, reduce cost, develop the brand, or gain a technological advantage.

Let’s take a look at an example to make this more concrete.

A Sample Vision Board

Say we want to create a new game for children to help them enjoy more about music and dancing and learn about the topics. Then corresponding Vision Board could look like this:

The board above captures the overarching vision. It states children aged 8-12 as the intended users of the game and their parents as the customers. It lists three reasons why the kids would want to play the game, the key features of the product, and the business goal and how the business model could work.

The good news is the Vision Board above helped me to think through the market the value proposition and the business model of the new app. The bad news is it contains lots of untested assumptions that would make it a gamble to use the board to derive the product backlog. What’s required instead is to systematically identify and validate its assumptions.

Validation with the Vision Board

Validating the Vision Board starts with identifying the most crucial assumption, the assumption that must be tested now to avoid late failure – finding out too late that the problem is not worthwhile solving. Once you have identified the appropriate assumption, decide which method is best to address it and who should be in your test group.

Some of my favourite techniques for testing Vision Board assumptions are direct observation – watching target users and customers get a job done, for instance, observing how children play music games on the computer today – and problem interviews – talking to members of the target group about how they accomplish a job today, for instance, what’s good and bad about playing computer games, particularly those related to music and dancing.

 

 

 

 

 

 

 

 

 

 

Once you have run a test, collect the relevant data and analyse it. Then use the newly gained insights to change the board either radically or incrementally. An example of the latter is to adjust a need or to replace a key feature. But a radical change – called a “pivot” in Lean Startup – profoundly affects one of more sections of the Vision Board. The vision stays true but the path towards the vision changes. For instance, changing the product to an app that teaches children dancing by encouraging them to try out the moves themselves would be a pivot for the dance game.

From Vision Board to the Product Backlog

Once you have validates the key risks and critical assumptions on the Vision Board, use it to create the initial product backlog and discover the right stories, interactions, and UI design, as the following picture illustrates.

 

 

 

 

 

 

 

With your initial backlog and the Scrum team in place, you are ready to start sprinting.

Summary

Before writing user stories, coming up with user interface ideas or the user interaction, make sure you understand who the users and customers are, why they would use and buy your product. Find out what makes your product special, what your business goals are, and how you can meet them. As Joel A. Barker puts it: “Vision without action is merely a dream. Action without vision just passes the time. Vision with action can change the world.” You can learn more about working with the Vision Board and download the template for free at: romanpichler.com/tools/vision-board/


Get 200 Real Life User Stories
Examples Written by Mike Cohn

Get 200 Real Life User Stories<br>Examples Written by Mike Cohn

See user stories Mike Cohn wrote as part of several real product backlogs.

9

Posted:

Roman Pichler

About the Author

Roman Pichler is a leading agile product management and Scrum expert. He has more than 10 years experience in training and coaching product managers and product owners, and a long track record in helping companies apply agile practices to achieve business success. Roman is the author of “Agile Product Management with Scrum”. He has created several product management tools, and he writes a popular blog on product ownership at: www.romanpichler.com/blog

The discussion here is closed but join us in the Agile Mentors Community to further discuss this topic.

Go to AgileMentors.com