Edwin Goddard

So many of the comments I hear about estimation boil down to "but we have to plan and meet our goals." That's a deep failure to grasp the concept (of agile ways of working). We plan strategically, and our goals are strategic. The details of what we have to build to meet those strategic goals are discovered incrementally by releasing small bits of valuable software and getting feedback on it. We defer details, in other words, to the last responsible moment. Defining those details too early doesn't really work because the customers themselves won't know what they need until they have something in their hands. The details are invariably wrong. Too-early focus on details also often leads to building things nobody wants or needs. There are occasional exceptions, of course, in the corners of the program where regulations, or the actual behavior of actual hardware, or necessary algorithms apply, but those bits comprising the entire system are exceedingly rare.

Maybe instead of #NoEstimates, it should be #WhyBother. We all know they don’t work. Estimates are the worst sort of productivity theater, given that nobody believes that they’re even close to accurate.

A Sprint is NOT a mini project. You DO NOT commit to finishing some specific bit of work (or be somehow penalized if you don't "finish" on time). It's NOT about completing stories (or, horrors, retiring tickets). That's all nothing but control-focused waterfall management bullying people into working in ineffective ways. A Sprint has a _goal_, not a target. E.g.: "make our customer's life better in this product area" or "help the user do X." Anything you can build that moves the product in the direction of that goal is just fine.

Estimates are not needed for choosing what work to do. The only thing that matters is customer value. If something is essential to the customer, you cannot choose not to do it. If it’s not essential, don’t work on it at all. Admittedly, they may be useful for cost-of-delay computations, but you don’t need an “estimate” beyond high-medium-low for that.

Backlogs are a Scrum thing, not an Agile thing. Customer-driven shops that work with agility decide what to do next by doing the current thing (and getting feedback). The decision is driven by strategic planning, but backlogs are entirely tactical.

The product owner's job is NOT to tell the team how to do its work or what to work on. They "order the backlog" but it's up to the team as a whole to decide "who does what, when, and how." A PO is ***not*** a manager. They tell nobody what to do. Their job is to understand the market as a whole, to arrange conversations between the team and the customer (they are **not** an intermediary between the two), and to organize the work by value. That's it. What they do is nothing at all like the old Business Analyst job. They are ***a team member*** who specializes in product development.

Deming said “You can only measure three percent of what matters”. The industry's obsession with metrics does a lot of damage. I'd certainly focus on solving tangible problems, but I find that using metrics as a measure of success (whatever that is) is usually counterproductive.

"Low performance" is an indicator of bad management, not a bad team. To improve performance, you must change the system within which the team works. Local optimization fixes nothing (unless you're dealing with a bottleneck, but dependencies are themselves a symptom of a bad system.)

I can think of nothing valuable to do with estimates. They are all about up-front planning. Otherwise, they're a guess. An up-front plan with enough detail to estimate is actively anti-agile, where change is welcomed even during the development process. Instead, focus on moving incrementally towards strategic goals and on delivering something truly valuable (to customers/users) as often as possible.

Yes. Work (very) small, release (very) often. Small things that provide customer value that are released often bring in revenue sooner == business value. It's a win win. Large batches create liability in the hope that you'll provide some value weeks (or months) down the line. It's very risky to work that way.