Skip to content
0:00 / 0:00

#noestimates#agileestimation#storypoints

Time to stop the madness. Time to stop estimating.

Development That Pays

74K subscribers • 1 video on Hallway

YouTube
  • Recommended by 1 person: 1 in engineering communities.
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

11K views3 years ago1 recommendation

Tools and practiceCode review and teamworkDeveloper productivity

An explanation of why software development teams should stop estimating and focus on throughput instead.

The biggest problem in Agile today is the degree to which we rely on estimates. = = = = = = = = = = = = New for 2024: my best-ever training: "How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout" → developmentthatpays.com/webinars/p-and-p?ref=yt = = = = = = = = = = = = 📎 Grab your FREE "Estimates vs. #NoEstimates" Cheat Sheet: pages.developmentthatpays.com/cheatsheets/estimates-vs-noest… 🎬 Watch this 4-part series from the beginning: youtube.com/playlist?list=PLngnoZX8cAn-cLyBLerru-kROqXN3wrkU 🎥 Watch Woody Zuill at Agile India 2017: youtu.be/3f1JebvRnOw Image by cookie_studio on Freepik - freepik.com/free-photo/close-up-cherry-woman-s-hands_7831730… ------------------- 153. Time to stop the madness. Time to stop estimating. #NoEstimates #DevelopmentThatPays Today’s episode isn’t just the end of this series, it’s the end of a journey that began 6 years ago… In 2016 - I asked the viewers if this channel about worst bit of agile And discovered that I wasn’t the only one that had concerns around estimates. It’s a thorny issue - especially as the process of estimating - is generally well-regarded as a great way of getting shared understanding o the work. A weird case of the means justifying the end A couple of years went by and I eventually knucked down to build a course on how to get better at estimating. I had most of it done and dusted when I stumbled across THIS VIDEO. And it really spoiled my day. This is Woody Zuill. Woody, as you may know, is the originator of #NoEstimates. I’ll put a link to the full 90 minute talk in the description below. But I want to play you a very short section where he shares an analogy // is that enough “Maybe not eating the junk food is the best solution“ The moment that I saw that, … I couldn’t say how or why but.. I was sure it was true. What we’re trying to do with estimates … … what I was trying to do with my course … is the same as trying to “chew junk food better.” We shouldn’t be trying to get better… get rid. For the first time I saw that there’s a whole industry out there dedicated to “how to estimate” and “how to get better at estimating”. And I knew right then that I couldn’t have any part of it: I had no choice but to take a hatchet to my course. // I’ve worked this in later Of course, eliminating [getting rid ] estimates is easier said than done, given that they’ve somehow weaved their way into, well, just about everything we do: Take a look at this: We start by estimating. That gives us Estimates. From estimates (over multiple Sprints) we can calculate (derive ) velocity And estimates and velocity are used jointly and severally for, well, all kinds of things: And for all manner of charts and reports - Burn ups, burn downs, that sort of thing Including… Forecasting // Say why splitting out selecting items from t

Why it's here

1 person recommends this

What people say. Recommended as a good argument for throwing away story points and tracking throughput instead.

u/becauseSonancein r/ExperiencedDevs • Recommends

On “Just dont bother measuring developer productivity”

I really like this guy’s take. If the brass force you to track something, throw away the story points and just track throughput (number of prs merged). It’s no more game-able than story points, with the benefit that trying to game it is actually beneficial since that would just reduce batch size