The Blog of Matt Peters

• Part 1: Introduction
• Part 2: The Process of Software Development
• Part 3: The Cone of Uncertainty
• Part 4: Expert Judgement
• Part 5: Count

Today’s I’d like to dive into another software estimation methodology.  I’ll refer to this only simply as Counting.  Using this technique you find something to count and base your estimation upon that count.

So, the first step is to find something to count.  What should this be?  Here are some examples of things you could count:

1. Requirements
2. User Screens or Web Pages
3. Function Points
4. Use Cases or User Stories
5. Database Tables

Whatever you decide to count needs to satisfy a couple requirements:

1. It must be available early on in the project (preferably at the Requirements stage, not the Technical Design one).
2. It should be highly correlated to the actual effort invovled to execute the project.
3. You should have historical data available telling you how long it will take for you to construct it.

Let’s say, for instance, you are creating a web site and you decide that you are going to count the web pages to try to get an estimate for the project.  Looking at your historical data, you determine that the web pages you have created have fallen into three categories: 1. Simple (static text), 2. Avarage (simple data input / retrieve), and 3. Complex (more difficult data input or retrieve).  Your historical data reveals the following average construction times for these web pages:

1. Simple: 4 hours
2. Average: 16 hours
3. Complex: 40 hours

To come up with your estimat, you simply have to inventory the web pages you are going to create as part of this project, and assign them to those categories.  Using these counts, you can come up with the total amount of time for coding and unit testing.  Based on your project breakdown percentages you can then derive the time for the other phases and get your complete estimate for the project.

This technique can be further refined by breaking your components into those that are being Created or just Modified and getting afterage times for Simple, Average, and Complex components in those two categories.

An additional factor can be added to this estimate to take into account the skill level of the developer doing the construction.  Say, for instance, you estimate what it would take for an Average developer to do the coding.  From your historical data it my be clear that it takes a Novice 50% longer to do the construction and an Expert only 3/4 the time.  So, you could break your components down by the skill level of the person doing the development, muliply the Novice ones by 1.5 and the Expert by 0.75.

So far I have been describing this estimation technique in a way that relies heavily on having your own historical data available.  But, what if you do not have this information?  In that case I would recommend using an industry standard metric to count that has associated industry historical data avaiable.  Function Point Analysis is a perfect example of a very refined Counting technique.  I will explore this in detail in a later post.

• Part 1: Introduction
• Part 2: The Process of Software Development
• Part 3: The Cone of Uncertainty
• Part 4: Expert Judgement
• Part 5: Count

Expert Judgement is the first estimation technique I’m going to explore. Normally when a team is trying to come up with an estimate for a project, they do something very similar. Someone will sit down with a list of features and guess how long it will take for the team to do the development. Most of the time these estimates vary widely from actuality. But, there are things that can be done to make them more accurate. 

The first step is to be carefull when picking your expert to do the estimate. The export should satisfy the following qualifications:

1. They must be an expert in the problem domain. That is, they should understand the business and technical side of the problem.
2. They must be an expert in the technical domain. They should have a deep understand of the systems that this project will integrate with. They should have been invovled with several projects in the past in this domain.
3. They must be an expert in the tools and technologies being used in the construction of the project.

The next step is to not just take a single estimate from the expert for each feature. The export should give the following estimates:

1. Best Case: If everything goes just right, how quickly could the feature be built.
2. Worst Case: Assuming everything goes wrong and road blocks are encountered at every turn, how long with the feature take.
3. Most Likely Case: Based on the previous two estimates and his past experience, how long does the expert really think the feature will take.

Based on these three numbers, an industry-standard “Program Evaluation Review Technique” (PERT) can be used to calculate the Expected Case. PERT does this by putting a different weight on each of the three numbers with the following formula:

• Expected Case = (Best Case + (3 x Most Likely Case) + (2 x Worst Case)) / 6

By adding up the Expected Case for each feature, the total amount of time for coding and unit testing can be determined. The percentages assigned to each phase of the project can then be used to determine how long the entire project will take.

Using this technique, you are still dependent on one person’s opinion. Often times you can’t find a single person that meets all of the qualifications of the expert that you need to do the estimate. This technique can be improved by having several experts independently use the above technique to come up with their own estimates. Then, have all of the experts come together an discuss each of their estimates. By talking about the reasons for the differences, the experts should work together to come up with a consensus estimate. The numbers from this consensus are then applied to the above formulas to determine an estimate for the project.

Expert and Group Expert Judgement are great methodologies to use early on in the project when the required features are known, but little about exactly how the solution will be constructed.

In the next post, I’ll investigate another estimation technique that works early on but does not require experts in the domain to do the estimate.

• Part 1: Introduction
• Part 2: The Process of Software Development
• Part 3: The Cone of Uncertainty
• Part 4: Expert Judgement
• Part 5: Count

The Cone of Uncertainty is another point that is very important to understand when trying to come up with an estimate for the execution of a software development project.  I originally planned on going pretty deep into the topic, but I found an article online that does a better job at it.  So, I’m going to cover it at a high level and then point you to that other article.

Early on in the project, very little is known about the detailed functional requirements and exactly how the solution is going to be constructed. Because of this lack of information, you need to understand that your estimate could be off by a certain percentage. As the project progresses, more is known about it so estimates get more accurate.

The following shows the amount of variance in estimates in different phases of the project:

