Scrum's planning poker is another approach to the same problem as XP's planning game, how to estimate the cost of user stories in advance. Again the discussion does not depend on the choice of measurement unit, such as developer-day or story point.
The two ideas of planning poker are to:
- Rely on the collective judgement of a panel of estimators, iterating until they agree.
- Avoid pointless haggling over small differences by forcing the values to be taken from a sequence of clearly distinct values.
A sequence of values satisfying the last criterion is the Fibonacci sequence: 0, 1 (and 1 again), 2, 3, 5, 8, 13, 21, 35, …
I hear you: that is not the Fibonacci sequence! Indeed. The last number cited should be 34. Congratulations on your mathematical sophistication! But one agile consultant has had the brilliant business idea of producing and selling a deck of planning-poker playing cards. Trouble is, copyrighting the Fibonacci sequence is kind of hard, since it has been around since something like 1202 in Italy (and a couple of millennia earlier in India). Not to worry: just change one of the values. Not exactly as I did above — I am far too scared of a copyright infringement suit! — but you get the idea.
If estimates are done in person -days, the second value is sometimes replaced by 0.5 since some simple user stories may be implementable in less than a day. What matters is that the values differ sufficiently to avoid the estimators getting into a fight over insignificant differences, such as whether a particular task will take 11 or 12 days; the aim is rough-cut estimation rather than exactness.
Some variants of planning poker rely on an even smaller set of choices, in particular "T-shirt sizing" which offers five values from X-small to X-large. Most variants also include the value "?" for the benefit of an estimator who feels there is not enough information yet to propose an answer.
The panel of estimators is the development team, including the product owner and other customer representatives as appropriate. It applies a form of the "Delphi" expert -consensus decision method, which originated with the US military and has been in use for decades. It is also influenced by the more recent concept of "wisdom of the crowds", according to which a group can collectively reach a better decision than even the best individual experts in its midst. The goal is to arrive at a consensus, but to avoid reaching it through the intimidation of outlying thinkers by the initial majority.
The process for estimating the cost of a functionality element involves the following steps:
1) Someone, typically the product owner, describes the feature.
2) The participants discuss it and ask questions as needed.
3) Every participant privately picks an estimate, from the preset sequence of values.
4) The choices are revealed. This where the process gets its name: as in a game of cards, you show your hand only when asked.
5) If the values agree, the process stops for this item and the common estimate is retained. (This is where it is important to have widely separated values in the sequence.)
6) If the values are not identical, a discussion takes place, with each member arguing for his or her choice. Then the process is repeated from step 3, on the basis of infor-mation gained in the discussion.
7) If the process does not converge quickly enough to a common value, the participants will have to abandon it and discuss what else to do, such as getting more information and postponing the estimation to a later date.
without, however, citing actual studies. My own experience, also individual and also not backed by studies, is less thrilling. The problem I have seen is the power of majority pressure. If you are truly an expert and you come up with an estimate that is widely different from those of the rest of the group, it is difficult to argue for long without appearing arrogant. To preserve group harmony you are naturally led to give up — at least if you know you are not yourself going to get the task of implementing the item. This outcome can be damaging to the project, especially when the expert knows how hard some task really is but is unable to convince the rest of the group, which has not performed such work before and thinks it will be a breeze.
Taken from : Agile!: The Good, the Hype and the Ugly
No comments:
Post a Comment