Effort Estimations

Software Development Effort Estimation, Part I

When we are talking about being a professional, one of the key concepts is effort estimation[1]. This is also one of the most challenging parts of software development activities. Everybody, the customers, project managers, technical leaders and so on are asking about an estimation of how much time do you think that the dealing with a certain task will take. And, in almost all the cases, the estimation will be wrong because we are, usually, too optimistic. Also, under the pressure of providing the estimation now, it’s easy to forget that the amount of time is not just the one that is required to implement something, but is a lot of other tasks or supporting activities that should be taken into consideration, too. We’ll discuss these in the following sections. But now, as advice, don’t hurry up with the estimation. Ask for time to evaluate the total amount of work that will be required in order to implement what it is requested from you or from your team, and never provide an immediate answer. Be aware that the estimation that you’ll provide will be understood as a commitment and you, as a professional, must be sure about what you’re making a strong commitment to.

Another important aspect is related to the estimation provided for you (or your team) by the others. Usually, the managers are tempted to do this on your behold, starting from the presumption that they are managing a budget and they know better than you how to get profit. Don’t be afraid to raise the hand if that estimation is not suitable for you, but be very well prepared to argue against it with solid arguments. If this will not change the management decision, then you’ll have to clearly state that you cannot make any commitment regarding the delivery. But if you accept the management decision that was taken without your involvement, you’re lost. It will take a lot of effort from your side, extra hours, weekends and so on. You’ll get over-burned and your private life will be a disaster. And, the worst thing, the quality of your work will suffer and is very unlikely that you’ll be able to deliver on time.
However, there is another possible solution to this. Look at the following picture:

Project Management Triangle

Project Management Triangle

As the legend is stating, this is called the Project Management Triangle[2]. What is specific to this tool is the fact that Quality should be the main concern – as a professional, there is no way to make any compromise regarding quality. From the perspective of the other dimensions, we can have, simultaneously, just two of them fixed. In this regard, if we have:

  • Fixed time and cost, then the scope should be adjusted (number of the features provided to the customer as part of the project). The adjustment of the scope should be done based on the priorities of different features, but this is another topic
  • Fixed time and scope, then the price should be adjusted
  • Fixed cost and scope, then the time should be adjusted

So, you can use this tool in order to discuss with the management or with the customer in order to find an approach that is reasonable also for you. Just after that, you can make a strong commitment regarding the project deliverables.
The case when the Sales is making deals to deliver in 2 days is not covered here 🙂

Getting back to estimation, I want to provide you some tools, well known in the industry, with some custom extensions.

Before getting to some formula and graphs, I have some tips:

  • Decompose the problem into small tasks, and estimate. If the estimation is bigger than a reasonable amount, consider decomposing these tasks even more. Depending on the selected development methodology, this reasonable amount can be around 4 ideal hours (classical approach), or a medium size – about 4 story points – where a story point is a relative size measurement unit (agile approach)[6]. There is no equivalence between story points and ideal hours; I just mentioned them as a reference regarding the amount of effort required to accomplish a task. I’ll go into more details in a future post regarding agile methodologies.
  • Evaluate the possible risks. As the risks are higher, as much the estimation should be increased, or the project should be even canceled. Address this to the customer or with the management. Some risks can be considered to be: team member unavailability, lack of knowledge regarding a particular technology, the unexpected behavior of the application because of impossibility to have a test environment, a poor or erroneous specification of the requirements, etc. A good tool for this is the one provided by PRINCE2 project management method[3,4]. Shortly, it makes easy to figure it out the impact of a given risk over of its probability as can be seen below:
Risk Ranking

Risk Ranking

  • Don’t forget to take into consideration the dependencies between tasks, the possible delays in getting the requested information regarding certain task implementation and other unexpected delays. You can plan 10% to 30% on this, maybe more, depending on the project risks
  • Use the previously gathered knowledge regarding similar tasks duration

Cone of uncertainty[5]
As you probably already know, it is difficult to get accuracy in estimation.  Why is this happening? Well, there are many reasons, but mainly because of what I have presented above, and the lack of taking into consideration of all the required activities for dealing with a certain task. One of the main tools that can help to have a structured way of making estimations is what is called the cone of uncertainty. This is actually a pattern that is helping to reduce guessing in estimation by providing a range of thresholds, statistically determined, for different stages of a project.

Phases:

  • Initial Product Definition: 0.25x – 4x
  • Approved Product Definition: 0.5x – 2x
  • Requirements Specification: 0.67x – 1.5x
  • Product Design Specification: 0.8x – 1.25x
  • Software Complete: 1x

I’ll use this opportunity to introduce another concept: the estimations should be always a range; nobody can say that an activity will take 47 minutes to be done, but can say that will take between half an hour and one hour. In this regard, the cone of uncertainty comes as a very suitable tool for an estimation. The horizontal axis reflects, actually, the knowledge improvement about what it should be done in a project. As your knowledge about what should be done is improving, as better will be the estimation in the terms of the range wideness.

In order to understand better, it is required to provide an example: think to a quite specific task that you’re required to provide an estimation of how much time will take to be implemented. If you have no, or very little, knowledge about the business problem that you’ll have to solve, or about a specific technology that should be used, it is, naturally, extremely hard to provide an estimation. If the original thought is, for example, that will be required to spend 2 days, it is very likely that it can take between 4 hours and 64 hours to implement it. As the project is progressing and your knowledge is improving, if you’re requested again to estimate the time, most likely, the range wideness will be lower, for example between 11 hours and 20 hours.

Of course, it is not enough just to apply this tool in order to get an estimation as accurate as possible (but within a range, remember). Because of the dependencies and the risks mentioned above, it is required to take more details into account.

In the next part, I’ll present some of these activities related to a software development task. However, please, feel free to adjust this list and the estimated percentages according to your own needs and experience.

 

References:

  1. The Clean Coder: A Code of Conduct for Professional Programmers
  2. Project Management Triangle
  3. Risk Register (PRINCE2)
  4. PRINCE2 Study Guide
  5. Software Cost Estimation with Cocomo II
  6. What Are Story Points?

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.