This is the first of several posts on my suggestions for the details of doing better Release Planning.
See here for a list of posts about 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 BSH.
In my experience, the BSH are never perfect representatives of 'the customers' of the product. But sometimes the level of imperfection is quite impressive. Sometimes, once the issue is identified and made visible, it can be corrected.
Typically the BSH 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. What it will be, 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.
We particularly like this 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, we 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 want to be on different pages, it seems.
How: We find this typically takes about 1 hour. Sometimes less, sometimes more. We find it is useful to do 15 minute timeboxes, to check if there is too much aimless or circular talk. To check for those talking too much, and those talking too little.
We recommend that the 'smart guys' (those who think they already know the vision) talk, and the dumb people (typically, 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 right people.
Ending: Usually the team forgets to identify a key metric. Go back and do that. Then, ask the whole team to get 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 ever. Half-way, this is just an average, typical project around here. So, one-two-three, show your thumb metric..."
Then 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 we said the right things so that the group is motivated?
Later: The war is not won or lost in the first hour of battle. The Vision is a start. Hopefully a good start. But some projects can start with a great vision and then get bogged down nonetheless. Some projects start with a clearer vision, some with a less clear one.
The Vision is typically improved later on, in any case.
***
Your comments please...
See here for a list of posts about 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 BSH.
In my experience, the BSH are never perfect representatives of 'the customers' of the product. But sometimes the level of imperfection is quite impressive. Sometimes, once the issue is identified and made visible, it can be corrected.
Typically the BSH 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. What it will be, 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.
We particularly like this 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, we 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 want to be on different pages, it seems.
How: We find this typically takes about 1 hour. Sometimes less, sometimes more. We find it is useful to do 15 minute timeboxes, to check if there is too much aimless or circular talk. To check for those talking too much, and those talking too little.
We recommend that the 'smart guys' (those who think they already know the vision) talk, and the dumb people (typically, 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 right people.
Ending: Usually the team forgets to identify a key metric. Go back and do that. Then, ask the whole team to get 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 ever. Half-way, this is just an average, typical project around here. So, one-two-three, show your thumb metric..."
Then 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 we said the right things so that the group is motivated?
Later: The war is not won or lost in the first hour of battle. The Vision is a start. Hopefully a good start. But some projects can start with a great vision and then get bogged down nonetheless. Some projects start with a clearer vision, some with a less clear one.
The Vision is typically improved later on, in any case.
***
Your comments please...
No comments:
Post a Comment