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.

Similar Posts:

• Refinance Your Technical Debt Just Like Your Mortgage
• Why Are You Asking Me This Question?
• The Broken Iron Triangle Is Broken
• Rearranging Furniture for an Unfocused Client
• The Dangers of Git ‘R Done

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

All to often I hear this phrase during an estimation meeting:

I think it’s about 20 hours, but let’s say 24 to fudge it a little…

Estimating this way brings a false sense of security that you have allotted more time than needed. Probably more correct, that small amount of extra hours placed on the estimation only shortened the gap between an optimistic timeline and reality. So why is this a poor estimation?

Single Point Estimations Stink

I have said this many times, and I will say it again – single point estimations stink. Sure you can tell the difference between a 1 hour task and a 2 hour task, but can you really tell the difference between a 20 hour task and a 24 hour task. Probably not.

Solution: Learn to break down your estimations in smaller pieces. For larger tasks, ensure you are estimating in ranges or with a process that implicitly includes a fudge factor such as Planning Poker (Point Estimation).

Fudge Factor Is Not Based On Fact

In the example above, where did the extra 4 hours come from? The majority of the time it is a gut feeling, but why can’t it be fact?

Solution: Keep track of your estimations and actual development time – you can’t fix what you can’t measure. Next, measure and understand your estimation variances. This will give you 2 action plans:

1. You can correctly pad your estimates with actual mathematical variance to improve estimation confidence.
2. You can now understand and measure estimation improvement (for example, 20% variance improved to 17% variance).

Presents 100% Confidence

Even with all your body language, chair shifting, ummming, and pre-warnings; most managers will take exactly what you say for gospel. That is because when you estimate in this fashion, you are presenting the posture to your manager, “I’m the expert and I know it will be right around 20 hours”.

Solution: Learn how to present your non-confidence in a manner that does not put the project responsibility on your shoulders. Learn to speak in estimation confidence levels that allows you to ask your manager, “I am 90% confident I can get it done in 200 hours, but if I say 100 hours I am only 30% confident. How much risk are YOU willing to take on?”

Learning to sandbag your estimates is not about tossing a couple of extra hours on a task. It is about truly understanding the things you can know, and articulating risk and concern about the things you can’t know. This way you and your manager can pad those estimations together and on the same page.

Similar Posts:

• Never Be Responsible For Your Estimations Again
• Mr. Yuk Says Project Roadmaps Are Poisonous
• Suck At Estimation? Use The 2 Day Crutch Method.
• Do Managers Prey on Developer Pride?
• Comfort vs. Confidence – A Thin Line Between Apathy and Assurance

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Perhaps the biggest problem area for the software industry is the inability to accurately estimate work. However, this is only because people allow themselves to give out wild ass guesses on very coarse grained and undefined pieces of work.

For example, with fairly high confidence we can tell the difference between a 1 hour task and a 2 hour task, but it is improbable that someone can tell you the difference between a 34 hour task and a 35 hour task. Here in lies the answer, better estimation comes from estimating smaller bits of work.

Regardless if you call them features or user stories, your chunks of work need to be broken down into eatable bite-sized pieces (smaller yields more accuracy). So what is small enough? The answer is the 2 Day Crutch Method.

There is only one rule of the 2 Day Crutch Method – break down features/stories whose estimations are bigger than 2 days.

This single rule causes you to practice many good habits:

• Forces further exploration/discussion of unknown or large features
• Insists task break downs of lengthy known features
• Teaches the wisdom of knowing when something is really unknown

Now I am sure that people are asking why it is called the “crutch” method. Simply put, this practice is meant to only be a crutch to aid you in your journey to being a better estimator. Depending on your team, you may need to run this process for a year or perhaps a mere month or two. I am not going to be as dogmatic as to suggest that all features can be broken down into parts that will take less than 2 days to accomplish; however, I can say that most features do fit into the 2 day method.

Whether to get some brush up practice or to fix some real estimation problems, every team should occasionally challenge themselves with the 2 day estimation method. I promise you will see benefits in 2 days or less or your money back guaranteed!

Update: If you are doing User Stories, this method really helps for you to frame in the differences between Themes and User Stories. Most people understand Epics fairly easily, but get a little hung up on the granularity differences between Themes and Stories. In short, this method might be able to flush out those differences; fits in 2 days = Story, bigger than 2 days = Theme.

