Estimating With Use Case Points - Part 3

Mike Cohn, Mountain Goat Software, https://www.mountaingoatsoftware.com/

Putting It All Together

To come up with our final Use Case Point (UCP) total, Karner's formula takes the Unadjusted Use Case Points (UUCP, the sum of the Unadjusted Use Case Weight and the Unadjusted Actor Weight) and adjusts it by the Technical Complexity Factor (TCF) and the Environmental Factor (EF). This is done with the following formula: UCP = UUCW x TCF x EF

The values that were determined for these components in the example throughout this article are summarized in Table 9. Substituting values from Table 9 into the UCP formula, we get:

 UCP = 600 x 1.02 x 0.89 = 545

Factor	Description	Weight
UUCW	Unadjusted Use Case Weight	560
UAW	Unadjusted Actor Weight	40
TCF	Technical Complexity Factor	1.02
EF	Environmental Factor	0.89

Table 9. Component values for determining total Use Case Points

Deriving Duration

First, notice that this section is titled "Deriving Duration." It is not called "Estimating Duration." An appropriate approach to planning a project is that we estimate size and derive duration. Use case points are an estimate of the size of a project. We cannot, however, go to a project sponsor who has asked how long a project will take and give the answer "545 use case points" and leave it at that. From that estimate of size we need to derive an appropriate duration for the project. Deriving duration is simple - all we need to know is the team's rate of progress through the use cases.

Karner originally proposed a ratio of 20 hours per use case point. This means that our example of 545 use case points translates into 10,900 hours of development work. Building on Karner's work, Kirsten Ribu (2001) reports that this effort can range from 15 to 30 hours per use case point. A different approach is proposed by Schneider and Winters (1998). They suggest counting the number of environmental factors in E1 through E6 that are above 3 and those in E7 and E8 that are below three. If the total is two or less, assume 20 hours per use case point. If the total is 3 or 4, assume 28 hours per use case. Any total larger than 4 indicates that there are too many environmental factors stacked against the project. The project should be put on hold until some environmental factors can be improved.

Rather than use an estimated number of hours per use case point from one of these sources, a better solution is to calculate your organization's own historical average from past projects. For example, if five recent projects included 2,000 use case points and represented 44,000 hours of work, you would know that your organization's average is 22 hours per use case point (44,000 / 800 = 22) . If you are going to estimate with use case points, it is definitely worth starting a project repository for this type of data.

To derive an estimated duration for a project, select a range of hours. For example, you may use Scheider and Winters' range of 20 to 28 hours per use case point. Based on your experience with writing use cases, estimating in use case points, and the domain of the application you might want to widen or narrow this range. Using the range of hours and the number of use case points, you can derive how long the project will probably take. For example, suppose we have the following information:

• The project has 545 use case points
• The team will average between 20 and 28 hours per use case point
• Iterations will be two weeks long
• A total of ten developers (programmers, testers, DBAs, designers, etc.) will work on this project

In this case, the complete project will take between 10,900 hours and 15,260 hours to complete (545 X 20 = 10,900 and 545 x 28 = 15,260). We estimate that each developer will spend about 30 hours per week on project tasks. The rest of their time will be sucked up by corporate overhead-answering email, attending meetings, and so on. With ten developers, this means the team will make 10 x 30 = 300 hours per week or 600 hours of progress per iteration. Dividing 10,900 hours by 600 hours and rounding up indicates that the overall project might take 19 two-week iterations. Dividing 15,260 by 600 hours and rounding up indicates that it might take 26 two-week iterations. Our estimate is then that this project will take between 19 and 26 two-week iterations (38 to 52 weeks).

Some Agile Adaptations

As originally conceived, a use case point approach to estimating is not particularly suited to teams using an agile software development process such as Scrum or Extreme Programming. This is one of the reasons I ultimately chose not to describe the approach in my book Agile Estimating and Planning (Cohn 2005). In particular, the need to create a complete use case model at the user goal level is incompatible with agile values because it encourages the early creation of a (supposedly complete) set of requirements. However, because many teams work with use cases and because many of them are moving in agile directions, it is worth suggesting how the approach can be applied in a semi-agile context.

Tracking Progress

One of the most useful techniques to come out of agile software development is the burndown chart (Schwaber and Beedle 2001). A typical release burndown chart shows the estimated amount of time remaining in a project as of the start of each iteration. The sample burndown chart in Figure 2 shows a project that had approximately 250 days of work at the start of the first iteration, about 200 by the start of the second iteration, and about 175 by the start of the third iteration. Things didn't go well during the third iteration, and by the start of the fourth iteration the team was back to an estimate of 200 days of work remaining. The cause of this increase is unknowable from the burndown chart. But this is usually the result of adding new requirements to the project or of discovering that some upcoming work had been incorrectly estimated.

