Planning Poker – 1

At Agile-Carolinas, Laurie Williams gave a great presentation last night on how she does Planning Poker. (Suggestion: Google her. She is a professor at NC State, but that is just the start. She is very good.)

Some of the discussion made me realize that there are many issues out there.

So, here is how I recommend doing it. This is overly simplified. Later I will discuss some small differences between what I recommend and what Laurie recommends.

The Basics

Assume for now we are in Release Planning (before starting Sprints).
Assume the user stories have been created. Some are epics.
Assume Business Value has been addressed (somehow).
Assume the stories are on cards (or Post-It notes).
Assume round 50 cards or stories to be estimated.
Assume our domain is software development (not an essential assumption).

Gather the team of pigs, including the PO and SM. Assume the team size is seven.
Assume the PO does not know how to do ‘real work’ (i.e., implement a story).

The team selects the smallest story from the set of user stories.
If the story is not ‘silly small’ (less than four ideal hours of work) and not ‘too big’ (umm, I won’t define that here), then this story becomes ‘the reference story.’

Give the team Planning Poker cards with the (modified?) Fibonacci numbers. One set per person. (0, 1/2, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144)

They pick the first story to estimate — this should be the story with the most Business Value (perhaps they have used Priority Poker to estimate BV).

The whole team discusses, asks questions, etc.
The SM looks for ‘enough discussion’ — roughly equally from all.
If the team has enough info to estimate it, then each implementer chooses the Planning Poker card (number) that represents the relative size-complexity (the effort) of this story versus the reference story. How many times bigger is the new story compared to the reference story?

Each person is thinking of the full effort on both stories from all the skill sets, not just the effort for ‘my own’ skill set (e.g., if he is a tester).

Each person is thinking about the ‘Definition of Done’ for the team, and the effort to complete the story in accord with that DOD inside the Sprint.

The PP card is selected privately — meaning people do not influence each other. We want each person’s independent opinion.

The SM waits until everyone has selected a PP card/number, and then says something like “1-2-3, show” and everyone reveals his or her number at the same time.

The highest and the lowest numbers talk. Usually each of those two people explains the assumptions they used to select that number. Typically, if they were business assumptions, they all look to the PO to ‘answer’ — which assumption is more correct? If they were technology assumptions, they agree on which assumption is correct or they choose an assumption (perhaps a compromise of the two opinions).

Typically the team votes again with the PP cards. Sometimes they could have three rounds.

If the result is that the team selects PP cards within three consecutive cards (e.g., some 3’s, some 5’s, some 8’s), then the team adds up all the cards, and divides by the number of voters to arrive at an integer (no decimal places) representing the average opinion. Note that typically the final number will not be a Fibonacci number (e.g., a six, not an eight or five).

The studies on and methods around wide-band delphi estimation propose a fancier calculation (which I have forgotten), but averaging seems to be accurate enough and fast enough, so we do that.

The idea is that they have discussed and agreed on the story enough (feature and basic implementation). They do not have to fully agree on the relative size (effort).

So, you see that the team reaches a degree of consensus (i.e., everyone in a three Fibonacci number range), but complete consensus is not forced, or, we might say, differences of opinion are respected. So, we do not require that the team reach consensus down to all voting one Fibonacci number (the same PP card).

We are kind of fuzzy about whether we mean size, complexity or effort. My answer is ‘yes,’ but if you want to say that ‘effort’ is the answer, I am OK with that. Ultimately, it is the total amount of effort (not duration) in relative terms.

In practice, it takes some time for the first few stories to be estimated — maybe 3 to 5 minutes each — but as the team moves along, many of the basic assumptions have been decided and things speed up, sometimes perhaps too much. We want discussion and learning.

Now, two important feedback loops.

1. Product Owner: We do not want a stupid person (meaning: a person who has no clue about the ‘real work’ of implementation) anchoring the team on an estimate. So, we typically recommend that the PO not vote. But, technology projects are all about cost-benefit trade-offs. So, what we usually recommend is that, after a story has been estimated (or maybe after all the stories have been estimated), the PO can say ‘well, on this story — I don’t want to spend that much on that (little) feature; what can we do?’ The team with the PO might modify the feature (the story card) or the nature of the implementation so that the cost-benefit ratio is more reasonable, perhaps by breaking down the feature.
2. At the end, after the team has completed Planning Poker, the team should look back at all the numbers on all the stories. By now, the team has learned a lot. Do any of the story points on any of the cards now look ‘stupid’? (That’s the technical phrase.) If so, the team can refactor those story points.

_____________________________________
Enough today. More later.

One thing I must emphasize: The value of Planning Poker is in the discussion-learning (80%) and only slightly in the final story points themselves (maybe 20%). The numbers drive a better discussion.

« « Scrum & Control || CSM Course + Workshop: Why? » »