Planning and Metrics

Your Product Vision in Scrum


Posted by Ilan Goldstein on September 3, 2013

“We need help! This whole Scrum thing doesn’t seem to be working anymore! Our stakeholders are putting immense pressure on our Product Owner to keep changing direction mid-Sprint. Even though our ScrumMaster is the size of a prop he is finding it hard to keep the pressure off our poor PO who is likely to combust any day now!!”

As a Certified Scrum Trainer and Agile coach I hear this reasonably often and the first question that I always ask these teams is: “No problem, can I please take a quick look at your Product Vision? The response is typically, “Sure thing, let us pull up the Product Backlog for you to check out.” My response: “Umm, I didn’t actually ask for your Product Backlog, I was after the Vision…” Their response: “Yeah, check out our PBIs, they’re actually well refined (something we’re doing pretty well) and you’ll see the direction that we’re supposedly heading.” Not the answer that I was hoping for but certainly not atypical and likely the root cause of their current problem.

With the eagerness to just jump in and start building ‘stuff’, new Scrum teams often put all their attention on the ‘what’ (the Product Backlog) and the ‘how’ (the Sprint Backlog). This is like putting the cart before the horse, as before we even consider the ‘what’ or the ‘how’, we need to seriously consider the ‘why’. The ‘why’ is not found in the Product Backlog or the Sprint Backlog but rather in a separate axiomatic artifact known as the Product Vision.

A good Product Vision should inherently contain the following key attributes:

  • Clear and understandable at all levels including at the senior stakeholder level as well as the development team level
  • Specific enough to ensure the clarity of the product essence and key goals, yet general enough to allow for creative implementation decisions to evolve
  • Visible and easy to reference to ensure that ongoing product decisions are always aligned with it.

Below is one of my favourite formats, affectionately known as the ‘one-pager’ inspired by variations that I’ve seen particularly from Jim Highsmith and Pete Deemer (oh and Toyota).

Elevator Pitch For…Who…That…Unlike
Target Customers
  1. People who work in…
  2. Those who need a
Major Capabalities
  1. share content with…
  2. Personalise ads on…
Benefits / Differentiation
  1. More accurate than…
  2. Better integration with…
Metrics / Goals
  1. X users per month…
  2. Y click-through-rate per month
Major Milestones
  1. v1.0 alpha
  2. v2.0 beta
Performance Attributes
  1. X requests per second
  2. Y concurrent users
Trade-off Options Scope: Flexible
Resources: Fixed
Schedule: firm

You’ll notice that this one-pager is not overly detailed yet provides enough key information to truly understand the ‘why’ as well as some of the very high-level ‘whats’. With this Vision now established, we can get started developing our higher level User Story epics (and Sprint-ready Stories) that will form the basis of our Product Backlog and just like any organism, we will now have the identifiable DNA ensuring that key directional decisions are more predictable, removing the perceived need for short-term, knee-jerk changes of mind that we so often see.

 

If you liked this article, you can:
Subscribe to this RSS feed!

Find out more about setting a product vision by taking one of our CSPO training courses.

3 responses to “Your Product Vision in Scrum”

  1. Eugene says:

    Definitely a good concept. I was wondering if you’ve found this to work with non-product features/bugs. I work in ecommerce and we have some clear “products” that map to projects. We also have different websites with different customers. how do you build a vision for something as broad as a website? is there a checkout vision, a search vision, etc? That’s how I’ve tried to look at it, but was curious.

    • Ilan says:

      Hi Eugene – you can certainly have visions that apply at a product/’website’ level but by all means, feel free to apply ‘sub-visions’ to product areas that are worked on by multiple/different teams. I’ve found this to be effective providing of course that the sub-visions align with the broader vision.

  2. Brad Stokes says:

    I quite liked this. Another approach, I plan to try with the team is the Product Vision Board pitched Roman Pichler (http://www.romanpichler.com/tools/vision-board/). I like the simplicity of the approach. Should be interesting

Leave a Reply

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

SOME OF OUR GREAT CLIENTS

testimonials

Sign up to receive our eNewsletter

[brb_collection id="13746"]