| >* while he is actually writing the code Yes. I can take time out to answer email. I can take time out to make estimates as soon as I get an estimate request. Doesn't have to be done in a meeting. >(so not up front) What the fuck is the point of an estimate that's not made in advance??? >not in a group setting but as an individual, so either one person estimating the whole thing or each person giving different estimates The latter. Is that a problem? >(third point same as first, dont want to estimate up front) "Not up front" is not the same thing as "not 4 weeks in advance". I'd do it as soon as the PM needed it to do prioritization. >must incorporate what is often called 'contingency' If you think risk and contingency are the same thing you're an idiot. Risk is story A (e.g. upgrading dependencies) might take 0 hours or might take 4 weeks while story B (updating translations) is going to take 1.5 hours and it's really only going to take 1.5 hours. Contingency is (for example) "let's make sure we have 4 weeks spare before doing story A". >(which is actually what the whole point of measuring velocity is for!) No, velocity is about measuring how fast you're doing stories. >and the final point - he doesn't want to have to commit to it Yeah, because as soon as you start assigning blame for missing feature deadlines the technical debt dial gets ramped up to 11 and predictions become an exercise not in being accurate but in CYA. An estimate about how long something is going to take can be wrong for many reasons that aren't the developers fault - bugs in libraries, technical debt in dependencies, technical debt they weren't aware of and didn't create, team members disappearing, etc. If you want developers to commit to things make sure it's things that they have full control over. |