Release Planning: Vision

April 22, 2012

[This is one in a series on Release Planning. The series starts here.]

This is the first of several posts on my suggestions for the details of doing better agile Release Planning.

The first step is Vision. We define the vision, and make sure that all the right people see the same vision and “agree with it.” Or at least start to align with it.

Who: The full team of pigs and the business stakeholders should do this together. The Pigs include: the implementors, the ScrumMaster, and the Product Owner.

The business stakeholders (BSH) are the other key people associated with the team that provide key input about what the product should be. They may be customers or internal managers, or really anyone who will participate enough to provide valuable input. It is mainly the Product Owner’s job to make sure these are the best possible people, given the specific situation. Often the Product Owner must seek help in selecting the BSHs. (Note: Often I mean something different than what your company means by ‘business stakeholder.’ One of the key things I mean are people who will come regularly to the Sprint Planning Meeting and the Sprint Review and provide good and useful feedback.)

In my experience, the BSHs are never perfect representatives of ‘the customers’ of the product. Once the issue is identified and made visible, you might need to change one or two BSHs.

Typically the BSHs represent two main groups: (a) ‘the customers’, meaning usually mostly the external and/or internal end-users, and (b) the firm, usually personified as the widows and orphans who own all the shares of the firm.

What: By vision we mean some relatively short statement of what the product will be, once completed. Why we or the customers will be excited about it. And a few more scoping details.

It establishes the ‘north star’ of our direction. It hints at what business value is.

And it is like an elevator statement. Something short that you could explain in 2 minutes to your bosses’ boss.

I particularly like the following format, which comes from Geoffrey Moore’s book, Crossing the Chasm:
•    For (target customer)
•    Who (statement of the need or opportunity)
•    The (product name) is a (product category)
•    That (key benefit, compelling reason to buy)
•    Unlike (primary competitive alternative)
•    Our product (statement of primary differentiation)

In addition to these nice words, I also strongly recommend you find one or two key numbers to ground the vision. Examples: “We expect to make $3 million in the first year.” “Widget production will go up about 125%.” Whatever metric (or two) makes sense. The metric makes the words more tangible.

Why:
– To clarify where we are going. Yogi Berra: “You have to be very careful if you don’t know where you’re going, because you might not get there.”
– To motivate all parties. This is quite important.
– To set a direction and a rough scope. (“This is about the iPad-1, not the iPhone, nor any other iOS gadgets.”)
– To start to get everyone on one page. My experience is that this is very hard. They tend to be on different pages, it seems.

How: We find this typically takes about 20 minutes, maybe 30. Sometimes less, sometimes more. We find it is useful to do 15 minute time boxes, to check if there is too much aimless or circular talk. To check for those talking too much or too little.

I recommend that the ‘smart guys’ (those who think they already know the vision) talk, and the least informed person (typically, one of the implementers) write the vision. This helps assure that the implementers ‘get it’. Sometimes, sooner or later, the Product Owner, who perhaps is better with words than some of the implementers, must improve the wording.

Remember that perhaps the most important goal is not to have knowledge (in one person’s head) but to spread the knowledge into the heads of all the people.

I also recommend the PO identify one key metric that gives them all a better idea about rough importance. Some are naturally sceptical and some are naturally dreamers. The metric helps them see this is not the greatest thing since sliced bread, and similarly helps them see this is not trivial in importance. It is somewhere in the middle. The metric is a first stab at helping them identify, in a concrete way, what that middle really is.

Ending: Usually the team forgets to identify a key metric. Go back and do that. Then, ask the whole team to give the thumb metric. Tell them: “If the thumb is pointing straight down, this is the worst project you have ever been on. If the thumb is pointing straight up, this is the best project you ever had. Half-way, this is just an average, typical project around here. So, one-two-three, show your thumb metric…”

The Product Owner should lead a discussion of the results. Sometimes this means improving the Vision statement. Or the metric. Sometimes it is just a short discussion.

Roles: The Product Owner is leading the content. The ScrumMaster is leading the facilitation. The SM checks the time boxes, and tries to assure that everyone talks the right amount. The Product Owner is always assessing. Have the right things been said to motivate the group?

Later: The war is not won or lost in the first hour of battle. The Vision is a start. Hopefully a good start. Some projects can start with a great vision and then get bogged down nonetheless. And vice versa.

The Vision is often improved later on, in any case.

***
Prior posts on Release Planning:
http://agileconsortium.blogspot.com/2011/03/scrum-and-release-planning.html
http://agileconsortium.blogspot.com/2011/08/joes-approach-to-release-planning.html
http://agileconsortium.blogspot.com/2011/07/why-release-planning.html
http://agileconsortium.blogspot.com/2010/11/release-planning.html
http://agileconsortium.blogspot.com/2010/09/release-planning-early-warning-system.html
http://agileconsortium.blogspot.com/2011/08/release-planning-with-business.html
http://agileconsortium.blogspot.com/2011/09/release-planning-business-value-points.html
http://agileconsortium.blogspot.com/2011/06/planning-poker-1.html