Release Planning: Effort (2)

May 27, 2012

[This is a continuation of a series on Release Planning that starts here.]

Now we come to the point of describing Planning Poker.

This has been done before; we will be brief. It is described at greater length many other places.

***
Some basic characteristics:
* We find the 5 best experts (or 4-7 people) on effort for this work. In almost all cases, this means the team of pigs.
* Usually the Business Stakeholders (as I call them) will not stay around for this work. This is ok. Not ideal, but ok. We will bring them back in later.
* We use the estimation cards with the Fibonacci scale.
* The approach is Wide-Band Delphi estimation. Delphi means we use the best experts we can find. Wide-band means that we allow the experts to talk and learn from each other. This bears strong resemblance to the knowledge creation ideas from Takeuchi and Nonaka.

The basic technique

We have 4-7 experts. These are typically the people who will be building the product. We try hard to get all of them, so that none of them feels left out.

The Product Owner is typically not one of the voters, but he/she is there. The PO has to make sure that the team is understanding each story correctly. Typically the PO is a business person and in any case is representing the Firm and the Customers. So, when those kinds of questions come up, he must be there to give them the best possible knowledge or assumption to work with.

The ScrumMaster (SM) is there to facilitate the meeting or the work. Ex: To try to get the quiet ones to talk more and the talkative ones to talk less.

In this discussion, we will assume all the PBIs (Product Backlog Items) are in the User Story format, so we will call them stories.

The Experts must now choose the reference story.

Imagine that the team has 50 stories that cover about 6 months worth of work. The Experts choose from that set the smallest story (smallest in effort). Except that it should not be too small. Ideally it is about 1 ideal person day (after adding together all the ideal hours from all the required skill sets or people in the team).

The reference story is arbitrarily given a 1. Meaning, it has an effort value of 1 Story Point.

Note: For those who are just reading this post, an earlier post talked about how the Team must have a strong DOD (definition of done). The DOD should make clear what things are being done in the Sprint to get the story ‘done, done’ as we often say. So, it is the effort on these things that we are estimating. Earlier we talked about a minimal DOD.

Now the team estimates the relative size of all the other stories in comparison to this reference story. This happens in this way:

Select the (next) highest value story.
Discuss it briefly to assure everyone understands it the same way. The PO describes the story. The Experts ask him questions.
Someone asks “any more questions?” If no….
Each Expert privately selects a Fibonacci card that best represents his feeling of how much bigger the new story is in comparison to the reference story. For example, if 7 times bigger, the choice is between a 5 card or an 8 card. Likely, the 8 card will be chosen…
They all reveal the cards at one time (no one influences the others’ votes).
If all Experts are within 3 Fibonacci cards of each other (eg, all have either a 5, 8 or 13), then average the numbers. Example: 5, 5, 5, 8, 13 …. averages to 7.
If the Experts’ votes are more dispersed (ex: 3, 5, 8, 13, 20), then the two extremes talk (mostly). In this example, the person with the 3 and the person with the 20 both talk about their assumptions, etc. If the assumptions are business-related, then the PO can decide which assumption is (more) correct.
With the new information, each Expert votes privately again.
Voting and discussing can go on a couple of rounds. Almost always, the final answer for a card is the average after the Experts get within 3 consecutive cards of each other (Ex: votes are 2, 3, or 5).
Once the number is decided, it is written on the card (story) in such a way that everyone knows that it represents the story points (color and placement on the card usually make that clear).

A few additional comments:

The discussion is actually the most valuable thing. The numbers drive a better conversation about the more important issues.
Sometimes important assumptions are identified. In that case, the assumption should probably be recorded (eg, on the back of the card). Later, if we discover that the assumption is incorrect, we can refactor (re-vote) the story points for the related story or stories.
Sometimes the Experts will want to address certain general issues. Issues might be architecture or design related. This is where the SM has to use good judgment. Typically let them discuss for ‘a while’ but not too long. Perhaps make one or two drawings. Make and document a few assumptions, and then get back to Planning Poker. Sometimes one or two people on the team want to discuss these issues too long. In this case, the SM must use good judgement and get the Experts back to planning poker.
You will hear of people suggesting that the Experts must agree on 1 Fibonacci number (eg, 8) for a given story. This is _not_ recommended. First, it gives a strong incentive for people to too quickly start to shade their numbers, rather than vote what they really think. They find that George, the senior guy, is stubborn, and to avoid conflict and to keep things going, they decide, almost subconsciously, to start voting as closely to what George says as fast as they can.
The research shows that the average is more likely to be the correct estimate. And it actually takes less time to reach that number (if everyone is voting honestly).
If they do not converge (wth 3 consecutive Fibonacci numbers) fairly quickly (3 rounds?), then take the average anyway. But mark that card as ‘special’, and consider what additional information will help the team to converge. And probably later, get that information.

Usually one or two new stories are identified while we are doing planning poker. This is normal. Occasionally it turns out to be the most important story.

At the end

It usually takes about 1-1.5 hours to estimate 50 cards well. Do not take much longer (it won’t be a good investment).

Once all the stories have been estimated (for effort), all the stories should be put on the wall. And then the whole Team should gather around and see if they can identify one or two cards that need re-voting (now that we are smarter).

It is very common that 2 or 3 stories that were estimated early on will need to be re-estimated, in the team’s opinion. This is fine, good even, and normal. They now, as a team, are much smarter than when they started planning poker.

Cost-benefit analysis

Now one or two people in the team calculate the R ratio for each story. BVP divided by SP. For each story. The R should not have more than one decimal place. This gives:

the return on investment
the bang for the buck
the cost-benefit analysis
the low hanging fruit

We next suggest that the PO organize the story cards based on the R number. Highest R first. Lowest R last.

We ask them: What do you think? Is this the right way to do the work? Virtually always they say: Well, it is a good start but we need to make some changes. And this is the right answer in my opinion.

What ideas do we use to re-order the work? More on that in a post soon.