In my last article on estimation, I talked about creating consistent estimates by establishing a scale, where for every type of work you do, and for a range of complexity levels (i.e. low – medium – high), you record pre-set values that can be plugged in to your estimates.  What I was in fact describing was a complexity model.  In this article I will describe how as a team you can build your own complexity model for your development organization to govern your estimates.

In constructing your complexity model you are essentially identifying the factors that complicate the various types of work your organization does.  This can be a great teambuilding exercise for developers that can bring clarity and structure to the estimation process. 

  1. To get started, you want to assemble a cross functional team of experts from your development organization. 
  2. Capture the different work types for your environment.  These can be driven by environmental factors such as specific technologies (e.g. SAP, Oracle, Microsoft) or specific architectures (e.g.  ERP, e-commerce, n-tiered, distributed).    Types might be development of things such as database elements (stored procedures, triggers, tables, indexes, etc.), a .NET or Java user interface window, a report, or some other special component as defined by specific technology / architecture present in the environment.
  3. For each work type, document the types of things that contribute to complexity of development.  For example, in the case of database stored procedures, some of the elements that add to complexity might be:

 

  • Call parameters
  • Table references
  • Table field references
  • Intermediate values set
  • Referential Integrity checks (for triggers)
  • Components Called
  • Trigger cascades
  • Branch logic (if/then/else)
  • Embedded looping
  • Data derivation complexity
  • Calculation complexity
  • Error handling
  • Performance criteria

 

 4. Parse each of the above list elements into 3 levels to comprise low, medium, and high complexity as outlined below:

Low Complexity Medium Complexity High Complexity
<10 Call parameters<5 Tables referenced<20 Fields referenced

<10 Intermediate values set

<5 RI checks (for triggers)

No Component calls

No Trigger cascades

Simple branch logic

Simple looping

Simple data derivations

Simple calculations

Simple error handling

Low Performance Risk

 10 to 20 Call parameters5 to 20 Tables referenced20 to 50 Fields referenced

10 to 30 Intermediate values set

5-10 RI checks (for triggers)

<5 Components calls

1-3 Trigger cascades

Small to moderate branch logic

Small to moderate loop structures

Simple data derivations

Simple calculations

Small to moderate error handling

Some Performance Risk

 >20 Call parameters>20 Tables referenced>50 Fields referenced

>30 Intermediate values sets

>10 RI checks (for triggers)

>5 Other components called

>3 Trigger cascades

Complex branch logic

Complex looping structures

Complex data derivations

Complex calculations

Extensive error handling

Critical Performance Risk

 

5. Finally, assign a development estimate in hours for each of the above complexity levels based on group consensus from past experience.  Capture these as initial values to plug in for estimates, and make adjustments as new data becomes available from actual projects.

In planning for new projects, the complexity model numbers can be used as a basis for estimates delivered.  Once the actual work is completed, during lessons learned review sessions, it is important to compare the actuals to the values in the complexity model and to re-calibrate the model for the next time.  This allows for continuous improvement and accuracy of the model over time.