Similar Posts:

• How To INVEST In Your User Stories
• How To Correctly Sandbag Your Estimates
• The Easy Way to Writing Good User Stories
• Mr. Yuk Says Project Roadmaps Are Poisonous
• Tool Review: SlickEdit Tools

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Almost all software teams run some sort of software process whether it’s Scrum, Agile, Waterfall, or Scumerfall. Each and every one of these processes includes a window of time (for example, Scrum uses the concepts of 1 week iterations).

A recent comment made me about fall out of my chair. Paraphrasing:

One of the best reasons [from a management perspective] to adopt Scrum is the fact that iterations are “accountable commitments” to what the team could accomplish in a week…

Screeeech. No. Estimations are not meant to be used as accountability rulers. They are meant for visibility.

But don’t we need estimations so that we can make business decisions and commitments; therefor aren’t they for accountability? Although, the last sentence would suggest a maybe…still a resounding – no.

Let me make something perfectly clear to everyone reading – nobody should ever be held accountable for estimations. Estimations are naturally shitty, wrong, and optimistic, so why even continue to do them? Because we need the business visibility of how long software is going to take, and as a measurement stick if we can continue the current game plan or react to a different (less optimistic) reality.

I want to repeat that – it gives early visibility to know that our business schedules will work, or early warning they will not so we can react accordingly.

So you are a team manager a few weeks away from a deadline that appears is not going to be meet. What are you to do? Here are a few things to avoid:

• Ignore the early warning signs and pray for a miracle
• Guilt or force your team into working overtime
• Don’t start preparing upper-management that timelines may slip
• Post Deadline: Chew out your team for not making the deadline

Alright, what should you do? Here are a few ideas:

• Realign management strategy
• Bribe the team into working late with food, bonuses, or tech gizmos
• Post Deadline: Aid your team in providing better estimations

Being middle management should be one of the hardest jobs. I have equated software management to being an Army Sergeant, and how you handle the tough decisions of this scenario really draw parallel. You don’t push hard against the officers – shit rolls down hill onto your troops. You don’t rally the troops to accomplish the mission – the overall strategy goes to hell. Either way, you are not a popular person but that is because you make all the hard decisions that everyone else skirts around.

Similar Posts:

• Quit Sweeping Known Uncertainity Under The Rug
• The Officers vs. Sergeants Syndrome
• The Blame Game: How Necessary Is Traceability?
• Mr. Yuk Says Project Roadmaps Are Poisonous
• Never Be Responsible For Your Estimations Again

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

This is a continuation of the post – Mr. Yuk Says Project Roadmaps Are Poisonous

As the saying goes, the first step in fighting addiction is admitting you have a problem. Unfortunately, it is human nature for us to rationalize away our problems. Problems which then create ticking time bombs in fragile card houses.

One of the biggest plagues in the management of software is never admitting that there is uncertainty in projects. Instead we quantify these unknowns in buffered estimations and optimistic risk analysis spreadsheets. This is the equivalent of sweeping known uncertainty under the rug.

What is known uncertainty? Like I have said before – we don’t know what we don’t know; however, I would debate that we do know roughly how uncertain we feel about a particular thing. For example, how many times have you said something like:

I am 100% confident that is correct, but I am only 80% sure that other one is right.

I am not going to go into depth today about how horribly wrong the above statement is, but it does prove my point that we have uncertainties that we should leverage as variables in management. But how do we do this?

Explore The Domain Early

The first step has historically always been the hardest for me to convince management of, and that is being allowed to have early in-depth conversations with the client about the domain problem.

The de facto retort of management when asked to understand more about the problem upfront is something like this:

We don’t want to waste time or money on a client or project we don’t know if we have yet. Let’s just figure out how much it is going to cost so we can give them a bid and we will figure out the rest later.

Do I even have to go into depth why this is stupid and counter intuitive? How can we even be remotely close in our estimations if we have no context of what we are building. We obviously are slow learners because numbers still fly out of our mouths when given an elevator pitch’s worth of information.

Estimate Early And With Uncertainity

Along with exploring and prototyping the domain early, we also need to estimate very early on. More important than just estimating, we need to estimate with uncertainty by doing the following:

