> If the thesis that “90% of everything is waste” then Planning Poker is also a waste, and we should devise a planning process to avoid this.
> In the next article we’ll look at how we might do that.
Cost estimates only are valuable if a) the amount of time involved is relatively large, b) you expect to learn nothing during that time, and c) the expected-value estimates are precise enough that you can calculate a narrow ROI range.
Instead, the way I prefer to work is with continuous delivery and small units of work. If you are releasing daily or more often in a context where you can learn a lot via experiments and user tests, then estimates cease to be valuable.
Another way to look at this is in terms of push systems versus pull systems. Scrum was made for push systems, where executives push large idea lumps through a plan/design/build/release process. In that world, estimates are valuable, if only because executives like to appear in control and need signals to tell them when to yell at people.
But in a pull system, you have small, cross-functional teams observing user behavior, developing problem and solution hypotheses. There, delivery is used mainly to test hypotheses, which are then revised based on new data. In this context, batch estimates are generally wasteful because new data and new hypotheses change the basis for estimation too often. There's rarely sense in estimating a month of work when every day you're learning things that change what you'll do and how you do it.
This article focuses on the Timebox issue. I'll be posting the follow up in a couple of weeks, will post on HN... although there's plenty of other content on this site that covers where I'll be going with that solution.
Apologies if it didn't cover everything you wanted - but I find that long articles tend to lose the readers too easily, and I'm trying to keep to a single main point-per-article in my writing as a matter of discipline.
I'll look forward to your thoughts on the next one.
I tried to read it, but "page does not exist".
----
Edit for clarification: First link in first paragraph after "10X" section header. About "visited the terrain before".
"But actually, we’re now three degrees away from the original problem of trying to build the right thing. The team is focused on figuring out how much they can get done in a Sprint, not whether they are building the right thing. Scrum purists might argue that this is the purpose of the Sprint Goal, which should be agreed in advance.. but actually this is usually just a bunch of items from the backlog, shoe-horned into a sprint-sized chunk of time."
However, I am pleased that people seem to agree with this article's diagnosis of the problem.
The next article will build upon this one (and others in the series). Hopefully it will be equally well considered on HN, I am interested to see how it goes down.