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
Post a Comment