• Always estimate in ranges – never give a single point estimation
• Use the Cone of Uncertainty to widen or narrow your ranges
• Bait and switch management so you don’t become responsible of horrible estimations based on no information.

I explain most of this information in an old post – Never Be Responsible For Your Estimations Again. But in short, here is the tactic:

1. Estimate in ranges or using something like the Fibonacci sequence method found in Planning Poker
2. Place a % of certainty that you can accomplish these goals given the time and budget, then divide that % by 2 (because you are being optimistic)
3. Pitch it to management – “I am 35% confident we can meet those timelines, so either that is a risk you know upfront or we have to realign expectations.”

Use Agile / Scrum For In-Transit Management

Not to kick the dead horse, but if you aren’t using Scrum or some other Agile development process you aren’t working as people are meant to work. You are working like robots, or factories, or some theoretical imaginary land that some professor made up, but you aren’t working in an environment where real life is a vacuum. Features change, people get sick, and money runs tight, manage all these with Agile approaches.

I am not going to preach to the choir, and those in the pews that still don’t practice these techniques are dirty dirty sinners. Same on you. ;)

Flaunt Your Weaknesses, Then Crush Them

Because people don’t psychologically like being uncertain it will be hard to receive initial buy in – this really is an act of humbleness and humility.

Ask these people if they are personalities who would rather be comfortable but feed lies, or know the uncomfortable truth. Only people in the latter group should be in business…well, at least a successful business.

In summary, if you can get your team to a state of practicing flaunting their uncertainty, you will eventually grow an environment where people will speed to extinguish uncertainty. Therefore, you will grow an environment that continually overcomes their greatest weakness next in the queue.

Give it a whirl, be humble. Give your poor rug a break and show your team how damn uncertain you are about things. I do and that is why I am the putz with the successful projects.

Similar Posts:

• Estimation Is Not For Accountability (It’s For Visibility)
• Never Be Responsible For Your Estimations Again
• Do Managers Prey on Developer Pride?
• How To Correctly Sandbag Your Estimates
• Mr. Yuk Says Project Roadmaps Are Poisonous

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

For some time now, I have thought that high-level project roadmaps (Gantt charts in particular) are one of the most worthless documents that a software project team can produce. I shouldn’t be so hard on them, but there are an uncountable number of reasons why I despise these charts.

Quantifies Unknowns

As the old saying goes:

You don’t know what you don’t know.

Most roadmap documents are created with very little research or prototyping done before hand. As a result roadmaps are left with very large holes in them. To add injury to insult, some roadmaps are even then “buffered” to account for these unknowns.

Regardless, these timelines are then declared “complete” as every action (that they knew about) was covered, and some arbitrary number is placed on the things that they didn’t know (which is always the lion’s share of the project).

Promotes Optimistic Estimations

The main reasoning behind estimation methods such as point estimation is that we have a hard time distinguishing the difference of long running tasks. Sure we can accurately estimate the difference between a 1 hour task and a 2 hour task, but can we really estimate the difference between a 23 hour and a 24 hour task? No, not in the least.

Roadmaps promote these optimistic estimations at an epic scale, attempting to reason the difference between a 3 month task and a 4 month task. Most commonly this is also done without ever breaking each of these course task blocks up into actionable tasks that can be completed in less than a day, thus getting back to quantifying the unknowns.

If the development team is very unlucky, the development team will be forced to estimate each of these tasks in an impromptu meeting lead by the manager creating this document. This is very unfortunate because it now allows the developers to become the estimation scapegoat.

Instantly Degrades

Progress is not linear, unfortunately, all roadmaps are designed to show that software is built in a linear factory-like manner. Some might say that it is the medium of which the message is delivered; however, I believe it doesn’t matter if the document is written on toilet paper – the core philosophy is flawed.

The instant the Step 1 – Step 2 – Step 3 plan deviates into Step 3 – Step 1.2 – Step XYZ, the document instantly degrades and needs updating. This is simply not how software is built, or how its’ progress should be kept.

Promotes Urgency

Although I do agree with the fact that we all need some level of healthy stress; however, because of inaccurate timelines and optimistic estimations we create slipping deadlines and broken promises.

As a result, we create poisonous environments of urgency. I believe it was Steve McConnell in Software Estimation who said that a developer under strict deadlines will actually produce less due to high levels of stress, which in turn, will put more bugs into the system – quicksand effect if you will.

