One of the activities taken in an Agile software development effort is assigning some form of identification to determine the relative size of the story in the product backlog. There are a number of ways that the relative size could be specified. T-Shirt sizes (XL / L / M / S). Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc…). Effort in days or hours.
It doesn’t really matter what metric you pick to assign this relative unit to the story - but there are some guiding principles that should be followed and some understanding of the nature of the people doing the estimates.
- Define a Baseline - Since the points assigned are relative sizes it is vital that everyone can answer the question “relative to what”. It is a trivial task to compare two stories to each other. However, comparing tens or hundreds of stories requires that everything is compared to the same thing. Otherwise the relative comparison will fall short.
- Be consistent - Let’s say “Story Foo” has 5 story points assigned to it because compared to the baseline it is deemed 8 times more difficult than the baseline. When “Story Bar” is being estimated it should also be compared to the baseline. However, it should ALSO be compared to “Story Foo”. Too often “Bar” gets 5 points compared to the baseline even when the team believes it is twice as difficult as “Foo”.
- Timebox the Activity - Let’s face it - people lose focus easily. The estimating activity is one where the team can get into a “bad” rhythm. Instead of really thinking about “Foo” and “Bar” they respond with the same estimate because they appear the same even when there can be significant differences. About a 30 minute timebox is appropriate.
- Don’t Estimate Everything - First of all, don’t estimate epics. You don’t know enough about the epic to be anywhere near right. Secondly, think hard about how much in the future is required to be story-pointed.
- People Translate - Whether they say this out loud or not - people are translating from “duration” to “points” when giving their estimates.
How is all this related to telling lies? I like to think of estimating software development in terms of telling lies. There is an amazing phenomenon that occurs when asking a developer how long an activity will take. For some reason there is magic about answering “2 weeks”. When I was the project manager for a very large pre-agile project I would ask how long something would take. Of course the answer was “2 weeks”. OK, fine… about 6 days later I would ask how things were progressing and of course there were problems that were going to delay the completion of the task. When asked how long to work through the problems and finish the task, the answer… you guessed it… “2 weeks”.
There is ONE AND ONLY ONE accurate answer to the “how long” question. That answer is “I don’t know” - everything else is a lie. I said this in a training class once and was met with “that is a very strong word - it isn’t a lie, it is the best estimate I have at the time”. My question to this person was “Define the word ‘lie’” which she defined as “telling someone something that you know isn’t true”. Need I say more? Telling me “2 weeks” is telling me something that you know isn’t true”.
Bottom line - Story points, estimates, lies… everyone related to the project needs to understand that by the very nature of the activity, the result will not be very accurate. In fact, when the task is supposed to start, the size of the task, and the level of understanding of the story are all factors in how big the lie is. A small, clear task starting now will have a fairly accurate estimate. A large, nebulous task starting in 4 months - well, that’s a whopper. It will probably take 2 weeks.
No comments:
Post a Comment