Now we come to the point of describing Planning Poker.
(This is a continuation of a series on Release Planning that starts here.)
Planning Poker has been described before, so we will be brief. It is described at greater length many other places.
***
Some basic characteristics:
The basic technique
We have about 5 Experts.
We use (solely, mainly) the people in the team who will be building the product. The affects motivation. This affects their knowledge. This will affect their later behavior. 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 assumptions 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 in the Product Backlog, covering about 6 months worth of work. The Experts choose from that set the smallest story. Well, 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). [Someone should check that the story is about the right size. But don't tell anyone, and especially don't let the experts start thinking in units of time (days, hours). Still, if the story is too big or too small, it starts to distort the voting, in my experience.]
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 of 'these things' done during the Spring that we are estimating. Earlier we talked about a minimal DOD.
OK, now the team estimates the relative size of all the other stories in comparison to this reference story. This happens in this way:
A few additional comments:
At the end
It usually takes no more than 1.5 hours to estimate 50 cards well. The first few cards take longer. Then things speed up. On average; sometimes one or two later cards will take some time.
Once all the cards have been estimated (for effort), all the cards should be put on the wall. And then the whole Team should gather around. And see if they can identify one or two 'stupid' cards.
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 be more than one decimal place. This gives:
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? Often they say: Well, it is a good start but we need to make some changes. Which is 99% of the time, the right answer in my opinion.
What ideas do we use to re-order the work? More on that in a post soon.
(This is a continuation of a series on Release Planning that starts here.)
Planning Poker has been described before, so we will be brief. It is described at greater length many other places.
***
Some basic characteristics:
- We find the 5 best experts on effort for this work. (About 5; maybe 3-7.) 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 planning poker cards with the Fibonacci scale.
- The approach is wide-band delphi. 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 about 5 Experts.
We use (solely, mainly) the people in the team who will be building the product. The affects motivation. This affects their knowledge. This will affect their later behavior. 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 assumptions 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 in the Product Backlog, covering about 6 months worth of work. The Experts choose from that set the smallest story. Well, 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). [Someone should check that the story is about the right size. But don't tell anyone, and especially don't let the experts start thinking in units of time (days, hours). Still, if the story is too big or too small, it starts to distort the voting, in my experience.]
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 of 'these things' done during the Spring that we are estimating. Earlier we talked about a minimal DOD.
OK, 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. PO describes story. Experts ask him questions.
- Someone asks "any more questions?" If no....
- Each Expert privately selects a Planning Poker 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...
- If all Experts are within 3 consecutive cards of each other (ex: all have either a 5, 8 or 13), then average the numbers. Example: 5, 5, 5, 8, 13 .... averages to 7. The average is rounded to the nearest integer.
- 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 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).
- If, after X number of rounds, the Experts have not reached some degree of consensus (with 3 cards), then the team should just take the average. Each team can decide how big X should be. My guess is 4.
- 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 stuff.
- 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 the story points for the related stories.
- Sometimes the Experts will want to address certain general issues. The 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. Maybe 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 a 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).
- 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 no more than 1.5 hours to estimate 50 cards well. The first few cards take longer. Then things speed up. On average; sometimes one or two later cards will take some time.
Once all the cards have been estimated (for effort), all the cards should be put on the wall. And then the whole Team should gather around. And see if they can identify one or two 'stupid' cards.
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 be more than one decimal place. This gives:
- the low hanging fruit
- the bang for the buck
- the return on investment
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? Often they say: Well, it is a good start but we need to make some changes. Which is 99% of the time, the right answer in my opinion.
What ideas do we use to re-order the work? More on that in a post soon.
No comments:
Post a Comment