[hinkley]

> Engineers felt comfortable taking stories in areas they knew nothing about.

and it was understood and expected that this meant the estimate would go up

Today we have 'bidding', which if that sounds like something a three year old does to their parents, you'd be right, and it's the same thing. You just ask someone else until you get the answer you want to hear (instead of the one you need to hear).

[Supermancho]

> you'd be right, and it's the same thing.

It's not the same thing. It's not "bidding", even if it's called that because the lowest or highest or middling bid doesn't necessarily get the work. I know, I know, it sounds like another "you're doing Agile wrong", but Agile already fucked it up by saying "bidding", so we get these wild stories of how companies have their laziest incompetents in charge of trying to make improvements to process.

> You just ask someone else until you get the answer you want to hear (instead of the one you need to hear).

Otherwise you will only have the most jr or senior people working on everything. The system of bidding just doesn't work, which is why it's not bidding in a practical sense.

You ask why people put down their estimates by describing what they know about the work. This is an opportunity to transfer some cursory knowledge and reinforce pain points. At a very progressive "Agile" company (we would invite speakers and A/B tested various practices across teams), I notoriously inflated/deflated all estimates by bringing up edge cases and/or constraining objectives. Story grooming aside, there are always people trying to over-engineer and estimation is another gate to prevent that.

Agile was a good try to create software process, but it's incomplete at best. The idea that it would evolve is laughably naiive (https://app.spectator.co.uk/2020/04/22/the-illusion-of-certa...). Companies want S&Ps, not sauce that they have to mix themselves.

[hinkley]

I'm not talking about Planning Poker, per se.

I'm talking about the dickering about whether something is N points or N-2 points. Or whether the points even mean the same between two teams. Or whether it's appropriate to assign it to another team or individual who says a smaller number because they have a different definition of Done or are more or less invested in the long-term health of the project.

I'm going to ask this person or the question in this way because I'll get the answer I like, even if that answer is unhealthy or even pure fiction.

[constantine42]

Where I work, all teams have different point systems. When we need to do high level planning, we used a normalized "sizing" system of small, medium, large, huge. They give some numerical values to these and use those as points. They're less accurate on a per story basis, but they tend to average out quite well.