Figure 2. A sample burndown chart

Having become addicted to the use of burndown charts as a technique for monitoring the progress of a team, I am reluctant to let go of such a powerful communication and tracking tool. Fortunately, there is a way to use a burndown chart even for projects that estimate in use case points.

The best way to do this is to use only the Unadjusted Use Case Weight on the vertical axis, and to allow a team to burndown 5, 10, or 15 points for every simple, average, and complex use case they finish. (You'll recall these were the weightings shown in Table 1.) For the sample project discussed throughout this article, the intercept on the vertical axis would then be at 560, the Unadjusted Use Case Weight as calculated in Table 2. The burndown chart shown in Figure 3 starts at this point and shows the team's progress through the first two iterations.

Figure 3. A burndown chart of Unadjusted Use Case Weight

Measuring Velocity

Agile teams like to measure their velocity, which is their rate of progress. With a use case point approach and with burndown charts drawn as described in the prior section, velocity is calculated as the sum of the weights of the use cases completed during an iteration.

Advantages and Disadvantages to Estimating with Use Case Points

As with most things, there are some advantages and disadvantages to the use case point approach. The final two sections of this article briefly outline the key issues.

Advantages

The first advantage to estimating with use case points is that the process can be automated. Some use case management tools will automatically count the number of use case points in a system. This can save the team a great deal of estimating time. Of course, there's the counter argument that an estimate is only as good as the effort put into it.

A second advantage is that it should be possible to establish an organizational average implementation time per use case point. This would be very useful in forecasting future schedules. Unfortunately, this depends heavily on the assumption that all use cases are consistently written with the same level of detail. This may be a very false assumption, especially when there are multiple use case authors.

A third advantage to use case points is that they are a very pure measure of size. Good estimation approaches allow us to separate estimating of size from deriving duration. Use case points qualify in this regard because the size of an application will be independent of the size, skill, and experience of the team that implements it.

Disadvantages

A fundamental problem with estimating with use case points is that the estimate cannot be arrived at until all of the use cases are written. Writing user goal use cases is a significant effort that can represent 10-20% of the overall effort of the project. This investment delays the point at which the team can create a release plan. More important, if all the use cases are all written up front, there is no learning based on working software during this period.

Use cases are large units of work to be used in planning a system. As we've seen in this article's example, 71 use cases can drive 38 to 52 weeks of work for a ten-person team. While use case points may work well for creating a rough, initial estimate of overall project size they are much less useful in driving the iteration-to-iteration work of a team. A better approach will often be to break the use case into a set of user stories and estimate the user stories in either story points or ideal time (Cohn 2005).

A related issue is that the rules for determining what constitutes a transaction are imprecise. Counting the number of steps in a user goal user story is an approximation. However, since the detail reflected in a use case varies tremendously by the author of the use case, the approach is flawed.

An additional problem with use case points is that some of the Technical Factors (shown in Table 5) do not really have an impact across the overall project. Yet, because of the way they are multiplied with the weight of the use cases and actors the impact is such that they do. For example, technical factor T6 reflects the requirement for being able to easily install the system. Yes, in some ways, the larger a system is, the more time-consuming it will be to write its installation procedure. However, I typically feel much more comfortable thinking of installation requirements on their own (for example, as separate user stories) rather than as a multiplier against the overall size of the system.

References

Cockburn, Alistair. 2001. Writing Effective Use Cases. Addison-Wesley.

Cohn, Mike. 2004. User Stories Applied for Agile Software Development. Addison-Wesley.

Cohn, Mike. 2005. Agile Estimating and Planning. Addison-Wesley.

Ribu, Kirsten. 2001. Estimating Object-Oriented Software Projects with Use Cases. Master of Science Thesis, University of Oslo, Department of Informatics.

Schwaber, Ken and Mike Beedle. 2001. Agile Software Development with Scrum. Prentice Hall.

Schneider, Geri and Jason P. Winters. 1998. Applying Use Cases: A Practical Guide. Addison Wesley.

---

Related estimation articles

Fingers in the air: a Gentle Introduction to Software Estimation

#NoEstimates - Alternative to Estimate-Driven Software Development

Forecasting: Asking Why and Discovering What is Behind the When

More Agile Project Management and UML Knowledge

Scrum Expert

UML & Software Architecture Zone

---

Page 2

---

Click here to view the complete list of archived articles

This article was originally published in the Fall 2005 issue of Methods & Tools