Project Estimation & Control based on Use Cases

This week Sander Hoogendoorn (Cap Gemini) presented a seminar about “Estimation with Use Cases”. Generally, this seminar confirmed that the development method of AMIS, internally called the “Way We Work @AMIS” is still valid and up-to-date. However, there are some interesting things to learn from this seminar. The three most important ones are:

• define Smart Use Case diagrams before the Use Case documents
• use Smart Use Case stereotypes to objectify estimates
• do project iterations including customer acceptance

First a short comparison will be made between the development method of AMIS and the one presented by Sander. Second, three learning points will be described that lead to ideas to improve the “Way We Work @AMIS”.

The Way We Work @AMIS

ASAP
A development project of AMIS typically starts with a so called, ASAP. This stands for Application Scoping and Planning. The ASAP takes about 3 to 4 weeks and delivers a clear scope, cost estimate and project plan. This phase can be compared to the phases Propose and Scope as Sander presented. Even the way the scope is defined, can be compared. The scope is defined as a hierarchy of business processes from “cloud” level processes, to “kite” level down to the “sea” level of elementary business processes. These identified elementary business processes are the right level for Use Cases.

Global Design
At AMIS we would now start on the global design by means of describing all elementary business processes in separate Use Case documents. These Use case documents would than be the basis for the cost estimation. Two experienced estimators will read the documents in order to identify system functions. These system functions will be classified as screen, report or utility with a certain level of complexity from 1 (simple) to 5 (complex). For every combination a number of development hours is known for either traditional Oracle development or Java development. In the end a total cost estimate will come out.

In the approach of Sander one would first work out Use Case Diagrams. Such a diagram contains the identified Use Case as one circle and a number of, so called, Smart Use Cases as circles attached to the first as either an “include” or “extent” (see http://wiki.trinidadplatform.org for more back ground on the Smart Use Cases). On its turn, the Smart Use Cases are given Smart Use Case Points, e.g. 1 point for a simple one and 10 points for the most complex. This means that the project size is not measured in development hours (AMIS approach), but in Smart Use Case Points, that can be converted directly into development hours, e.g. 10 development hours per point.

The Smart Use Cases come real close to the above list of identified system functions AMIS uses. However, there are two advantages:

1. It’s much quicker to deliver the Smart Use Case diagrams as it is to deliver the detailed Use Case documents. In this way a cost estimate can be provided more early in the project.
2. Since the Smart Use Case diagrams are a formal project delivery, they are known and accepted by the customer. As opposed to this, the list of system functions is an AMIS internal list, which is not known or accepted by the customer.

Development
If the project has a cost estimate and planning that fits with the customer’s budget and planned time-to-market, then the development can start. At AMIS the complex Use Case scenarios will be detailed further in a detailed design and a screen mock-up. These screen mock-ups add-up towards a kind of demo version of the system without the underlying invisible functionality and checks. All simple Use Cases scenarios will be developed right away. The whole project will be planned and divided into smaller iterations and the customer is invited to look at the result of each iteration.

There are a few interesting differences in the approach that Sander presented:

1. The project is not planned completely. Only the first iteration is planned. Together with the customer a certain amount of Smart Use Cases is chosen as part of this iteration. The total iteration size will typically be around 18 points.
2. Within the iteration, the global design, detailed design, development and testing of all chosen Smart Use Cases is executed. As opposed to the AMIS approach, the customer will not only look at te result, but also will execute acceptance testing and formally accepts the correct results.
3. After each iteration an evaluation is done, where the actual number of Smart Use Case Point is measured. Suppose that the team actually succeeded in delivering 13 accepted Smart Use Cases, then the customer is invited to choose about 13 points for the second iteration.
4. During the project, typically new insights will pop-up that lead to changes in the project scope. Each change that results in a new Smart Use Case, will be added as such. The new Smart Use Case can be given points and the impact is known to both the project team and customer. Note that the impact will only be realized if the customer chooses this particular Smart Use Case within a future iteration. In the end, the least important Smart Use Cases will probably fall-out of the scope of the project and will never be delivered.

By means of this approach it becomes possible to have an accurate project status on a daily basis, without the possibility of surprises in the end (see the Burndown Chart below). Also the customer is more involved in the continuous setting of priorities, changing of the scope and progress of the project.

Three ideas to improve

The above comparison of the “Way We Work @AMIS” and the presented approach of Sander, provides at least three ideas for improvement.

Define Smart Use Case diagrams
By means of defining Smart Use Case diagrams directly after the ASAP, a project estimate can be given more quickly. Also a list of Smart Use Cases is known and accepted by the customer as an important unit of measurement. This unit of measurement will be a shared and constant factor within the project for discussing scope changes, measuring progress and accepting deliverables.

Use Smart Use Case stereotypes
By means of describing “stereotype” kind of functionalities, it is possible to both objectify the cost estimation and possibly even generate or skip the global and detailed design of such stereotypes. A stereotype functionality might be a simple pick list, a master detail maintenance screen or a list report. See also http://wiki.trinidadplatform.org/stereotypes.ashx for a list of stereotypes and the related number of Smart Use Case Points.

Do project iterations
By means of introducing a formal acceptance test within all iterations, there will be no surprises at the end of a project. By means of planning only the next iteration, the project can absorb changes more easily. Also planning and monitoring becomes a more continuous process, together with the customer and taking into account the actual project progress and pending scope changes.