Estimation Smell

Sometimes it seems there are dependencies in user stories, and the dependency can cause confusion on how to proceed with the estimates, and like many things estimation isnt an exact science. A number of times over the past year this problem has cropped up in some form or another. One approach I like is to think of the stories in isolation, because it not only keeps things simpler for everybody during planning, but it also works very well with the principle of change – the customer is allowed to change priorities.

Consider the following stories:

  1. Show ticking stock prices (3 points)
  2. Show ticking index prices (1 point)
  3. Show ticking hedge prices (1 point)

A possible way to estimate these could be to say that if we do the stock prices story first, it will take 3 points, and the rest should be much quicker, say 1. But theres a problem with this way of estimating – what happens if the customer requests to do the hedge prices story first? To make some sense we would probably have to change the estimates on the other two dependent stories. A second issue is that there is a smell here – if we are building just-enough-infrastructure, adhering to the 80/20 rule when building the code, we shouldnt have a “framework” at the end of the first story. What happens if after doing the framework to allow the other two stories to be implemented much faster, the customer requests to drop the other stories for other more important work?

Another possible way to deal with these dependent stories could be to pull out the technical aspects, create a story for those, and then stabilise our estimates on the actual three stories above:

  1. Build ticking engine (3 points) // Technical Story
  2. Show ticking stock prices (1 point)
  3. Show ticking index prices (1 point)
  4. Show ticking hedge prices (1 point)

I wouldnt take this approach any further for the simple fact it sides-steps all of the techniques we are trying to harness to help us deliver just enough software faster. The technical story not only has to be done first (which reduces the customers ability to prioritise based on business value), but after the technical story something could arise that would force the customer to drop the other ticking stories, leaving all of the technical “infrastructure” in place in the system. I have never liked this approach because it completely avoids the process of emergent design that would be used to build the software incrementally around the axis of these three stories.

In the end the principles I like to keep in mind are:

  1. Simplicity
  2. Individuality
  3. Simple Design

Simplicity – keep the estimations and process of dealing with them simple. As soon as it starts to “feel” complicated, thats probably a smell.

Individuality – see work as individual pieces.

Simple Design – possibly one of the hardest principles to learn, but very important to grapple and gain experience with, since it is one of the key enablers to building high-quality software fast. In the original stories above I would see that I would need to build something to allow me to get some ticking in each of the stories. I would be thinking how I could bring something into existence that would be as simple and as lean as possible. This could cause me to lean towards estimating all around the same size, such as 2 or 1.5. Not a true fan of decimal estimations I would also consider just leaving all at 2.

    • Wan
    • May 14th, 2007

    great post!

  1. I think your solution is absolutely spot-on! I like your reasoning and I think you have arrived at the correct solution.

    If the Customer does indeed proceed with all 3 stories in the order listed, JiT design will allow you to adjust the architecture to one that fits them all – only when there is a clear business reason to do so. Who knows – you might not even end up with a “ticking engine” of any recognizable form, but that’s the point! You’re supposed to be solving the Customer’s business problems, not looking for some Grand Unified Architecture. 😉

    Once, years ago, when I was young and foolish, a (wiser) friend saw me over-engineering some code and said “There’s no Nobel Prize for programming.”

    • Nick Robinson
    • May 29th, 2007


    I like your GUA reference – I think I’ll use that. You are right about the “ticking engine” – through simple emergent design, the outcome might be very different to the conjecture from the begining of the stories. Admittedly this part of XP is difficult, but its well worth practising.


  1. No trackbacks yet.

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

%d bloggers like this: