I’ve had a long career with estimates in software projects. While it’s been a rocky journey, I now feel that I’ve gotten to the point where I truly understand how to and the value of estimation.

But before I give you the great reveal, let me share some of my history…

Estimate Newbie

I first began my career as a newbie in estimation. I fell into the trap of being as honest as a could be and I found that my estimates were often used against me. For example:

  • My bosses would often forget the “fine print” around the estimates. Words like – “this is only a guess until I get more formal requirements. Or, I’ve never done this before, so I really don’t know how long it will take” were never remembered. Imagine that?

  • People who had not a clue would weigh in on my estimates. Bosses, who were under pressure to release quickly, would cut them. And project managers, who were trying to “defend” the project, would pad them. And my developer colleagues, who always had an optimistic spin on things, their estimates would always be lower than my own. Imagine that?

  • And I always felt that nobody wanted the “truth” in estimates. That they couldn’t handle it. So, it negatively influenced me to pad/cut depending on the situation. But the key point is the inherent dishonesty I felt around all estimate discussions. Early on, it felt like a game of sorts. Where the last one that weighed in on a number…won. And the development team…generally lost. Imagine that?

But as in all things, I grew in my experience and in my career. Soon, around the late 1980’s, I became a “manager”. Which meant that I not only had to estimate for myself but for my group(s) as well. This showed me both sides of the estimation continuum and frankly, I didn’t like it much.

Estimate Maturity

Later in my career, I became a sort of aficionado of fine estimation. A sommelier if you will ;-)

I studied and used:

  • Various flavors of team-based estimation

  • Early agile Story Point estimation

  • Function Point estimation

  • Use Case Point estimation

  • Personal Software Process (PSP) and Team Software Process (TSP)

  • COCOMO and other variants of data-driven estimation

  • Other algorithmic / probability approaches to estimation, for example, Monte Carlo simulations

This was in the early 1990’s and into the early 2000’s (around 2003-4).

During this time, my Holy Grail was the search for an estimation mechanism that proved to be accurate. I was less focused on what we were delivering and how well it worked. Instead, I was much more attuned to the accuracy of our plans.

I even started teaching these estimation techniques at conferences. Something that today, I’m not that proud of ;-)

Agile Estimation – Early Days

I guess the AHA moment for me was in the early days of the agile movement. And it crystallized with my reading Mike Cohn’s work around Agile Planning and Estimation. I consider that book to be a seminal piece of work by Mike. Especially given the timing of it.

What many don’t realize is that we (in the agile community) were really struggling with key elements of agile tactics in 2004 and 2005. So, the early days. Two of those elements were writing solid user stories and effectively estimating and planning in agile contexts. Mike Cohn provided tempered guidance on these two challenges at a time when we needed it the most.

I came to understand the value of “good enough” estimation that relative, story point estimation gave us. It got us close to the target. I also came to understand that the conversations that Planning Poker created were much more important than the actual point values that surfaced. Something I had never considered before.

Another technique that I discovered was team-based release level planning. This more so came from the XP community and the wonderful XP planning book by Kent Beck and Martin Fowler.

https://www.amazon.com/Planning-Extreme-Programming-Kent-2000-10-16/dp/B017S2CU00/

I began to feel like agile estimation techniques AND the resulting balance between (estimation, planning, forecasting, commitment, etc.) and the (actual results delivered) had achieved the BALANCE that I’d be longing for. It felt right. And the emphasis shifted to delivered results over infinite planning. How cool was that?

Sidebar

I have an interesting sidebar to share. At the time, I was so interested in estimating techniques that I started to write a book. It was focused on the journey from traditional estimation techniques to agile estimation techniques. I was hoping to provide a bridge for traditionalists that supported basically user stories, collaboration and relative sizing (pointing).

I was close to finishing the first draft when Mike Cohn’s book hit the streets. I read it immediately and realized that my efforts were no longer relevant. Mike had delivered something that blew the market away. I also learned that timing is everything ;-)

Agile Estimation – Now

If you listen to Josh Anderson and my thoughts on some recent Meta-cast podcasts, you’ll see that we’re discussing current estimate trends in the agile community. Much of it surrounds the #noestimates movement.

(with a nod to our colleague Ryan Ripley who has been a vocal supporter of it for quite some time)

In our view, we’ve seen agile estimation trend in the following ways –

1) Teams have been reducing the number of units. Ten years ago, Fibonacci story point estimation seemed to be a standard. But there were so many choices, that it largely created team confusion and less than meaningful debate around closely similar values. Today teams more often use T-shirt sizing or similar, very simple relative units to drive sizing, but more importantly, driving healthy discussion around level-of-effort, complexity, and risk.

2) There is an ongoing healthy deemphasis on the estimates and a healthier emphasis on collaborative discussion. Planning Poker, facilitated properly, helps to encourage this. As does, healthy backlog refinement activity. The notion of 3-Amigos is also an effort to bring different perspectives (personas) to the table to create even richer discussion.

3) One trend that we’re concerned about is “leadership” still expecting waterfall / project management levels of commitment from agile teams. Meaning, fixed date/scope projects. This puts traditional project pressure on agile teams and it forces them to do things like:

  1. Pad the estimates; basically lying;

  2. Try to please executives with far too risky commitments;

  3. Compromise quality in order to hit an artificial date;

  4. Overwork which impacts quality and morale;

  5. Amongst other dysfunctional behaviors…

But more and more leaders are looking for the TRUTH rather than trying to influence these sorts of behaviors. They can handle the truth and then make quality leadership and customer discussions accordingly. In other words, they’re ready to LEAD.

4) I’m really glad for the spirit of the #noestimates movement. It’s really not about not estimating. From my perspective, it’s more about:

  1. Simplification;

  2. Placing a focus on valuable & predictable iterative delivery over estimate accuracy;

  3. Where possible, working in such a way as to eliminate finely grained estimates;

  4. Emphasizing conversation and collaboration;

  5. And perhaps, getting Leadership’s attention around the importance (not!) of estimates versus the importance of (yes!) iterative, predictable, value-based delivery.

Wrapping Up

My “inspiration” for this post is the following article:

https://trackchanges.postlight.com/estimation-is-a-core-competency-36dfc1dfdea3

While it’s a very good article on estimation, I think it had an anti-pattern influence on me in writing this piece.

It made me reflect on the VALUE of estimation as it relates to the VALUE of delivery. That is, I’m more and more coming to the conclusion that estimates have very little intrinsic value. Customers don’t buy them or use them in any way. And they’re often wrong…especially early on.

Of course, your own leaders use them for forecasting and customer commitments. However, they also need to understand the quality and reliability of any software estimate. That is, embrace the inherent variability and risk and make business plans and decisions accordingly.

Stay agile my friends,

Bob.

1 Comment