If you assigned 1 story point to every story, how much slicing would you do before you were confident you could actually complete each story in a day or so? Congratulations! You just discovered #NoEstimates. Stop trying to fit the estimate to the story. Start slicing the stories.
@erichbuhler While the neuroscience behind estimation is interesting, the cognitive and social benefits aren't exclusive to traditional practices. #NoEstimates achieves the same benefits without the antipatterns of traditional estimation.
It's a well know fact that meteorology (science of weather) can scarcely forecast more than 5 days of weather ahead. Yet, software projects (which are also affected by the weather!) pretend they can plan in detail several months ahead. #noestimates
"It's hard to predict what this dice will roll."
"Well, then, you need to get better at predicting."
Conventional wisdom about software development processes - that unpredictable work needs better estimates, not a more predictable way of working.
@carlvellotti Stop trying to guess how big a story is. Estimate all stories as 1 point. If the team isn't 100% confident that it's 1 point, split it. Then prioritize stories by value each iteration.
If a story took longer than expected discuss as a team to understand why.
A common criticism of #NoEstimates is that the term is misleading. It's not without merit. Given its emphasis on empirical evidence over expert opinion here are just a few terms that would be more accurate:
Evidence-Based Estimation
Performance-Driven Planning
Adaptive Planning
Any management that wants you to give them predictions so they can plan is living in la-la land. That's the opposite of agility. Slapping agile-ish words on waterfall does not give you agility.
Why do ppl assume that estimates are necessary? I don't see the need for them myself. They're solid waterfall thinking—big upfront plans, milestones, months-long delivery cycles. Not much agility. It's deployable right now. It will be deployable w/ this new capability tomorrow.