I have no comments on this subject, but hell man, I’ve been trying to find you for a long, long time.

No problems, just want to keep in touch.

Colin
Wuerzburg

thanks a lot for your insights on this topic. I agree with most of your points.

Planning poker is a very nice technique to get good estimations, but its by far not the whole story. There is a lot of psychology happening when estimating tasks. So the project manager needs really good soft skills to squeeze out the right estimations and to add the necessary buffer. It is not impossible, but its very hard to do. What I have learned for planning poker is: do not let people estimate task which are held responsible when the project is delayed . Those people tend to estimate always too low. Its not their fault, that just is a natural thing to do.

Longer tasks should really be broken down as fast as possible, because they bring a lot of risk into your planning. Sometimes a good thing to do is time boxing.

If you are not sure how long a task is going to take, because of inexperience or any other issue, time box that task to 8 or 16 hours. After that period you should normally be able to break it down and estimate it much better.

Very interesting point about pushing unloved task and pulling the favourites…
If people try those tricks, the project manger is clearly NOT doing a good job. He should be able to know what people like and don’t like. If the people act like this, they don’t trust their project manager anyway.

Project managers do need to be demanding while I don’t think they need to be inquisitive, because that will not help anybody. They need good communication skills and have to be very honest to their team, because they need the people’s trust, otherwise they will not be able to do their job.

Crunch does exist, and some of that is surely caused because of unskilled project managers, but there are many other reason why people have to crunch.

For a while now i’ve been sticking to 1, 2, 4, 8 and 16 hour estimations with nothing in between. With 16 hours mostly meaning “it won’t be finished today, probably sometime after the same time tomorrow”. There’s also a 0 hour estimation which is for tasks that i can work off in between tasks without sacrificing anything.

Longer tasks that haven’t been broken down or aren’t specified clearly are estimated in weekly increments. Estimations are mostly pure gut feeling mixed with experience and rounding up to the next nearest time.

Btw, in this case 8 hours means a work day, eg 8 “real” hours which are 4-6 “actual programming” hours.

If a task is matched with inexperience in the field i tend to grossly overestimate the time needed. It’s better that way and to positively surprise anyone than working your a– off and not getting close to being done in time.

I think the real art to planning a project is to know when people are using high estimations to push undesired tasks back or off the project completely, and vice versa using low estimations to be able to work on something they’re enthusiastic about. From my experience this happens all the time, more so if people find they have no say in the direction of the project or their line of work so they tend to factor that in by the estimations they give.

Project managers need to be inquisitive and demanding while not pissing people off or forcing them to “just work harder”. Not an easy job. One of the reasons why something like crunch exists, right?