Estimating what effort is needed to develop an IT solution is not an easy act. The pitfalls are multiple and chances are that you end up guessing.
In this post I will outline how to estimate projects based on the use cases. In addition I will show you how you can use Use Case estimation to negotiate with suppliers.
Estimation can be hard. Luckily a number of techniques exist that can give you a qualified (gu)estimate.
Among others, the following popular estimation techniques for estimation IT development exist:
- Expert Judgment
- Lines of Code (LOC)
- Function Point Estimate
- Use Case Point Estimate
Expert Judgment is when you rely on an estimate based on talking to experts. Especially valid when talking to experts experienced in the domain and with experience from developing similar solutions. Investigations shows that expert judgments can be fairly valid and almost as valid as more proven methodologies. Challenges are for example how to find the right experts and to evaluate their expert level. Furthermore, it can be hard to convince others (for example your supplier) that your estimate is valid, because it is a subjective evaluation.
Lines of Code (LOC) are a technique that is fairly reliable in the hands of an experienced team. The technique says, as a rule of thumb, that it takes X number of hours to develop Y lines of code. For example 100 hours per 1000 lines of code. An disadvantage of this technique is that you need to know how many lines of code you are going to produce – this can be estimated for example for a 1:1 conversion of an existing system, but can be hard to determine in other situations. Another disadvantage is that you need an experienced team to do the estimation, and you need to compare with similar systems – the amount of lines of code in a from-scratch-developed-system might differ from a similar system developed using a industry-standard-solution or framework.
Function Point Estimate, is an estimation technique developed by IBM. It counts the elements of the functional requirements and based on that calculates an estimate. The technique is very usable and accurate. The advantage of this technique is that it is fact based and can be used by teams not experienced in the domain of the solution. Another advantage is that the cost of the project can be based on previous/other projects, and that other estimates using Function Point Estimation within your organization can be used as baselines. A description on how to use Function Point Estimation can be found here: https://en.wikipedia.org/wiki/Function_point
Use Case Point Estimation is a technique developed by the Swede Gustav Karner in 1993. The Use Case Point estimation technique is based on the same principles of Function Point estimation and has the same advantages. It has turned out that Use Case Point (UCP) estimation is as reliable as Function Point estimation.
An explanation of the content of Use Case Point Estimation can be found here: https://en.wikipedia.org/wiki/Use_Case_Points
“What makes this technique particular interesting is that by using UCP estimation you are able to produce a reliable estimate very early in the development cycle.”
“Actually even after sketching the use case model you are able to produce an estimate, apply it to the business case and consider stopping the project at this early stage, if the business case is not positive. That is a strong asset”
The figure below outlines where in the development cycle the various estimation techniques apply.
Lets have a look on a practical example on how to use the UCP estimation technique:
Lets say you’ve created the following simple use case model:
In this use case model there are seven use cases and two actors. The UCP technique involves ten calculation steps. Once learned they are easy to follow and your UCP estimate can be calculated within minutes.
The very first step is to calculate the Unadjusted Use Case Weight (UUCW). For calculating the UUCW you look at the number of use cases in your use case model, categorise them and calculate a UUCW score. The UUCW score will be used in other calculations as we move forward. So, we already know we have seven use cases. Those seven use cases needs to be categorised into Simple Use Cases, Average Use Cases, and Complex Use Cases.
In the table below you can see how each Use Case Category is described. Simple Use Cases are those having 1-3 transactions, and so on.
You just need to determine for each use case how many transactions they have in order to categorise them. To do so, you could have a look at the activity diagram and count the number of times the flow control switches from actor side to system side and vice versa.
For example in use case #1 the activity diagram could look like the one shown below (Notice: The activity diagram could as well be represented by a table showing the steps):
When looking at the activity diagram you can see that the control flow starts in the User side where the user is on a screen typing in some details. At some point in time the User chooses to save the input and clicks “Save”. By doing that, the control flow switches to the System side where the system validates the input.
When counting the transactions you should count the number of times the control flow switches lane (crosses the lane line) – except for error handling – those should not be counted.
So, in the activity diagram above I count three lane crossing – when I subtract the one involved in error handling, I calculate a total of two transactions for that use case.
Imagine doing this for all seven use cases in the use case model, we might end up with following categorising and a total UUCW score of 45:
“As you might have noticed you are now taken advantage of having documented your use cases properly by using activity diagrams with clear division of actor lanes!”
So far, so good.
The next step is to calculate the unadjusted Actor Weight (UAW) score. The UAW score tells something about the complexity of the solution. The Actor categories shown in the figure below doesn’t need much explanation.
When looking at the use case model shown in top (above) of this post, let’s assume that the two actors are human beings. The UAW score is then ‘6’ as stated in the figure above.
The next step in calculating the UCP score is to calculate the Technical Complexity Factor (TCF). The Technical Complexity Factor is often the most confusing part. In short, the TCF score adds an overhead of complexity to your score – the more complex the technical part of your solution is the higher score. Lets have a look at the TCF below:
By filling in the 13 factors above you’ll reach a score of 0,8 (TCF). Notice that the Complexity Factor (not to be confused with TCF) is 0.6. The formula to get to the TCF is just to multiply the Complexity Factor by 0.01 – don’t ask! it just happens to be the formula.
The final calculation to do is calculating the Environmental Complexity Factor. This factor is even more confusing than the TCF score. As you can see from the figure below the impact of various factors are rated. This gives you a sum (ETF) that goes into the ECF formula:
So far the following calculations has been performed:
Unadjusted Use Case Weight : UUCW
Unadjusted Actor Weight: UAC
Complexity Factor: CF
Technical Complexity Factor: TCF
Environmental Technical Factor: ETF
Environmental Complexity Factor: ECF
By having those six formula results you are now able to calculate the Use Case Point result. The Use Case Point for your solution is based on the following formula:
UCP = (UUCW + UAW) x TCF x ECF
Here is what the calculation from the example in this post looks like:
UUCW = 45
UAW = 6
TCF = 0,8
ECF = 1,085
UCP = (45 x 6) x 0,8 x 1,085
UCP = 44,268
Now, what use do you get from that?
Knowing that this project or this solution equals 44,268 worth of Use Case Points tells you a lot about the size of your project/solution. For example if you previously developed a solution worth 88 Use Case Point you now know that (with all other things being equal) this project is about half as big. This is valuable information in estimating the effort.
If you know that the previous solution you developed (the one worth 88 UCP) demanded you 1000 hours of development, then it is likely that this new solution will take you about 500 hours to develop. That is, what the final calculation is all about: The Productivity Factor (PF).
The Productivity Factor (PF) is the hours of development per use Case Point. If the PF equals 10 then; (from the example above) the project estimate is (10 x 44,268) 442,68 hours.
Using the UCP method for creating estimates and discussing those estimates with suppliers can involve a lot of arguing about what the right PF factor should be. The supplier of course, will argue that the PF factor should be fairly high – e.g. 20 or 25. You, on the other hand, might argue that the productivity factor should be way lower – e.g. 9 or 8. So, what is right then? Reading materials explaining UCP estimation often suggests that a productivity factor of 20 is correct. The thing is though, that it depends.
Building your own baseline of PF Factor documentation
What you should do is to start collecting knowledge about your projects and the realised PF calculated. Let’s say you have completed a project and that the UCP point calculated for that project was 120. Now, if you spend 1800 hours developing the solution then your realised PF is: 1800/120 = 15
Imagine doing this for all your projects the result could look like illustrated below.
Now, by tracking your realised PF you can calculate a baseline by calculating an average PF of 12,6.
What the average PF of 12,6 tells you is that in average, when developing solutions in your organisation, using your IT environment, dealing with your business complexity, you spend in average 12,6 hours per use case point.
You could take the UCP baseline calculation a step further. For example if Project1 and Project2 are infrastructure projects and Project4 and Project7 are ERP projects you can create various Realised PF baselines depending on the project type ….. or depending on the suppliers, or in-house / external development, or, or….. The possibilities go on. It only requires a solid base of project tracking.
Using this information to control your suppliers
By having an average PF calculation you are able to create a documented fact based estimate. With a fact based estimate you have a better position when negotiating with suppliers.
- Why can’t you deliver on a PF of 12,6, when all our other current suppliers in average delivers on 12,6 PF?
- If your offer is based on a PF of 30 we believe you are charging too much based on the performance of our other suppliers/projects
- If your offer is based on a PF of 4 we fear that you have not understood the complexity of our project, or that you under-charge just to get your foot in.
- All right, we’ll accept your offer based on a PF of 20 once again, but you must document a strategy on how to optimise your performance to match our other suppliers.
Remember that UCP estimation and PF calculation are not absolute truths. What you get is an estimate based on facts and an estimate that gives you a feeling of what end the “real” estimate should be in.