Feb. 7, 2013 at 3:12pm
aonwagileproductscrum
Product and Project Visioning with the Product Vision Board

The Product Vision Board is the highest-level document before the execution begins where it’s broken into the stories through grooming stories. This could be set up as a 1-hour product overview meeting with the team. It can be expensive, but it’s an exercise to help create alignment. It’s a kickoff exercise for the product to get everyone in the mindset that we’re working on the same thing, and create the vision and create the buy-in.

Can alternatively start with the mission, and think about the team is going to need to use. There needs to be alignment. 

Product owner will come up with a first pass of this Product Vision board. Then take it to the stakeholders. Then the product owner will take it to the development team to flesh it out even more. Constraints are added and fleshed out, and constraints often come up in implementation.

The idea for the Product Vision Board from Roman Pichler, who is a product own blogger at www.romanpichler.com/blog/ More info on “Working with the Product Vision Board” is here:

www.romanpichler.com/blog/agile-product-innovation/working-with-the-agile-product-vision-board/

Pichler blogs from the product perspective with pragmatic information on analytics and business model on a consistent basis.

This is to help create alignment on your teams. Easy to work in a box, and go work on it without caring about what else is going. This will help you transition from Conceptualization to Product Team and implementing with Scrum.

Product Vision Board has four vertical columns (Users, Needs, Features, Values) with a header portion at the top for Mission Statement. Constraints are listed at the bottom of each column. Specific, actionable and time-based goals. Say what they’re going to do and when they’ll do it, and like a Mission Statement for what going to deliver and why.

Mission Statement: Pizza shop that wants to create a Windows app.

First Column is the User. You can either create a user persona, which is identified with a specific person. But you can get too specific with user persona, and he uses “User Categories” instead. Like a call-center representative. Then list the constraints for that user in that column, like a call center rep won’t have high-performance machines.

Second Column lists the needs of the users in order for them to be happy and solve their issues. If the user’s computer is constrained, then the developed application needs to be lightweight. Let the team write on post-it notes, and then let the team put it on the wall. Gets users to get more buy-in, ownership and autonomy.

Third Column is the Top Five features. Feature constraints helps to identify things you haven’t thought about.

Fourth Column is Values.

Let’s do an example. Background: We’re a bleeding-edge pizza business. In college town with lots of smart phone users. Build an app where you order and deliver a pizza without talking to anyone.

Users

* [Add all of the users in the value stream]

* College students

* Pizza makers

* Delivery employees

* Business owner

User Constraints

* Need to own a smart phone

Needs

* Pay for my pizza

* Get my pizza

* Chose pizza

* Order in bulk

* Metrics - Think about how you’re going to measure what you’re doing so that you can get alignment. Book: “Liftoff: Launching Agile teams” talks more about that.

Constraints

* PCI or other compliance

* Within store hours

Features Top 5

* Easiest to define the Features

* Order Pizza

* Enter address

* Enter phone number

* Display pizza queue to the

Values

* [Hardest to define]

* For example, “Simple app” is too vague. Needs to be more measurable and definable.

How to create the “Why?” criteria

* Create alignment with the team. Sometimes a presentation, but like for it to be a collaborative exercise.

* Provide Reference - Post it somewhere where it is highly-visible so that people know what they’re working on.

* Opportunity for thinking through your project - Helps to create the ability to think through what you’re delivering.

* Crossing the Boundary from Planning to Execution Phase — Getting ideas to specificity. “Make it faster” or “Build a simple application” is not specific-enough

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.