Software Project Estimation Part 5: Count

This post is part of my series on Software Project Estimation: 

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.

6 thoughts on “Software Project Estimation Part 5: Count

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s