[alexanderdou]

Perhaps I've just always been extraordinarily lucky, but I've never heard the developers I work with complain about our Pointing and Development cycle (and I'd like to think I do try my best to 1) proactively ask them for feedback and 2) recognize and squelch any of my own reactionary defensiveness that comes from feedback).

One thing I see a lot in the comments is about time estimates and the amount of pressure that that brings and the rarity in which it works.

In my teams we NEVER talk about time of delivery with Engineering. I've always been trained to think of pointing as an estimate of "complexity" (e.g. 1 point is roughly the complexity associated with a copy change).

Then, by getting a track record of historical points completed in a week, we can transform our way from feature => complexity => time.

[t0mbstone]

Complexity only matters if it can be correlated to time.

For example, if you ask someone to transcribe 10,000 pages of text, and you know that they type 60 words per minute, and that there are an average of 300 words per page, then you can estimate that it will take approximately 833 hours to transcribe.

If we followed your method of estimating stories strictly by complexity, however, this is clearly only a one pointer story. After all, there is nothing complex at all about the dull task of rote transcription, and all quantities are known and established.

When people talk about "complexity" in software development, what they are really talking about is how certain they are in their knowledge about all the things they have to touch. The more things they have to touch, and the more things they are unfamiliar with, the more things can unexpectedly go wrong.

Each task should really receive two estimates:

1. How long do you think this will take?

2. How certain are you of this estimate, given all the factors you are aware of?

That would be too much work, though, so people condense this into a single point value and hope for the best.