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.

A BIG thanks to everyone that participated in both the Atlassian Stimulus event and then the Codesqueeze Charity Kickin. Atlassian raised a HUGE $100,000 for the charity Room To Read, and everyone that participated in the kickin raised another $345 to go towards a great charity.

I really look forward to doing this again – what a great cause!

Agile and Scrum has done a horrible and irreversible injustice on software culture with it’s term – Product Owner.

The definition of Product Owner straight from Mountain Goat:

The Product Owner (typically someone from a Marketing role or a key user in internal development) prioritizes the Product Backlog.

Scrrrreech. Repeat that? Don’t see the problem yet? There are really two pieces here, so let me explain.

The first flaw is in the semantics of the word – owner.

owner: to have or hold as one’s own; possess – Dictionary.com

In short, we have mislabeled this role to begin with. The person who “owns” the product (i.e. the business, a CEO, or in Mountain Goat’s definition some Marketing role) is more appropriately the person who has financially paid for and owns all legal rights to the software. I would wager that 99% of software projects are not consumed by the legal owner of the end product, but by a subordinate.

This leads me directly to my next point [that I find it ironic] the term Product Owner has become synonymous with the role of being the person who is responsible for the delivery of the product. In most cases, this is the true legal owner (or someone who is very accountable for the time and money spent).

So here is the big question: Product Owners are not responsible for the long-term care and usage of it, so why are they in charge of the delivery of it?

Contextually, it is absolutely no different than a father who test drove, purchased, and owns a car he bought for his child with only a small amount of verbal input. From a salesman perspective, I want to know what the father says, but as an engineer I want to know what the child wants! Adding salt to the wound, we now have processes centered around a social antipattern which are appropriately mislabeled.

In all reality, I know we will never be able to break the habit of the people accountable for the project budget wanting to be involved in the process. They need to receive a false sense of assurance that the software will delivered and they will get what they paid for. However, I do believe by correctly labeling the most active role to something more representative of the person we want to engage in a meaningful client relationship with, we can reverse the trend of placing so much emphasis on the “when” and more on the “what” and for “who”.