Accurate Story Estimation?

One of the questions that we get all the time is “why can’t you estimate better?” This is a good question, but it’s actually a trick question – and not the right question. What the questioner really wants to know is “why didn’t your actual effort match your estimate?” Now, this is a very good question, and it has a very good answer.

We know that we can think of a story as a request for value; in particular, we usually think of most development stories as if we were being asked for a solution to a problem. The effort it will take to provide the solution (for a story that involves coding) is based on the following four factors:

  1. the intrinsic difficulty of the story;
  2. how robust the solution must be;
  3. how hard it is to integrate the new code into the old codebase; and
  4. the abilities of your team, including the people, tools, environment, and so on.

Each of these four issues is essentially independent of the others, and each of them is difficult to figure out without doing a lot of upfront analysis and investigation – and even then it would probably not be too accurate.

In fact, the only way we can actually know all these factors is to do the story or, at least, to do enough investigation that you might as well have done (or at least started) the story.

There’s no way we know the actual difficulty of the story until we start analyzing and designing it – and the analysis and design should be part of the story. There’s no way we can know how robust the solution is until we’re having conversations with SMEs about the results we are getting – and these conversations should be part of the story. There’s no way we can know how hard the integration with existing code will be until we start integrating – and this integration should be part of the story. Ok, ok, we may know about our team’s capabilities without doing the story, but three out of the four factors are intrinsically unknowable.

So, it’s no surprise that our actual effort doesn’t match our estimates, is it?

Thanks, Dan 😉

Dan Rawsthorne, PhD, CST
Transformation Coach
dan@danube.com

Download the PDF version: Accurate Story Estimation blog

Posted in Agile
2 comments on “Accurate Story Estimation?
  1. Anonymous says:

    The blog entry makes total sense. Realistically though, businesses still need to know when the software will be ready for release, at least as a beta. There are salespeople out selling and marketers getting their promotions in gear and management wanting to know resource allocation for the next several months.

    In an atmosphere where the estimates are rarely true to the effort, what is your suggestion for how the team can set a realistic expectation (in advance) for a releasable product.

  2. Michael James says:

    Anonymous wrote businesses still need to know when the software will be ready for release, at least as a beta.

    Yes, they want to know that. And as the funders of our efforts, they’re entitled to the best information we can give them. The good news is that Agile approaches give us the ability to measure something we didn’t have before: velocity (the rate the team actually turns stories into potentially-shippable product increments). Measuring velocity empirically allows us to extrapolate from real world data instead of shooting in the dark. We also have to consider the historic rate of new requirement discovery (p.k.a. “scope creep”).

    One approach to this, using actual project data that’s been anonymized, is described here:
    http://danube.com/system/files/MacroMeasurement.pdf

    By the way, both ScrumWorks Basic (the free version) and ScrumWorks Pro support this, as shown here:

    http://danube.com/docs/scrumworks/pro/latest/reports.html#prodburnenhanced

    Hope that helps!

    –mj

    Michael James
    Software Process Mentor
    http://www.danube.com

Leave a Reply

Your email address will not be published. Required fields are marked *

*