[cechner]

can we infer that he would like to give his estimates:

* 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?

[Chris2048]

Assume each person giving different estimates for their own work, but not up front - ongoing as code is written.

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).

[cechner]

it is totally reasonable for stakeholders to want to track your progress through a project. If you have a good way of doing that then great, you should use that.

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)

[Chris2048]

> for those estimates to be useful in tracking your progress you have to do it in advance

In advance of what? The only constraint on a useful estimate is that is comes before the task is finished - it needn't be considered as credible at the earliest possible time.

Also, your response doesn't really address my post..

[cechner]

(I went to bed so didn't take long to reply before)

I am clearly not expressing myself well. I am talking about a situation where some stakeholders are expecting a complete picture of roughly how large the project is and would like to be able to track how far your team is through this project on a regular basis.

I am putting scrum forward as a methodology for, in as short a time as possible, measuring the size of that project in a meaningful way by merely breaking it up into as small pieces as possible and attaching numbers to those pieces, intended to measure the size of each piece relative to the other pieces, and then over time discovering how long it takes to complete a piece of a given size.

> Assume each person giving different estimates for their own work, but not up front - ongoing as code is written.

The situation I outlined above (the time when scrum helps out) requires you have a stab at estimating all the constituent parts of the project at the beginning of the project.

> an estimate is an estimate, not a commitment. Committing to an estimate makes it a commitment, not an estimate.

True, but the point of estimating in scrum is to assign relative sizes to the pieces of work, not a number of hours, so this isnt a commitment to finish at a specific time but just to say 'I think this is one of the larger pieces of work in this project.' The person I was replying to sounds like they are on a bad team/project where people use their estimates to blame/finger point, and they are ascribing this to scrum as if the team wouldnt be doing this otherwise.

And in case you suggest that estimating without ascribing a time value is not meaningful, it is used to track how far you are through the project, and over time you refine what the finishing date will be given the emerging velocity.

> 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.

The analysis comes in discovering the velocity. The expectations evolve over time. But knowing your velocity is of limited use if you dont have an estimate of the overall size of the project.

> The difference is choosing to commit to an estimate you have high confidence in

This is the method for getting confidence in your estimate. You have an overall number of 'points' in the project and you learn how many points you can tackle on average every X weeks.

[crdoconnor]

>The person I was replying to sounds like they are on a bad team/project where people use their estimates to blame/finger point, and they are ascribing this to scrum as if the team wouldnt be doing this otherwise.

Every time you try and infer what I'm "really" saying or what "really" happened to me you get it completely wrong. Next time you do that just assume that you're wrong, it'll save us both time.

The blame/finger pointing on my projects wasn't really external (although in a different environment it certainly could have been). Developers themselves felt bad about missing their 'commitments'. The pressure/blame was largely self-inflicted.

Despite feeling bad the predictions were still consistently optimistic and still consistently wrong due to the environment the predictions were made in. It was a bug in the scrum process that led this to happen, but the team and management (and you, apparently) would rather assign blame to anything else other than a bug in their methodology.

>The analysis comes in discovering the velocity.

Velocity isn't a useful metric.

>This is the method for getting confidence in your estimate.

Except it doesn't work. It didn't work for us and it probably doesn't work for anybody else.

Confidence in estimates means treating risk and uncertainty as if it is real rather than sweeping it under the carpet, like it is in scrum.

Confidence means a prediction process that doesn't make developers feel guilty about being wrong, like it does with scrum 'commitments'.

Confidence a prediction process that doesn't intentionally subject developers to groupthink and peer pressure by immediately putting them on the spot like scrum planning pt 2 does.

Confidence means that your estimation process itself should be mutable. Under scrum it is fixed and not subject to review (if you change it you're doing "Scrum-but" and that's a sin, according to scrum trainers).

Most of all, confidence means that you should be able to inject technical debt cleanup stories into the sprint that derisk future changes. Scrum says that's only allowed if the PO says it's allowed. The PO is not responsible for missed commitments though, so it's not their problem.

[crdoconnor]

>* 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.

[Chris2048]

The tone of this post is uncivil, e.g. "If you think ... you're an idiot."

[cechner]

(replying here because I guess we've reached the maximum depth)

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.