Agile Estimation: Guessing Intelligently

Estimation is fundamentally a “guessing game” but in many environments, it is seen and used to make predictions or commitments as to when something will get done.  Even worse, is that many organizations focus very hard on trying to make commitments in the large instead of in the small.  It’s been stated many times that product development is the art of creating new recipes.  There is so much uncertainty in the large.

I actually believe that estimation is an activity that should be done as infrequently as is possible and when done, should be extremely light-weight.  I know this might be a bit controversial, especially for my traditionalists friends, but hear me out.  I don’t see estimation as a much of value-add to the product development process in most cases.  Estimates in the large ultimately create undue pressure (not challenges) and try to impose order on an inherently complex systems.  Unfortunately, we don’t learn and keep trying and keep failing. Einstein had a description for such behavior.

This post is going to look at estimation in the case where a “Fixed Date” is not in place but we need to get a sense of the effort required in order to determine what should be done next or as input into a high-level release plan.  A “Fixed Date” means that a solution much be delivered or live by a certain date.  In the absence of this constraint,  I suggest a completely different approach to estimating. There is a lot of effort (possibly overhead) in planning for a Fixed Date so it must be worth it.

The smaller the work item, the better we generally are at estimating.  The smallest work item is usually a “task” and so if you are looking for an accurate estimate that will translates to effort (cost) and schedule (delivery), then a user story/requirement/whatever should be decomposed into all its composite tasks and every single task should be taken into consideration. I have made the mistake in the past of not having every different role explicitly specify and estimate their tasks.  For example, instead of having a business analyst, developer and tester estimate the same line item, each role estimate their tasks separately.

However, when beginning a new initiative (such as adding a new module) referred to as “themes” in agile speak and “requirements” in other contexts, the tasks are pretty obscure, so what do you do when you’re required to give an estimate?  Well you could go through the process of decomposing down to tasks but as mentioned above, except there is a “Fixed Date” for delivery, I wouldn’t do that.  I would start with T-Shirt sizes.

T-Shirt sizing provides an avenue to quickly categorize and classify themes into buckets without expending too much effort.  Now these sizes need to tie back to a common unit of measure.  In my experience, non-product development folks may not understand things like “story points” (if you are using user stories) and so hours/days may need to be used i.e. develop estimates in the language currently spoken in your environment.  I believe in using ranges in estimates given the uncertainty that is product development and to account for the cone of uncertainty.  So an example (in hours) that I just used recently could be:

  • XS:    1 – 100 hours
  • S:       100 – 500 hours
  • M:     500 – 1000 hours
  • L:       1000 – 2000 hours
  • XL:    2000 – 5000 hours
  • XXL: 5000 – ?

The key is to use a scale that works in your environment.  Maybe all your requirements are smaller i.e. under 1000 hours, then XL would be 1000 – ?.  The disadvantage with using hours/days is that most product developers are tempted to want to breakdown themes into tasks in order to provide what they consider “better” estimates.  A way to mitigate this, is to find a baseline item to work with, such as previously completed initiative (historical data) or another item within the list of themes for which there is more “confidence” about its estimate. Another key point to emphasize is that we’re just attempting to identify at a high-level how much work we think we have.  By no means should concrete plans be made on such estimates.

A question that I often get asked, is ‘who’ do I think should provide these “high-level” estimates, especially on teams with different roles involved.  This is a little tricky because different roles bring different perspectives to the table.  However, my general answer is that the senior technical people who understand the domain should be the primary estimators at this level and it should ideally be more than 2 people.  Leverage the wisdom of the crowd.  Use the Wideband Delphi method.  When discrete tasks are being estimated, get everyone involved.

Assuming the “cost of delay” for a theme has been determined, the result of the estimation process should help drive the selection of the factor should determine.

What do you think?  How do you (if you) estimate large requirements or themes?


