“Definitions of #NoEstimates”? An enumerated list of counterpoints, Part II

As I set the scene in Part I of this post, I’m centralizing the counterpoints here for the enumerated list of #NoEstimates “definitions” (meaning approaches/arguments) that were nicely laid out by Jay Bazuzi in his recent post. Jay listed 11 items, the first six of which I covered in Part I of my post; I’m covering the last five in this Part II, plus adding my counterpoints for two additional frequent NE arguments that Jay omitted.

7. The parts of our work that can be estimated aren’t the parts that matter: if you understand work well enough to estimate it reliably, then it’s in the Known/Complicated or Obvious domains and you should automate it away.

But everything can be estimated to some degree of accuracy, and “accuracy” doesn’t imply precision. And the very phrasing of the question misses the point on what estimates actually are: note the casual misuse of “reliably” to imply some level of what amounts to certainty. No profession works with certainty. My dentist has never put a crown on this particular tooth, but she has no problem discussing with me the probable time frame, cost, and risks that are involved in doing so.

We’ve got to stop thinking (and we’ve certainly all got to stop exuding the pervasive attitude to our business compatriots) that software developers are special snowflakes who just can’t be reasonably asked to give their professional judgment in a similar manner, in areas they are deeply familiar with in general.  Note too that estimates, properly done, are always revised regularly as your understanding increases. It’s not a one-shot deal. Professionals in any arena simply don’t chronically scoff at normal business questions, and questions on cost, effort, time are all perfectly normal.

Also, think about the automation claim: it’s actually a rather strange and quite techno-centric assumption to make, that anything that you can understand would be both possible and somehow easy to automate. For example, all of us understand quite well the basic process and mechanisms required for driving, but look at auto manufacturers and technology companies struggling with automating the trickier aspects of self-driving vehicles.

Often, what’s very hard to automate isn’t at all hard to estimate usefully. In fact, that’s the whole point. When I drive, any new trip I embark on will have unfamiliar territory and new challenges, yet I am perfectly capable of making some assumptions, setting an overall plan, and adjusting as needed as I proceed. Equally, just because a software project incorporates something new (a technology, an approach, an integration) doesn’t meant that it’s a completely brand-new beast with absolutely no commonalities to what’s come before. We’re humans, we’re engineers, we’re practitioners, and that means we extend tried-and-true techniques and practices every day in various ways without somehow sailing off the edge of the world into the completely unknown/unplannable. We’ve got to stop raising the all-too-frequent lament of “here be dragonsfor every new initiative; it makes us come off, to our business colleagues, like Chicken Little combined with Eeyore.
[Read more…]

“Definitions of #NoEstimates”? An enumerated list of counterpoints, Part I.

A week or two ago, we saw the first interesting new blog post on the bizarre and rancorous #NoEstimates movement in quite some time. Although that post is titled “definitions of #NoEstimates”, it’s not really “definitions” per se; it seems instead to be more of a mixed list of NE approaches (sometimes contradictory, as the author himself notes) and miscellaneous arguments that have been frequently made in favor of the movement. To the best of my knowledge, no such overall compilation has ever been made by a #NoEstimates proponent; as such, I applaud Jay Bazuzi for putting it together.

Of course, each of the described approaches/arguments has been outlined (and countered) individually many times before. But as far as I know, none of the major NE advocates has ever actually addressed any of the counterpoints to them, choosing instead just to block and insult the people making those counterpoints, often boasting proudly that they do so to “filter out the noise”.

In any case, let’s centralize those counterpoints now: here’s an item-by-item recap, springboarding off of Jay’s enumerated list of #NoEstimates approaches. For reasons of space and manageability, I’m splitting this rundown of counterpoints into two separate posts. Here goes: [Read more…]

Quocknipucks, or, why story points make sense. Part 1.

A long time ago, before most people (including me) had ever heard of the concept of story points, I came in as the CTO at a major social networking site. The dev team, even though staffed with a lot of excellent developers, had experienced enormous historical difficulty in delivering according to expectations, theirs or anyone else’s. People both inside and outside of the team complained that the team wasn’t delivering big projects on a timely basis, plus there were a lot of small-but-important items that never got done because the team was focused on larger work.

What’s the team’s capacity, I asked? How much can it reasonably take on before it becomes too much? How do we viably fit in smaller items along with the major initiatives, instead if it being an either/or? No one really knew, or even had thought much about what seemed like natural (even mandatory) questions to be asking.

At the time, I declared that it seemed like we just needed some abstract unit of capacity (I jokingly proposed the first Carrollian word that popped into my head: Quocknipucks) that could be used to help us “fill up the jar” with work items, large and small, without overfilling it. Each item would be valued in terms of its number of Quocknipucks, representing some approximation of size, and we’d come up with a total team capacity for a given time frame by using the same invented Quocknipuck units, which we would adjust as we gained experience with the team, the platform, the flow.

Little did I know that I was independently coming up with the basic idea behind story points. Interestingly, the term I chose was deliberately whimsical, to separate the concept from things in the real world like the actual amount of time needed for any particular item.

Here’s what I’ll argue: the basic idea behind story points is sound, and useful; yet, somehow a certain set of Agilists has now come to reject story points entirely, even referring to them (wrong-headedly and quite overstated) as “widely discredited”.

[Read more…]