* while he is actually writing the code (so not up front)
* not in a group setting but as an individual, so either one person estimating the whole thing or each person giving different estimates
* (third point same as first, dont want to estimate up front)
* must incorporate what is often called 'contingency' (which is actually what the whole point of measuring velocity is for!)
* and the final point - he doesn't want to have to commit to it
how can you _not_ read this into it?
How is that the same as not being "required to give any estimate at all"?
> he doesn't want to have to commit to it
why not? an estimate is an estimate, not a commitment. Committing to an estimate makes it a commitment, not an estimate.
I might expect a dice roll to be 3.5, I'm not committing to the next roll being 3.5 - analysis should inform policy, in this case expectations informing stated commitments, but the two are not the same.
Furthermore, this bullet point actually takes the quote out of context - He specifically doesn't want to commit to the estimate produced under the previous conditions, not that he won't commit to any estimate. The difference is choosing to commit to an estimate you have high confidence in, versus any estimate given automatically being a commitment (where estimates may be required on demand).
Scrum people believe that scrum is the simplest way of measuring that. But at some stage you have to estimate the constituent parts of the project in order to get an idea of its size, and for those estimates to be useful in tracking your progress you have to do it in advance.
I repeat however, if you dont need to do this then thats fantastic! Many of us do however, and some of us choose to use scrum to do that, and some of us have had a great deal of success with that.
(edit: I worry that this sounds condescending. I am just trying to keep the tone friendly)
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.
I am here assuming that you want to be able to try to measure your progress through the project (as I mentioned, this is the only thing scrum does for you). Both of you seem to be suggesting (dont insult me if Im wrong) that this isnt the highest priority.
And no, velocity is to make the whole system self-adjusting. If I put 3 points against a story we use velocity to discover over time how long those 3 points take. This self-adjusts to incorporate for contingency.
If you disagree with this then we simply disagree on what velocity is about. It doesnt make us enemies, we dont need to get super pissed off at each other.