8 Replies to “Agile Estimation: Guessing Intelligently”

  1. Hi Eb,

    “How do you (if you) estimate large requirements or themes?”

    Have a bunch of guys/gals with prior experience working in a similar context with a similar team, solving a similar problem to have a SWAG (Sophisticated Wild Arse Guess) at how long “something” should take.

    With the right bunch of folks, I have found this approach to be pretty accurate 🙂

    The rest in my experience is about managing expectations, planning contingencies, and effectively using feedback.

    The biggest misconception I find is the lack of appreciation that things always change. The “something” itself is a (S)WAG. Requirements and/or themes aren’t well defined items out there just waiting to be gathered 🙂 People make them up, and as their understanding of the problem improves (through discovery and feedback), the requirements change also.

    So we end up in this strange scenario where the problem is constantly changing, yet the key stakeholders expect the estimate to stay the same. This is where it all goes wrong IMHO.

    There is an in-built bias in our industry against dealing with the unknown. Yet we live in a world of unknowns. We talk about systems, as if the only type of system possible are closed and predictable”clock-work” machines. Yet we experience open complex adaptive systems that co-evolve with their environment every day. How about the weather system? 🙂

    In the face of complexity, you can detect patterns and make sense out of chaos, continuously adapting your actions to keep yourself in the “safety zone”. It starts with acknowledging that chaos is a normal part of every day life. Ignoring this reality leads to pointless attempts to predict the unpredictable.



  2. Hi Eb,

    A couple of additional points. Kudos for including Dave Snowdens’ kids party. Managing kids is a process of adaptation. Mums become pretty effective Chefs, knowing how to mix the right ingredients at the right time in response to events. They don’t rely on fixed recipes. Interestingly it was a toss up whether the joint manifesto for “light weight processes” was called the “Adaptive Manifesto” or the ‘Agile Manifesto”. In hindsight I think the guys chose the less descriptive name. Adaptive Software Development is a better description of what we actually do 🙂

    Also all this estimation/prediction malarky boils to to the fear of the unknown. Not knowing leads to fear. Yet not knowing is part of the intrinsic nature of a complex adaptive system. We need to learn to accept the unknown, and trust in our ability to respond quickly to events as they emerge (like Mums do). Unfortunately this trust in the ability of teams is extremely rare (rightly or wrongly :)).

    Knowing this to be the case I have found the language of risk to be a very useful tool. Risk Management, is grown up speak for managing peoples fears. Interestingly a CAS perspective and the traditional Risk Management perspective are in broad agreement, although each uses its own language. I find that Risk Management can be an effective approach. Allowing the introduction of CAS ideas through the back door 🙂



    1. Hey Paul –

      Thanks for your feedback. Yes, these systems are complex. But I would suggest that many a case, the right skill for existing in complex systems is lacking. I’m befuddled by this given that life is inherently complex (at least in my opinion)!! This theme (excuse the pun) is probably the subject of another post. 🙂

      Ah, Risk Management. That’s a great point. We are managing risk. I’ve found it harder to convey that perspective to folks (even software folks), but I keep trying!



  3. Hi Eb,

    ” But I would suggest that many a case, the right skill for existing in complex systems is lacking”

    The right skills? I would go further, often the right mindset is lacking. You either get it or you don’t, and most don’t.

    ” I’m befuddled by this given that life is inherently complex (at least in my opinion)!!”

    This has perplexed me too. I’ve come to accept that it is a natural reflection of the fact that most of us are pretty analytical (left brained) in nature. We must have all the answers, and not knowing is just unacceptable, even if that means us pretending we know, when we really don’t.

    The original Agile movement started to buck this trend, but I think it is deep rooted. For example most people who are attracted to “Lean” ideas, don’t accept that software development is indeed complex. Many would argue that it is merely complicated.

    Making them destined to repeat the mistakes of the past again, and again, adopting one fad after the next. A good source on this pitiful history is Jerry Weinberg. He’s seen it all before 🙂 Dave Snowden provides a great ontological description of different system types and the appropriate behaviour for each. He explains why our preferred Newtonian, analytical approach doesn’t work in the face of complexity. I can send you a link to the paper if you like. Yet many software people still don’t make the link.

    I’ve accepted it, which is why I don’t post as frequently to software forums as I use to 🙂 I found I was wasting my breath 🙂 Interestingly though, these ideas have taken root in some Management circles, so not all is lost.

    In Software circles however, Ontological myopia is very much the norm. Making the propagation of fads a profitable endeavour, with a ready market. 🙂



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s