Eight points for one team is two points for another team

I've spent a lot of my time helping ours grow into a collaborating by walking them through my expectations of a product brief and what we need from our user stories. They're also really good at helping with the release, managing story sign-off and communicating changes with the other teams (customer success, account managers, sales team, etc). A good product manager manages... the product. They also collect all the user feedback, validate feature requests with data, and act as a guard for the rest of their engineering team.

That sounds wildly micro-managey. I often don't know how long something is going to take until I dig into it; sometimes I don't know how long something is going to take until I'm almost done. The ambiguity/fuzziness of points is a feature, not a bug.

If I'm going to be "held to account" based on my estimates, I will optimize for producing work that matches my (naive, uninformed, up-front) estimate, rather than producing the _right_ work. This will last for a few months, at which point I will realize I'm burned out, working inefficiently, and writing bad code, and I'll find a new job on a different team that doesn't treat its employees like train conductors.

I have, at a truly well-run engineering team. She was fun to bounce ideas off of, and quick to rope in relevant experts, business or techincal. She also understood the value proposition of each feature, and could easily spot if you were wasting cycles on something unimportant.

Probably not coincidentally, this was the only place I've worked where KPIs were truly a useful way of framing our place within the organization.

The point of the numbers is to be a tool for the team, not management. If they get reported up it should be at most one level (immediate supervisor/lead, not middle or upper management). The information provided, assuming that the team is moderately consistent in their point assignments to tasks, is: Are we holding steady, slowing down, or speeding up?

Steady and accelerating are the good cases, slowing down leads to questions. "Why did we slow down?" "Oh, that task we gave a 1? Turned out it was actually huge because it involved X which none of us noticed or was more broken than we realized. Took up the entire time." Or "We brought two new people onboard and were spinning them up. They aren't productive yet and our experienced people were spending the time bringing them up to speed. We should get back to the normal flow in a few weeks." Or "We have no idea" which drives more questions. Or "We brought on two new people and spun them up, but now their estimate inputs are changing how our tasks are scored so it will take a bit to figure out our new baseline."

All of that assumes the team tries to be consistent in their scoring and is reasonably stable in its composition. If you're changing out team members frequently, then there is no value from points (because they won't be stable). If your team decides to fuck with it by rolling a die and using that for each one, then there is no value either.

When you change your processes in some way (and assuming a stable team and scoring), then you can also use the velocity over a series of sprints to evaluate the effectiveness of the change. If it hurts, you'll see a long term decline, and if it helps you'll probably see an initial decline (learning) and then improvement.

> “Building the wrong thing on time and within budget doesn’t buy you much.”

Let's get one elephant out of the room out right away. Many in the #NoEstimates camp are speaking from the position of some enterprise context where the business technically has already built the right thing, they have revenue, aren't innovating much (by design), and as long as they keep the ship afloat and don't make too much of a mess of things, they're fine - or at least engineering isn't going to be the deal breaker.

Estimates or no-estimates in these context-- who cares. Literally anything you do on the engineering side means nothing to the upside of the specific product line you're working on, and if you look around you in these contexts, you'll find gross and massive inefficiencies abound and none will have anything to do with your dev process, agile, estimates, no estimates, what-have-you.

For the rest of us, you live and die by execution, which includes your ability to prioritize what you're delivering, all of which means nothing if you're not estimating - however indirectly or directly you are estimating.