What the Scrum Guide doesn't say about Beginning an Agile Project

Dear readers, first I would like to apologize because my English writing is not really good. I am not an English native, however I am trying my best to improve my skills. I hope you understand that.

Before starting an agile project it is usually necessary to perform some dynamics with the Scrum Team to facilitate the composition of product backlog.

These dynamics are called INCEPTION meetings. In meetings like that is where the product scope statement is developed.

Techniques such as Product Vision, Impact Mapping and Stories Mapping (Story Mapping) are initially applied to delimit the boundaries of the scope to the product and direct the focus of the work, which later user stories will be used to start the composition of product backlog.

Creating a Clear Product Vision

Product vision is quite important to the success of the product. It seems a simple statement, right? But think about how much impact it can really have in the project.

A product vision gives us the direction and focus we need to deliver something that will ultimately solve the problems of a customer segment and deliver value to the business.

If it is well-crafted and well-communicated, product vision should permeate everything you do, from business models and product roadmaps to the stories in your backlog and how you execute them.

Chris Spagnuolo suggests a simple test to verify about product vision: Take a minute and scribble down the vision statement for the product you’re currently work on. Then another test: Have the co-workers who sit near you do the same without discussing it. Compare notes. Do your notes match? Are some notes still blank? Are any of the notes the same? Do the same test across your organization. 

Test number two. When you finally find your product’s vision statement on the company website or wiki, how does it read to you? Is it delusional? Cloudy? Confusing? Dismissive? Heady? Wordy? Lengthy? Boring? Uninspiring? Generic? Maybe a little of all of those.

If you feel bad, don’t worry because it is normal. Some of the best organizations in the world have difficulty using words to define what it is they do, who it is they serve, and what success looks like to them. But you don’t have to wallow in the words of your vision statement much longer. There are many simple tools that can help you clearly define the product and use it to drive the product’s business model, the product roadmaps, the product-market fit experiments, and the backlogs for development team.

Defining an Initial Product Vision

When most organizations develop their vision statements, they default to some standard template. One of the more popular templates comes from Geoffrey Moore.

Another simple Product Vision Board was defined by Roman Pichler. It’s a visual tool  quite similar to the project model canvas.

Steps to Create a Product Vision

First, we have to craft a vision statement. Some simple advice on what to write in this box:
Say a lot in just a few words. Pick your words wisely. Don’t be generic. Describe a long-term vision but don’t be overly restrictive. Clear, concise. Calls people to action. Oh, and if you took the two tests above with your co-workers, they’d all remember it…or at least a pretty close flavor of it.

For developing a vision statement you may use a technique called Elevator Pitch.

A good elevator pitch tells people what your product is, who it’s for, and why it’s special in about the time it takes to take a ride in an elevator.

Creating a good one can be harder than you think. But once you get it, it feels great. You can quickly distill a big abstract concept (which is how most projects start) into something tight, real, and concrete.

The first time when I used it was to develop a application called Global Applications Map:

For [IT department at Gerdau]
Who [needs to manage functional and technical information of IT applications]
the [Global Applications Map]
is a [information system based in web architecture, operated in English language, with features for easy exporting data]
that [which provides the possibility of performing predefined queries, and data export to external manipulation]
unlike [the others current Applications Map]
our product [offers the possibility of viewing across any platforms and anywhere a consolidated view of all applications of Gerdau.]

Other option would be a technique called Product Box.

Thinking hard about the product from the customer’s point of view is always a great idea. Not only does building a product box get you in the head of your customer, it’s a great team-building exercise, as you are formally given permission to draw and color at work.

For doing so, it’s not necessary to come up with anything elaborate or complex. Just ask yourself:
What are the top three reasons people are going to buy this product?

And if there was one slogan that captured the spirit of this thing, what would it be?

After you’ve wordsmithed your awesome, clear, thoughtful, inspiring vision statement (and if you have, share it here, I’d love to read them), write it in the box, pat yourself on the back, high-five your teammates, and move forward one space.

The next four boxes should be easier. Mostly because they are all hypotheses, or guesses at what you think the right answer is:

Target Group: It is all about our customer hypothesis. Who do we believe we are trying to serve? Typically, for a new product or even existing products, we’re looking at the early vangelists. We’re looking for customers who clearly identify with our vision.

Needs: In this one we address our problem hypothesis. What do we think the problems of our customers are? Again, don’t fit the problem to your solution. Empathize with your customers and truly try to understand what their problem is. Not what you want it to be. When you think you have a good problem hypothesis, write it in the box in clear, simple terms, pat yourself on the back, high-five your teammates, and move forward one space.

Product: This one is your solution hypothesis. Based on the customers you described, and the problem you identified, what is the minimal thing you can do/build to solve that problem and make them smile? Again, this isn’t rocket science. It’s a guess.  First guess. It doesn’t have to be right. It just has to be something you can build, test, and see if your customers approve.

Value: This one vexes me a bit. So first timers, leave it blank. The world will not end if you do not define the value to your business right now. Why? Just because so far, the other boxes have been guesses. Hypotheses need to be tested, validated.

Look a the sample below:




I hope you enjoy my post.

Andre de Godoy Nunes

Comments

Popular posts from this blog

Reverse Income Statement in Discovery-Driven Planning

The Importance of Planning in Agile Project Management

How to Begin Your Journey into Agile Practices