Modern Agile Bullshit #1: Story Points are Pointless

Alright, folks, it’s time to put on our hip waders and wade through the cesspool of modern Agile bullshit. Today’s steaming pile of nonsense: story points.

So, here’s the deal. A bunch of Agile “experts” (and I use that term looser than a wizard’s sleeve) have been peddling this idea that estimating work using abstract “points” instead of good old-fashioned time estimates is the bee’s knees. They claim that points are more accurate because they account for the variability in developer productivity. Well, I call bullshit.

Let’s break this down, shall we? First of all, points are always, ALWAYS, translated back into dates for planning purposes. No business in the history of capitalism has ever operated solely on an abstract point system divorced from the constraints of time and space. Dates are the bedrock of planning in software development, not some arbitrary, made-up points.

But wait, it gets better! These Agile acolytes want us to treat developers like interchangeable cogs in a machine during estimation. They expect us to pretend that all developers are equally productive and that a point is a point is a point, regardless of who’s doing the work. News flash: developers are unique snowflakes, each with their own quirks and tendencies when it comes to estimating.

Some developers are more cautious than a cat in a room full of rocking chairs. They’ll overestimate tasks like it’s their job (which, ironically, it kind of is). Others are so optimistic, they make Pollyanna look like a goth kid. They’ll underestimate work with a smile and a shrug.

But here’s the kicker: as long as a developer is consistent in their estimating tendencies, you can apply a simple multiplier to translate their points into realistic dates. Let’s say Cautious Cathy always estimates double the actual time needed. No problem! Just multiply her point estimates by 0.5X to get the real deal. On the flip side, Optimistic Ollie always underestimates by 80%. Easy peasy, just multiply his points by 5X, and you’re golden.

By tailoring estimates to individual developers and converting points to dates, we can inject some much-needed realism and honesty into our planning process. We can stop pretending that points are some magical, universal constant and acknowledge the inherent variability between developers.

It’s time to face facts, folks. Time is the one true constant in software development. Dates are real, points are imaginary. The sooner we ditch this point-based estimation nonsense and get back to good old-fashioned date-based planning, the more predictability and sanity we can bring to our projects.

So, let’s stop drinking the Agile Kool-Aid and start calling out these estimation fallacies for what they are: pointless bullshit. It’s time to roll up our sleeves, embrace the reality of individual developer differences, and plan our projects based on the only currency that truly matters: time.

Remember, folks, in the high-stakes world of software development, it’s better to deal in cold, hard dates than to get lost in the abstract wilderness of story points. Let’s leave the fairy tales to the children and get back to building real software in the real world.