1. Scoping: -50% to +100%
2. Requirements: 20% -33% to +50%
3. Design: 20% to +25%

There are, however, techniques that can be utilized while putting together your esitimate that can help to make it more accourate.  In the following posts I’ll be addressing several different estimation techniques.  Each have their pluses and minues and are more appropriate at different phases of the project.

A very good article on the Cone of Uncertainty can be found on the Construx website here.

Many people have been emailing me asking about the estimation techniques that I am going to cover.  I’ll begin diving into those in the next post.  The first one will be ‘Expert Judgement’.

• Part 1: Introduction
• Part 2: The Process of Software Development
• Part 3: The Cone of Uncertainty
• Part 4: Expert Judgement
• Part 5: Count

To come up with an estimate for completing a software development project, first you need to really understand the process of completing a project.  This concept should be obvious, but too many times it is not.  People who have only been involved in the coding piece of a project sometimes do not understand all of the other steps that go into a project.  They will come up with an estimate for completing the coding, and not communicate to their management that their estimate did not include the other pieces.  This will lead to an estimate that is very small.

Typically a software development project will have six phases.  You may have  a couple more, or you may call these something a little different, but typically these are the main six phases:

1. Scoping: The purpose of this phase is to put a high level boundary around the purpose of the project.  What is the customer asking for?  It’s a good idea to make a high level list of business goals, what features are in scope, and what is out of scope.
2. Requirements: The purpose of this phase is to completely flesh out exactly what the customer is wanting.  The result of this phase will be a very detailed requirements document with the following sections: Business Requirements, Functional Requirements, Nonfunctional Requirements, Dependencies, Assumptions, Out of Scope.
3. Design: You have now defined exactly what the customer wants.  The purpose of this phase is to detail exactly how the solution to the problem is going to be constructed.  The result will be a very detailed Technical Specification that will be a blueprint for developing the software.  My goal here is to make it so detailed that someone only moderately familiar with the technology and problem domain could pick up the document and complete the project.  Its always easiest to figure out the difficult parts of the project there before a single line of code has been written.
4. Development: This is the phase where the actual coding is being done.  If the requirements and design were solid, then it should be a very smooth process for the development team to complete the construction.
5. Testing: This is the phase where the test team takes the requirements and tests every aspect of the application to ensure that every requirement is met by the application.  Unit Testing should occur in the Development phase.  The testing that should occur here are: Functional Testing, Integration Testing, Performance and Load Testing, and User Acceptance Testing.
6. Deployment:  This the phase where the application is actually rolled out and made available to the end users.

The above list is very high level.  But, from it you can see that there are a lot of different tasks and phases that go into the process of completing a software development project.  An estimate put together should include all of these.

One good way to make sure you allocate enough time to each of the phases is to keep records of how you do at previous projects.  If this is your first project, lean on some industry averages.  But, from then on out, keep records on your execution time and adjust future estimates accordingly.

The following outlines what I’m talking about.  Let’s say your project delivery rate normally falls out as follows:

1. Scoping: 5%
2. Requirements: 20%
3. Design: 20%
4. Development: 30%
5. Testing: 20%
6. Deployment: 5%

Having these statistics on hand is very powerful.  If you are completing a project very similar than several you have done in the past and you have these numbers, you can estimate just the construction of the project and from that extrapolate how much time the other phases will take.

So, while putting together a project estimate, the first key is to keep in mind the entire process of software development.  If you do not do this, you will miss pieces and your estimate will be too small.  The next key is to keep detailed data on your completed projects so you can use those numbers to aide in estimating future projects.

In the next post, I will talk about the Cone of Uncertainty, and how the accuracy of your estimate varies based on when you make the estimate.

• Part 1: Introduction
• Part 2: The Process of Software Development
• Part 3: The Cone of Uncertainty
• Part 4: Expert Judgement
• Part 5: Count

One of the biggest challenges I have run into in the course of my career is coming up with good estimates for completing software projects. So many times I am overly optimistic when coming up with an estimate, or I completely forget about certain pieces or steps, and the resulting estimate is insufficient.

When the estimate for a project is too small, one or more of the following will always happen:

1. Requirements will be either intentionally or unintentially left out of the finished product.
2. The team will rush through the construction of the project. This rushing will cause the quality of what is being developed to suffer.
3. Time will be stole from later phases of the project to allow more time during construction. Most of the time this time will be taken from the Testing phase.
4. The project  will be completed, but it will be delivered late.

In all of these cases, the project should be considered a failure. The customer will not be happy with the product they have received.

An estimate for a project that is too large can also be a problem.  The customer may reject the project because they don’t think they can afford it, or too much budget may get allocated to this project causing other projects to not be funded.  Another danger is that Parkinson’s Law may come into play.  This law states that the amount of time required to complete a task will always expand to fill the amount of time available for it’s completion. So people begin working slower on this project when they could be completing it and beginning to work on other things.

All of this can be avoided by establishing good estimates early on in the project.  But how can you come up with a good estimate to execute the project? There are a wide variety of methodologies for doing this, some of which are more accurate than others, and some can be applied earlier in the project than others.

This series of posts will address different aspects of project estimation and dive into several techniques.

The following posts will deal exclusively with the software development projects.  That’s where my experience lies.  But, I’m sure there are concepts and principles here that apply to the completion of any type of project.