Subscribe via RSS

How Many Bedrooms Did You Say?

Filed Under Estimation, Software Process


As we all know, perhaps the largest communication problem between a client and the developer is the misinterpretation of requirements. Client verbalizes what he/she wants, we believe we have the same mind’s eye of the scope and implementation of those ideas, and thus go merrily on our way down the wrong path.

For example, let’s say we use the simple example of the task – “Build Me A House”. Without a shadow of a doubt, the very first question that needs to be asked is – “How many bedrooms?”.

Unfortunately, alternative (and less important) questions are prioritized ahead of the basics:

  • What materials should we use?
  • What is your budget?
  • What is your time frame?
  • What about details X,Y,Z?

Do not read me wrong, these are very important questions to ask, but they are important questions to ask after the most important question of all – assuming I don’t have all the information, roughly how big is this thing?

About now I am assuming you have 2 outstanding questions; why prioritize the rough size question above all others and what is up with this stupid bedroom analogy?

Why prioritize size and complexity before questions such as budget and time? Simple, knowing the size and complexity will trigger a defensive response when the answer to all other questions are not inline with the size. For example, assume we know the budget and time frame when presented with a size or complexity that does not match, instead of being defensive and pessimistic it is common for us to become optimistic and believe we can get it done under those constraints. This of course is a huge mistake.

As for the bedroom analogy, the underlying moral of the story is – find estimation cornerstones. In houses, you make huge assumptions on roughly how large a house is based on how many bedrooms it has. 4 bedrooms? Probably 2 bathrooms, 1400-2200 ft, and a yard….just a guess, but you see my point.

Without a doubt, you will be able to find those weird 2 bedroom mansions, 4 bedroom apartments, and standard suburbia 4 bedroom houses with swimming pools and marble kitchens; however, those are the exception and not the norm. By asking how many “bedrooms” you should be able to make a huge amount of assumptions up until you get hit with a modification that breaks the norm. These “normality breakers” however are commonly very out in the open (nobody expects a house builder to come in on time and under budget if you neglected to mention the swimming pool and sun room, therefore it gets mentioned).

There are tons of estimation cornerstones (some which I myself am experimenting with) such as:

  • How many Epics / Themes can I detect early on? (for those using user stories)
  • How many Roles / Persona have been mentioned?
  • How many integration points are needed?

Depending on your environment, there might be a completely different set of criteria you might look at as a “bedroom”; however, I do believe that you will always be able to find at least one. The client budget and time frame is always on the forefront of the discussion; however, those are variables that [regardless of what they say] are mutable, their need for a 3 bedroom house is not.

RSS Icon

  Don't miss a drop! Subscribe now via RSS or email.


2 Responses to “How Many Bedrooms Did You Say?”

  1. Weekly Link Post 93 « Rhonda Tipton’s WebLog on May 11th, 2009 7:56 pm

    […] some great points about the misinterpretation of requirements in the development cycle in his post How Many Bedrooms Did You Say?. “Client verbalizes what he/she wants, we believe we have the same mind’s eye of the scope […]

  2. Matt Baker on May 20th, 2009 7:37 pm

    I had a very similar example to this one in a presentation I gave to my team last month. Except my example involved the wonderfully vauge requirement “the house shall have a front door”. As you can imagine, that one got fun pretty quickly.

Max Pool - © 2024 - {codesqueeze}. Sycorr Banking Solutions