Product managers everywhere are constantly challenged to effectively share the vision and timing for a product, especially so in software. Car designers have models and rollout plans. Landscape architects have blueprints and Gantt charts. What is the best mechanism for Agile software products? Clickable mockups and a stack ranked backlog? Likely the answer is dependent on product and market specific variables but the question is always the same: What are we taking to market and when can we do that? The challenge facing software product managers is to not only decide what the minimum market-viable product (MVP) is but also predict when that MVP can be delivered. You must do both to gain holistic understanding. I am going to share two methods that have served me very well to date, regardless of product or market type, to answer these questions.

First lets define what a Product Manager (Agile Product Owner) actually owns.

In the “Scrum Guide” (Schwaber 2009, 5), Ken Schwaber writes about the product owner:

“The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the team performs. This person maintains the Product Backlog and ensures that it is visible to everyone.”

This definition seems appropriate and adequate until one attempts to share that backlog. If you’ve ever seen a stack ranked backlog, you know all too well how poorly it shows any crucial information about the product vision or roadmap. Below is a snippet of a backlog, stack ranked. (courtesy of

Even though this ranked list might be useful to a Scrum Team who does not need larger vision when selecting user stories, they are likely the only ones.

At CodeScience, it is critical that we share a cogent vision with our clients for the delivery of their products. Ultimately, it’s the strong communicator that wins the day and this holds true in any product development organization. Roman Pichler sums this up well:

“The product owner must be an effective communicator and negotiator. The individual communicates with and aligns different parties, including customers, users, development and engineering, marketing, sales, service, operations, and management. The product owner is the voice of the customer, communicating customer needs and requirements and bridging the gap between “the suits” and “the techies.” Sometimes this means saying no and other times negotiating a compromise.”

Pichler, Roman (2010-03-11). Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series (Cohn)) (Kindle Locations 414-418). Pearson Education. Kindle Edition.

Let’s explore a strategy for both reflecting the product backlog and then calculating the timing of the MVP and subsequent releases. Often, I find a need for multiple visualizations depending on the message being sent and the audience involved. As always, use your judgement to fit your current needs!

The WHAT – Map the User Stories to suss out the MVP and subsequent releases

User Story Maps have been a favorite of mine for quite a while for the following reasons:

  • It’s easy to gain a side-to-side view of the entire featureset
  • They break up into features and activities for better organization
  • Ideally, connecting user personas to the top level hierarchy reflects that the feature solves that users needs
  • It’s easy to split up the vertical story list into releases

Some things story maps don’t do well:

  • Still very manual, although there are some tools that starting to support this visual model.
  • Not a replacement for a product roadmap
  • Does not communicate timing or velocity, the process of backlog estimation is still critical

User Story Maps are most effective when combined with a release plan. That way you can apply context, timing, and go to market strategy all in one cohesive message.

Here are some resources for user story mapping (I make no claims of 3rd party tool performance):

The When – Plan the Releases

Product Roadmaps have always lacked the granular detail that User Story Maps provide, but they are necessary to illustrate when large pieces of functionality are to be delivered. Product Roadmaps are very useful to describe the INTENDED deployment of multiple releases but how can we be sure with good certainty when the NEXT release will be deployed?

First, we have to take our MVP release that was set using our User Story Map and quantify it in user story points by estimating the entire release backlog. By the time the development has experienced 2-3 sprints, there should be sufficient understanding of user story points to accurately perform this exercise. This metric is critical to understand the timing of the release, as the Scrum Team have a velocity measured in story points completed per sprint. It is the application of that velocity to the release points sum that allows us to calculate when the release will be completed. This is commonly referred to a release burndown.

As you can see, our current point is sprint 6, the slope of the burndown is the team’s velocity and we have a future cone of uncertainty based on variability of historical performance. As we move forward in time, the cone of uncertainty will grow smaller as the team progresses towards the go live date and velocity variability naturally tends to reduce.

Once you have the ability to predict one release, you can use that method repeatedly to roadmap your full product releases with excellent certainty!

How do you understand and roadmap your own products? Leave me a comment and start a conversation!

CodeScience is ready to help you bring your ISV product to market in a predictable way leveraging Agile Product Delivery Methodology. Send us a note if you want more information!