Smart estimation

Smart estimation is a technique for estimating the complexity and size of software development projects. The technique has been used in a large number of projects, ranging from custom software development, to business intelligence projects and even package implementations. The technique is fairly simple and is applicable without much knowledge on estimation techniques. An overview or list of your requirements will often do just fine.

Read more

Smart estimation. How does it work?. Page describing the process of smart estimation, establishing project complexity, and iteration velocivty.
Estimating user stories versus smart use cases. A brief comparison of estimation using (user) stories and using smart use cases.

Estimating smart¶

Smart estimation relies on the availability of high level requirements, modeled as smart use cases, or even a list of such use cases. Thus, estimating smart cases is independent on technology, architecture or even the type of project you're estimating. There are templates available (in download) to create the actual estimate. This is done by categorizing the smart use cases according the scale presented here, which can e.g. be done in a workshop, a so-called smart estimation poker session, or by filling in a quick estimate spread sheet. Another really fancy possibility is to export the UML model, import it in Tobago MDA, and generate out the estimate spread sheet.

Smart estimation scale¶

Smart use cases all have a similar level of granularity, an thus their complexity can be estimated on the same scale. The complexity scale that is used in smart estimation is:

1 - Piece of cake. Apply when dealing with simple selection, or simple maintenance use cases.
2 - Moderate. Apply this complexity for normal selection use cases.
3 - Average. This complexity is good for normal maintenance, or normal search use cases. Average is also the default level, even though in projects the average complexity is somewhat over 3 (on average 3.7).
4 - Hard. Apply this complexity for reporting, or one-to-many use cases.
5 - Very difficult. These are the really tedious use cases, and include graphs, extensive reporting, or interfacing to other systems and web services.
8 - Extreme, but known. This complexity is for instance used for complex interfacing with other systems, and for importing and exporting services.
10 - Extreme and unknown. Used with distributed interfacing, and complex calculations.

Download

Smart estimation poker cards. Download our set of smart estimation poker cards (as PDF).

Always investigate the possibility to split use cases of levels 8 and 10 to more detailed smart use cases of a lower complexity.

Sander Hoogendoorn

A good example for this practice came out of a project where a number of types were imported from a comma delimited flat file.

We originally estimated the single use case for this procedure an 8, but found out later during the project that this use case actually consisted of importing a larger number of types (8 to 10). If we had known this upfront, we would have extended the model, and hence would have been able to estimate more reliable.

Wouter Goedvriend

Benefits of smart estimation¶

The are a number of benefits of applying smart estimation over most other techniques:

Simple and straightforward. Once an overview of the requirements is produced, creating a smart estimate is very straightforward. Just add the complexity to the individual use cases and your done.
Early in proposals and projects. Because smart estimation relies solely on the availability of high level functional requirements smart estimates are already available in proposals and can be tuned during the early stages of projects. In it's most minimal form, smart estimation can even be used based on a list of functional requirements or on existing applications (without having the high level requirements available yet).
Deviation is minimal. Because most projects hold a large enough number of use cases, the Law of Large Numbers applies to smart estimation. Applied to this setting, this means that whenever an estimator estimates a few smart use cases to high, it is very likely that on the other hand some smart use cases will be estimated somewhat too low. On average, it still adds up.

Which types of project does smart estimation apply to?¶

The smart estimation technique can be applied to projects when the total functionality of the system can be modeled using smart use cases. There are basic guidelines for modeling smart use cases. Originally these guidelines where intended to model smart use cases for custom software development, using environment such as Java or .NET. These guidelines apply to a wide range of types of projects, mainly because they model forms and functionality at a level (called sub-function level) that is well applicable to:

Business systems. Regular administrative business systems can be modeled well using smart use cases.
Web applications. Many web applications have been modeled and built according to smart use cases.
Mobile applications. The technique works equally well in constructing mobile applications.

Additionally, modeling smart use cases has been applied to other types of projects as well:

Business intelligence. Here smart use cases are mainly use to describe the data flows in the different layers of the project. This requires additional guidelines for modeling smart use cases for business intelligence.
Workflow. Projects that administrative forms, and are based around the workflow to handle these forms, such as mortgage requests, or authorisation forms can also be handled using smart use case modeling. In this particular case, the business processes are modeled , and transformed into user goal level and sub-function level use cases.
Rebuilding existing applications. Quite often, software development projects rebuild existing outdated applications. In these projects, smart use cases can be modeled by walking through the current application, and identifying the forms and functionality behind them. Note that, in this type of projects, it is often requested that the new application contains an exact copy of the existing application. To my opinion, this is an illusion. You must aware of the fact that new and changing requirements will drop in from time to time. Therefore, the flexibility of agile software development is essential to rebuild projects.

Smart Metrics and Feedback

Feedback from real life projects. A metrics page of real life executed proejcts. Find your type of project in this section to find out what indicators you can have for your project.

Smart use case stereotypes. All about our standard types of smart use cases
Smart estimation poker. Using estimation poker for a fun way of estimating.
Quick estimate'''. Quickly produce an estimate, without having to model all the smart use cases.
Book