More Practical Effort Estimation
In overview, the method takes use cases (in the form of their graphical representation, not their textural description) and gives them weights: simple, medium or complex. It also factors in the number of actors: human or interface and gives them weights too. The numbers are summed, and a measure of the system under consideration is produced.
The question arises, how is it possible to ascertain the relative complexity of a use case? This can be done either through heuristics (more about that presently) or through a measure such as the number of scenarios that are possible running through any given use case. Because the object of the exercise is to create a reliable early lifecycle estimate, this implies the use cases also need to be available early. Typically, use cases are not produced until the project has formally started. There is, however, another way that allows the use case graphical elements to be produced quickly in time to act as the input to an early estimate. How is that accomplished?
At the heart of the activity to produce an unambiguous set of business requirements lies a requirements pattern language. This pattern language defines a set of constituent requirements patterns that are applied in sequence. The patterns include ‘Minimal Business Objects’, ‘The Usual Suspects’, and ‘New, Search, Modify’. Minimal Business Objects extends the work of Abbot on grammatical analysis to produce the smallest possible object model (which can be thought of as a data model/schema) necessary to support a system to satisfy the outline system. The input to this pattern is typically a ½ to 1 page client brief describing the kind of system they seek. Usual Suspects defines actors that typically appear in a transactionally oriented database system such as the clerk, the senior clerk, the senior manager, the customer and the systems administrator. New, Search, Modify is a modern adaptation of CRUD (create, read, update, delete). In terms of complexity, Modify X is always either of medium or high complexity. Space precludes a thorough exploration of the requirements pattern language and the identification of relative complexity, though one will be forthcoming (stay tuned). Although there are more patterns that help create an early lifecycle use case graphic, these three form the basis of the method. The approach has been used in industry for the last 5 years with success. It is good at predicting the form of the general system that is sufficient for creating effort estimates based on the UCPM.
To re-cap, the Use Case Points Method looks promising provided it is possible to get a view of the constituent use cases at an early enough phase in the lifecycle.
Figure 1: The ‘Goldilocks’ grid. Only use cases that are ‘just right’ can be compared in the UCPM.
Applying use cases to an effort estimation algorithm only makes sense if the use cases themselves are comparable i.e. they are all expressed at the same level of hierarchical abstraction. For instance, it is not possible to compare Manage Maps, with Print Map, with Create New Map. These example use cases are at different levels of abstraction; too high, too low, just right. In order to ensure use cases are available at the right level of abstraction, the requirements pattern language described above can be employed.
We now have the basis of an effort estimation technique that is intellectually defensible, however there remains much work to be done. Consider that a system is represented at 35 use case points. Further consider that the representation is given to a team of programmers and they look at it and estimate they can do it in 300 hours. Continue imagining that the system goes on to be built, and goes somewhat over the estimate and is delivered in 350 hours. The estimator has now calibrated the method at 10 hours/use case point. A useful piece of information, but not a reliable piece of information. Imagine the team does another project that is 20 UCP and they do it in 180 hours (9 hours/UCP). Now imagine that a different team is given a project that is also 20 UCP and they do it in 230 hours (11.5 hours/UCP). What is the estimator to make of all this additional information?
Clearly, the amount of time needed to fulfil one use case point’s of functionality is going to fall within a range, and the actual amount of time is going to vary based on a variety of factors. Those factors will include the team’s composition:
- The seniority/level of talent of the team members
- The individual’s effectiveness within a given team
- The degree of experience the team has of working together
- The familiarity of the team with the business domain
- The degree of reusability the team can identify from existing components
Therefore it could be expected that a team’s effectiveness may be reliable within a range of between 8 and 15 hours per use case point in the first year, and within 7 to 12 hours in the second year when experience and familiarity begin to make themselves felt, increasing productivity and narrowing the range.
There are certainly other factors that will impact on the productivity metric, such as the overall size of the project, where one of magnitude 200 vs. one of magnitude 1000 might require a different range, given that greater size, requires more people and therefore more complexity. No doubt there are other factors as varied as there are projects, but it must be borne in mind that we are interested in the overall method rather than the exceptional project that confounds it.
To implement a system of repeatable effort estimation within an organisation, there needs to be a willingness of the programme office to make the investment in instituting a repeatable process that will start off being less accurate, and consequently less useful, and grow over time to become more accurate and correspondingly more reliable. The reality is that few organisations have the patience or rigour to ensure the system they define of prediction and measurement is established, implemented and analysed. In the past, this was entirely understandable, because the number of unknowns was too great. To an extent that constraint has been removed. However, a word of caution, should the eventual requirements change to such an extent that they are very different from the original requirements, the data collated will not be useful. This is not a warning to abandon the implementation of a repeatable effort estimation programme, rather it is an entreaty to capture the requirements sufficiently well in the first instance so that they are insulated from change. Certainly requirements change, but it can be demonstrated that at the level of the use case ‘Create New Map’ the requirement holds throughout the development whereas the detail of its creation as black and white vs. colour may change without compromising the process of effort estimation within a broader governance structure.
Applying the use case points method in an example is a new topic in the PrinceLite seminars.
Page 2/2