about services publications events blog
Pichler logo

All Things Product Owner

Archive for February, 2010

Envisioning your Product

Feb
22

Being able to envision what a new product or the next product version should look like and do is essential for getting there. Traditionally, organizations tend to carry out extensive market research, product planning, and business analysis activities up front resulting in a product concept or a market requirements specification. Some fall into the other extreme: They rush into the first sprint without having thought about the product’s customers and users and its value proposition.

Neither of these two approaches is desirable. The first one ignores the likelihood of change. It assumes that customer needs and how they are best met can be correctly predicted upfront rather than viewing flux and unpredictability as dominant factors in software development. The latter leaves the team without a common goal making it virtually impossible to understand what it takes to develop a successful product. Since envisioning the product results in a product vision in Scrum, looking at the product vision will help us understand what visioning should comprise in an agile context.

As its names suggests, the vision describes what we believe the future product will roughly look like and do – a sketch of the future product, as I put it in my book Agile Product Management with Scrum. The vision should act the overarching goal, galvanizing and guiding everyone involved in the development effort, and is the product’s reason for being. It selectively describes 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:

  • Who is going to buy the product? Who is the target customer? Who is going to use the product? Who are its target users?
  • Which needs will the product address? What value does the product add?
  • Which product attributes 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?
  • How does the product compare against existing products, from both competitors and the same company? What are the product’s unique selling points? What is its target price?
  • How will the company make money from selling the product? What are the sources of revenue and what is the business model?
  • Is the product feasible? Can the company develop and sell the product?

How much effort is necessary to answer the questions above depends on a number of factors including the degree innovation and the complexity of your product. As the product matures, the visioning work tends to decline. (After the successful launch of a product, I usually employ the product roadmap to capture the goals for the upcoming product versions.)

To minimize the visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.

You can find more information on creating a product vision in my book Agile Product Management with Scrum. The book has a whole chapter dedicated to product planning and discovery in Scrum.

spacing rule

Grooming the Product Backlog

Feb
15

Like a garden growing wild when left unattended for too long, the product backlog becomes unwieldy when it’s neglected. The backlog needs regular attention and care; it needs to be carefully managed, or groomed. Grooming the product backlog is an ongoing process that ensures that the product backlog is DEEP. It comprises the steps listed below. These are not necessarily carried out in the order stated.

  • New items are discovered and described, and existing ones are changed or removed as appropriate. A great technique to capture functional requirements on the product backlog is user stories. User stories describe functionality form a user’s perspective, are easy to use and can be smoothly refined incrementally.
  • The product backlog is prioritized. The most important items are now found at the top. The lower-priority items are found at the bottom. It’s clear which items will participate in the next release or product version and in which order the items will be implemented.
  • The high-priority items are prepared for the upcoming sprint planning meeting; they are decomposed and refined until they are ready: The are clear – the entire Scrum team has a common understanding of the items. They are feasible – small enough to fit into the next sprint so they can be transformed into a product increment according to the definition of done. And they are testable – they can be validated so that the product owner can assess if an item was successfully implemented or not at the end of the sprint.
  • The team sizes product backlog items. Adding new items to the product backlog, changing existing ones, and correcting estimates make sizing necessary. Common measures of size are story points and ideal days. A great technique to facilitate team estimations is planning poker. Note that team members don’t estimate the work individually. The team agrees on the likely team effort.

Although the product owner is responsible for making sure that the product backlog is in good shape, grooming is teamwork in Scrum. Items are discovered and described, prioritized, decomposed, and refined by the entire Scrum team – Scrum allocates up to 10% of the team’s availability for grooming activities. Don’t forget to involve stakeholders including customers, users, marketing, service and sales as appropriate.

Grooming the product backlog collaboratively creates a dialogue within the Scrum team and between the team and the stakeholders. It removes the divide between “the business” and “the techies.” It eliminates wasteful handoffs, and avoids miscommunication and misalignment. Requirements are no longer handed off to the team; the team members co-author them. This increases the clarity of the requirements, leverages the Scrum team’s collective knowledge and creativity, and creates buy-in and joint ownership.

When do the grooming activities take place? Some teams like to do a bit of grooming after their Daily Scrum. Others prefer weekly grooming sessions or a longer grooming workshop toward the end of the sprint. Grooming activities also take place in the sprint review meeting when the Scrum team and the stakeholders discuss the way forward; new backlog items are identified and old ones are removed.

Make sure you establish a grooming process so that the activities are carried out reliably, for instance, by starting with weekly grooming workshops. A well-groomed backlog is a prerequisite for a successful sprint planning meeting. The backlog now contains the right items and its high-priority items are ready for consumption in the upcoming sprint.

Find out more about product backlog grooming in my book Agile Product Management with Scrum: Creating Products that Customers Love, or attend one of my product backlog grooming workshops.

spacing rule