Before a scrum team is ready to start the first sprint, some prep work has to take place: “The minimum plan necessary to start a scrum project consists of a vision and a product backlog,” writes Ken Schwaber in his book Agile Project Management with Scrum. Scrum does not define how the vision and the initial product backlog are created, nor does it provide guidance on how much time and effort should be invested in the visioning activities. This is in stark contrast to traditional approaches, which emphasize carrying out market research, product planning and business analysis work before the software is developed.

This article explores the question how much visioning is required in scrum. It focuses on the product vision as one of the key visioning artifacts and suggests keeping the visioning investment to a minimum.

Envisioning the Product
Envisioning the product results in the product vision—a sketch of the future product. The vision is the product’s reason for being. It should act as the overarching goal, galvanizing and guiding people. The product vision should selectively describe the product at a coarse-grained level, capturing the product’s essence—the information considered critical to develop and launch a winning product. An effective vision should answer the following questions:

• Customers and users: Who is going to buy the product? Who are its target customers and its target users?
• Needs: Which needs will the product address? What value will the product add?
• Features: Which features are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
• Competitors: How does the product compare against existing products? What are the product’s unique selling points?
• Revenue sources: How will the company make money from selling the product? What are the sources of revenue and what is the business model?
• Feasibility: Is the product feasible? Can the company develop and sell the product?

When you develop the product vision focus on the needs of its target customers and users. Bear in mind that the product is only a means to an end. People don’t buy products only for their features. Products are purchased to address needs and to realize hopes and dreams. We don’t buy an iPhone, for instance, because it offers the ability to send emails and text messages or to make phone calls. We want to communicate, conveniently access information and be entertained while we are on the move. What’s more, some products are status symbols that express the owner’s wealth and ambition. I remember some of the early iPhone adapters showing off their phone in business meetings by putting it on the table in front of them.

Once the product vision is in place, we can derive the product backlog from it. The backlog details the vision and makes it implementable. The initial product backlog tends to be sketchy containing many coarse-grained items. But it quickly evolves, as the scrum team gathers customer and user feedback and learns which functionality is required and how it is best implemented. New items are added, existing ones changed or removed; large items are progressively decomposed and detailed until they are ready to be pulled into a sprint.

Determining the Likely Visioning Investment
The visioning effort depends on what is required to create an effective vision and an initial backlog. This in turn is influenced by the product’s lifecycle stage and its complexity.

The younger a product is, the more visioning work tends to be required. A new-product development project may spend several weeks creating the product vision and carrying out necessary prep including developing throwaway prototypes to explore product design, architecture and technology options. As the product matures and incremental updates are released, the visioning effort usually declines. The visioning investment may now range from a few hours to a few days. Visioning now forms a part of creating and updating the product road map.

The same applies to complexity: The more complex a product is, the more visioning effort is usually required. Note that complexity comprises not only the internals of the product – its architecture and technology – but also the functionality provided. A feature-rich product is hence likely to require more prep work than a minimal marketable product – a product with the least amount of functionality that still provides the desired value.

Just-enough Visioning
When envisioning the product, avoid two common mistakes: Don’t rush into the first sprint without having agreed on an overarching goal, without understanding what the future product will roughly look like and do. At the same token, avoid overdoing the visioning work. There is no way to guarantee that the vision is correct, that the new product or next product version will be a certain success. For anyone not blessed with perfect foresight, predicting the future correctly is notoriously difficult; no market research technique can deliver forecasts that are 100% accurate.

I therefore recommend you keep the visioning effort to a minimum. Do as little as possible, but as much as necessary. To find the right balance, try the following: First, envision the minimum marketable product. Secondly, quickly implement the product vision and gather customer and user feedback on early product increments to validate and refine the vision. Thirdly, reduce complexity by creating a simple product – a product that is easy to use and easy to extend and maintain.

Summary
Make sure each scrum team has a shared vision before it starts development. Don’t neglect the visioning work but keep it to the minimum. Put your vision to the test by inviting customers and users to sprint review meetings and by releasing early product increments. Then use the feedback to evolve the product.