So what can we do to combat Product Roadmaps? I am just getting going…be sure to look for Part 2 on Friday….

Similar Posts:

• How To Correctly Sandbag Your Estimates
• Suck At Estimation? Use The 2 Day Crutch Method.
• Quit Sweeping Known Uncertainity Under The Rug
• Whiteboard Wednesday: Using Your Bug Tracker For Estimation Tracking
• Estimation Is Not For Accountability (It’s For Visibility)

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

As I mentioned in the video above, my team does their bug tracking with Jira, and because it is flexible enough to add in custom user defined fields, I added the Points drop down list. After that, I simply created some reports using their pre-canned charts and wam-bam I have my burn up charts.

Just a few additional hints when attempting to leverage your issue tracker to help with estimation analysis:

• Make sure you keep 1:1 relationships with issues/estimations
• Split issues into weekly iterations (or sprint)
• If you cant create dashboards, learn how to export the data so you can still use it
• Track everything – completion rate, completion velocity, growth velocity, and project completion date

Similar Posts:

• Mr. Yuk Says Project Roadmaps Are Poisonous
• Never Be Responsible For Your Estimations Again
• How To Correctly Sandbag Your Estimates
• Do Managers Prey on Developer Pride?
• The Blame Game: How Necessary Is Traceability?

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

This Whiteboard Wednesday talks about the benefits of doing your software estimation in points rather than in time. As I explain in the video, there is a great game called – Planning Poker. Here are some links on Planning Poker:

• Let’s Play Planning Poker! – Jeff did a great job of explaining this in detail (very similar to this whiteboard)
• Crisp.se sells Planning Poker decks
• You can also play Planning Poker online

Similar Posts:

• Best of Codesqueeze 2008
• Concentrated Codesqueeze: February 2008
• Concentrated Codesqueeze: January 2008
• Whiteboard Wednesday: Effective Communication Channels
• Response To Effective Communication Channels

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Wild estimations are a common job hazard that every developer encounters. Developers are asked to give exact estimations based on few requirements, little to no domain experience, and in a very short time. Whatever number the developer spits out of their mouth becomes written project law. How fair is that? It gets worse than unquantified estimations…

The real problem is that you, the developer, now have effectively taken all responsibility for the project budget. By giving a single point estimation the project manager is no longer in control of the situation. All responsibility of the success and failure of that project is riding on your ability to wildly guess. In other words, you have made a managerial project scapegoat of yourself.

So what can the common developer do? The answer is simple – learn to push the decision making back onto the manager. By forcing management back into making the “important” decisions, you are giving management the authority to be responsible for the project again.

For example, let’s pretend you are a consultant working for $100/hr and get asked to do an estimation for a new custom solution.

Old Way – You throw out a complete guesstimate of $50,000 (500 hours). You are now a budget scapegoat.

New Way – You think it will be about 500 hours, but you present it with this wording:

Boy, this is really hard to say. I apologize for the range, but somewhere between 500 – 1250 hours. I can 100% guarantee that 1250 hours is plenty of time, but there is only a 10% chance that the project will come in on budget with a shoestring budget of 500 hours. How many hours would YOU like to dedicate to this project.

This tactic puts the act of estimating back into reality. An estimation range is much more forgiving than a single point estimation, and it gives multiple options for your manager to consider.

Your manager might have many business reasons for wanting to reduce your estimation. Putting a probability of success associated with each dollar amount makes them answer the tough questions they may have been dodging:

• Is the client most concerned about dollars or success?
• Is the business willing to take a 50% gamble on project failure to get this bid?
• If I gamble on a 10% success rate – what will happen to ME?!?!

The equation for this is very simple linear equation. If you feel your estimation ranges could use modification, I would recommend starting large and tightening using a model like the cone of uncertainty:

Being a responsible estimator is important, but being responsible for your estimates is not. You have to build the solution, you should not also have to manage the budget. Put your estimations in ranges with probabilities and let your manager manage the costs and risks of the project.


Similar Posts:

• How To Correctly Sandbag Your Estimates
• Do Managers Prey on Developer Pride?
• Open Source for Relaxation?
• Why False Starts Hurt Your Project
• Quit Sweeping Known Uncertainity Under The Rug

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.