Estimating software can be tricky. Earlier this week, I’d written a tip about using Planning Poker for estimations in an Agile environment. As I was researching this tool, I found Mike Cohn’s name dominating this space as an authority on Agile estimating techniques. I’m used to finding experts on the Internet that can be anywhere in the world. Little did I know, Cohn lives in neighboring Lafayette, Colorado. I was even more surprised when an email popped into my inbox yesterday that said that Cohn would be speaking this week at the Denver Java User Group (JUG) meeting! How lucky for me!
Cohn, Agile coach, trainer and author of several books, including Agile Estimating and Planning, described using “story points” as units of measure. “People are better at relative estimating than absolute estimating,” he explains. Story points allow for relative measurement, rather than using time or size. In this video clip, Cohn compares using story points to the “T-Shirt sizes” method of estimating.
[kml_flashembed movie="http://www.youtube.com/v/BAGain3T-xU" width="425" height="350" wmode="transparent" /]
Cohn warned us against “anchoring.” Anchoring, he explains, is when people hear a number, and even if that number is not relevant, it still seems to influence their estimates. Cohn gave a very interesting example of a team that was asked to estimate a project. A control group, without any outside influence, estimated that they project would take 456 hours . A second group was told that the customer, with no knowledge of the project, thought it should be done in 500 hours but that this should not influence their estimate. The estimate this group came up with was 555 hours. A third group was told the customer thought it should be done in 50 hours. Again, they were told that this should not be used in their process for coming up with estimate. This group came up with an estimate of 99 hours. Even though the groups were told not to be influenced by the customer’s numbers, the experiment implied that their estimates were skewed towards the numbers given by the customers.
Planning Poker is a technique where each team member use cards with a range of numbers to estimate effort. Typically the numbers do not progress incrementally, but are more spread apart, the higher they get. The Fibonacci series (0, 1, 2, 3, 5, 8, 13, 21, …) can be used for this. The reasoning behind this is that the larger the numbers get, the more uncertainty there is. Cohn gave us each a deck of cards and had us do an exercise in which we were given several tasks and then work in teams to estimate those tasks using the cards. If we didn’t agree on the first pass, we would explain our reasoning and vote again. In all cases, we were able to reach consensus quickly. Cohn even has made a free planning poker tool available for distributed agile teams.
Advice from Cohn
I caught Cohn at the end of his presentation for a few minutes and asked him if he had some short words of wisdom that might help teams that are working on software estimates. He shares this advice for times when the team feels the estimate is somewhere between two numbers that are being used:
[kml_flashembed movie="http://www.youtube.com/v/AkbcuiZbh94" width="425" height="350" wmode="transparent" /]
Cohn gave us each a couple of decks of his Planning Poker cards to go home and play with. His decks include four sets of ?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 and the infinity symbol. I may not be ready for Vegas, but I am so ready to estimate software. Bring it on!