2

As a developer, task and story pointing seems somewhat too fine-grained. The cards we use for pointing are: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, and infinity. Of these, there are really only a few significant verbal equivalent categories. 'already done', 'easy', 'moderately difficult', 'hard', and 'that involves a system rewrite'.

Sometimes a task is drastically misjudged, but usually the difficulty of the task is approximately in-line with its estimation. This being the case, does it really matter whether the task is a 0.5 or a 3? The many factors that influence a task's difficulty are rarely completely grasped within the planning meeting. One result of this is that a particular task does not seem to be matched up with a particular points value over time.

If the pointed difficulty of its constituent tasks floats up and down over time, do any resulting metrics add significant value?

flag

3 Answers

1

Well in your particular case, I would say that your pointing might not be scaled properly. In that case, you could get rid of some of your cards. Get rid of the 3 and 13 if you feel it is a good idea.

However, then you lose the ability to accurately point. It's like having a quarter in your pocket. In the pocket it doesn't seem to have much value, however in a change jar it can add up to a hefty amount. The theory also being that the smaller an item is, the easier it is to guesstimate how much work it is going to be hence the Fibonacci sequence.

If you find that a particular task is difficult to accurately point, then consider breaking the task apart into what can be pointed accurately and the rest as another task that can be pointed independently - including time to research and understand the task completely.

link|flag
I like the idea of dropping cards if they don't work out. One of the problems with working on very intricate projects with thousands of unit tests is that the actual difficulty of the task is hard to determine until undertaken. – D. Cooksey Dec 17 at 23:05
1 
 That sounds like a problem with your unit testing strategy, not Agile or pointing ;-). If Single Responsibility is done properly without a big tangle of dependencies and poorly written tests, then you shouldn't have much to worry about. If you are adding a new feature, only a few tests should probably fail. Changing a feature should only cause those feature's tests to break, etc. – John Merriwether Dec 17 at 23:08
1

I encourage teams to treat every story as if it had one point, and likewise every task as if it had one point. Over time, the usual estimating errors will average out, so this method is just as "accurate" as anything else, but without the time wasted in creating estimates.

If you're estimating points in order to estimate team load and story due dates, it's much more valuable to track "flight time" instead. Mark each story (or task) as it is created, and then mark again when completed. The difference between the start and end dates gives a flight time, which offers a much more meaningful measure of capability to those in the business who need to know such things.

link|flag
1

The cost of a story depends on the complexity of the story and the amount of technical debt in the areas of the design we need to change or extend to deliver the story. Working in areas with high technical debt causes the cost of repaying that debt to dominate the cost of the story. I interpret the accuracy of either story or task estimates as a sign of the simplicity of the design: the more misleading the estimates, the more we need to improve the design. See http://bit.ly/511xps for more details/

link|flag

Your Answer

Get an OpenID
or

Not the answer you're looking for? Browse other questions tagged or ask your own question.