Why Is Software Estimation Always In the Backseat?

I don't understand why software estimation doesn't take a more prominent role in software development.

Virtually everyone who's livelihood is related to software development has experienced projects where team members have worked a zillion hours, the project went over budget, had features ripped out to meet a date, was delivered with poor quality, etc.

Here are some data to provide context into our experiences in relation to the software development space as a whole (thanks again to Steve McConnell's book "Software Estimation: Demystifying the Black Art"):

• Many studies have concluded results that state 25% of projects will be canceled, 25% will be on time and within budget, and 50% will be late and/or over budget.
• A project with 10,000 function points, which is a mid-sized project, has a 1% chance that it will be delivered early and a 20% chance that it will be canceled. As the number of function points goes up so does the failure rate.
  
• On average, a late project is 120% late and an over budget project is 100% over budget.
  

It is likely that the percentages for late/over-budget is only a piece of the picture and the actual experience is much worse. When a project is 120% late and/or 100% over budget, there is severe urgency to deliver. When that occurs functionality is often stripped out of the original scope and teams are forced into a death march to get the project done. Most teams do not pay overtime so whether a developer works 8 hours or 18 hours, the effect on the budget is the same. As a result, the overage stats do not reflect that what is delivered is likely less than what was scoped and the hours applied are far more than the budget overrun indicates. It is also reasonable to assume that in that environment design time suffers causing a more difficult application to maintain, extend, and scale.

The moral of the story is that the our industry is dysfunctionally addicted to under estimating our projects! One major reason for this, believe it or not, is expert judgment. There are a lot of smart people with loads of experience in our industry and many will estimate tasks, and thus projects, based on gut instinct instead of quantifiable data. This is by far the least reliable estimation technique.

In the next article, I'll provide a few methodologies that you can use that are fairly easy to implement and will increase your likelihood of success.

Software Estimation v.1

I recommend to everyone who is involved in any way with software development to read the book "Software Estimation: Demystifying the Black Art" by Steve McConnell. I laughed, I cried, it changed my life. Well maybe not the first two, but it did change the professional side of my life.

There's so much to software estimation that one article cannot do it justice; especially if the objective of the article is to keep it short and concise. This first of probably many blog entries on software estimation will be dedicated to distinguishing between an estimate and a commitment. This is a vital point because the two are often used interchangeably.

Estimating is an unbiased analytical process. With regards to software development, the objective is to approximate the amount of time and/or cost to develop software to solve a problem or satisfy a specific need. As an approximation, an estimate should be communicated as a range, e.g. "it is likely that this project will be delivered in 3-5 weeks".

A commitment is much more definitive. It is an agreement to deliver specific functionality on a specific date for a specific cost, e.g. "the project will be delivered in 6 weeks."

Related to a commitment is a target. A target is a biased process based on the goals of the business, e.g. "We need this software delivered by June 15 to demo at the premier industry convention!".

In my experience, more often than not estimates are expressed as commitments which are influenced by the business driven target.

Communicating estimates as a single point number vs as a range is misleading (in most cases unintentionally). Every software development effort is, in actuality, an invention and an invention cannot be guaranteed to be completed on a certain day for a certain cost. As we all know, our estimates are not 100% accurate. However, if we communicate estimates as a single point number we are implying 100% accuracy.

Developing high/low cost estimates is fairly common and as you can probably guess I recommend communicating both to your customers. There are many techniques to quantify, thus making credible, high/low estimates. Although estimation by intuition is one estimation technique - and is probably the most frequently used - it is the least reliable. I'll be writing about some of many techniques I garnered from Steve McConnell's book in future blog entries.

On the other hand, dates are rarely communicated as high/low estimates. Typically they are communicated as commitments (single point date) which often result in very long days for developers, negotiating with the client to deliver at a later date, removing features from scope, providing a poor quality product, or a combination of some or all of those. I have a question for you, when was the last time you presented your delivery dates as probabilities, e.g. "there is a 25% probability of us delivering the software in 11 weeks and a 98% probability that we'll deliver it in 15 weeks."? The techniques for quantifying those probability statements will come in later articles too.

I'm interested in hearing about your issues/resolutions to software estimation problems.

Creating and Maintaining a Sense of Urgency

A consistent sense of urgency is one of the separators of great teams from all of the others. Urgency promotes teamwork, focus, efficiency, collaboration, pragmatism, vision, and all the other important characteristics of a highly productive team and project.

I’ve been on projects where the management team wanted desperately for our team to have a sense of urgency but was unable to create it – never mind maintain it. Assuming a project team is made up of talented people who enjoy what they do for a living then the reason for the lack of urgency falls on management’s inability to provide a conducive atmosphere to instill it.

Knowing the ingredients that creates a sense of urgency is the hard part. Actually creating urgency is simple. All it takes is a disciplined approach to process by management.

The key ingredient are:

• Short and tightly focused goals that roll into medium term goals which roll into longer term goals.
• Individual accountability.
• Visibility into the goals of the team and it’s individual members.
• Knowing the dependencies each member of the team has on one another.
• Everyone’s involvement with process improvement.

Every project already knows the long-term goal – deliver the product that is mutually agreed upon between the developers and customer.

Agile does a great job of providing the short and mid-term goals via the daily stand-up and sprints, respectively. At the beginning of the sprint, the development team provides a scope for the sprint, which is usually between 2 and 4 weeks at the end of which is a demo to show what was accomplished. What rolls into the sprints are the daily stand-ups. Each member of the team provides an update on what was accomplished yesterday, what’s planned for today, and any obstacles they have.

For as far back as I can remember, my father has always emphasized that “if you take care of the little things then the big things will take care of themselves.” The daily stand-up epitomizes this philosophy. If we strive to consistently accomplish our goals on a daily basis, then it’s reasonable to assume that we should accomplish the goals for the sprint. The same holds true for the relationship between the sprints and the project as a whole.

The tightly focused goals that revolved around the daily stand-ups and the sprints creates an environment where creating and maintaining a sense of urgency is built-in. The best part is that it is self-maintaining. It doesn’t require constant reminders and direction from management. The best processes are those that work on auto-pilot where a manager’s job is to nurture it, make sure the team stays disciplined to it, and looks for ways to improve it.

That begs the question – as a manager, how should my sense of urgency be created and maintained? That’s a blog for another day.

Test Driven Development (TDD) Tip

I'm a big fan of Test Driven Development (TDD). TDD is an Agile methodology where automated unit tests are developed before the feature is developed. By coding automated test before actually coding the feature, the developer is forced to think through how the feature should work. If you've ever developed manual test scenarios you know what I mean. Many questions come out of the wood works of one's mind when going through this process. Another advantage of TDD is that once the tests are developed the development mission become clear – code to the tests and once they all succeed you are done and ready to move on to the next item in the prioritized list of features.

However, TDD requires a bit of procedure built into it – especially with regards to Continuous Integration (CI) and deploying working code on a nightly basis. Both processes are vital to the success of a project. I encourage my team to check in working code daily; ideally multiple times per day. With each check-in the CI server builds the project(s). If the project fails to compile or the unit tests fail then the build is considered failed. At that point, everyone on the team gets an email stating the failure and fixing it become the top priority. This also applies to the nightly deploy process which compiles the code, runs the tests, deploys the project into a distributed environment where automated QA scripts are run. A failure at any point results in top priority work for the team the next day.

In case you haven't already deduced the problem, if a feature takes a week to develop and all the automated tests are written up front, then the CI and deployment processes will be in failure mode most of the time. Thus, there are three solutions:

1. Iteratively develop the tests. For example, in a single day a developer may create a few classes, some properties, and a few methods. Tests should be written to accommodate what will be completed today not for the entire feature (this is my preference).
   
2. The developer could develop all the tests with an "ignore" flag so the tests don't run.
   
3. Use a methodology other than TDD.
   

I'm interested in your thoughts and alternative approaches that you've seen.