In 2011, I wrote my thesis describing an approach to estimating agile projects early in the software development life cycle. Primarily, the thesis was concerned with sizing software. However, in one of the case studies, I described how effort and schedule could be estimated using the Constructive Cost Modeler (COCOMO), Constructive Phased Schedule Model (COPSEMO), and Constructive Rapid Application Development (CORADMO). The primary output of CORADMO is shown above. At that time, both COPSEMO and CORADMO were implemented as separate spreadsheets in the same Excel workbook. The USC COCOMO team wrote a book called Software Cost Estimation with COCOMO II. There were copies of all of these models included on a DVD sewn into the book. The models all worked together. This is important. You can download the different models from the USC website, but sometimes the versions to not work together properly. Regardless of this implementation difficulty, the underlying models are all usable. I did not make any changes to the COPSEMO parameters. Now COPSEMO and CORADMO are implemented as separate workbooks.

COPSEMO

COPSEMO was first developed as part of the CORADMO model. It adjusted the scheduling that was done in COCOMO or COCOMO II. COCOMO was primarily used for projects that used a waterfall approach. There were analysis phases, design phases, and more. Even small projects ended up taking a fair amount of schedule time. For example, a 4 staff month project might take almost 4 calendar months to complete. An analysis would have to be done. Customers would have to sign off on the analysis. It could become lengthy. Most project managers use a square root approach to staffing. A 4 staff month project should take 2 people 2 calendar months to complete. Most Scrum Masters would agree.

The square root approach quickly becomes unworkable. A 100 staff month project usually cannot be done by 10 developers in 10 calendar months. COCOMO II would predict that it will probably take longer. In fact, after about 64 staff months, COPSEMO predicts that the COCOMO II duration is accurate. Between 4 staff months and 64 staff months COPSEMO extrapolates its schedule between the square root approach and the COCOMO II prediction.

For my thesis, I did not have to make any changes to the COPSEMO parameters. For estimating agile projects, COPSEMO should work without modification. For typical agile projects, it gives reasonable estimates of required project schedule.

The project schedule is the time until the software is released. If it is 2 calendar months, this will correspond to anywhere from 2 to 8 iterations, depending upon the length of the agile iterations used in the organization. When the COPSEMO program is run, it is very possible that the schedule will exceed 2 calendar months. However, agile principles state that delivery should be less than or equal to 2 months. This means that something must be done to speed up that delivery. Adding more people is usually not an effective way to achieve this. The approach that usually works is to reduce the functionality of the first release and plan to add functionality on subsequent releases. Marketing people will recognize this as the process of designing the minimum viable produce (MVP).

CORADMO

When COCOMO was developed, software was developed using a waterfall approach. First, all of the analysis would be captured by analysts. Next, designers would come up with a systems design. Then, coders would implement that design. There was constant translation between the work products of analysts, designers and coders. This took time. In the Eighties and Nineties, people started to experiment with Rapid Application Development (RAD) techniques. These techniques cut the amount of effort required to develop an application. It also lowers the calendar time required to deliver the completed system.

RAD covered several different styles of software development. Sometimes it involved the use of spreadsheets or other very high level languages to develop applications. These languages might be domain specific in areas such as finance or process control. RAD could also involve the use of GUI builders and database management systems. Prototyping was often used. Systems were often developed in time boxes, where the amount of time and effort was fixed and the functionality was adjusted to insure on-time delivery. Agile development is the latest incarnation of RAD, and like its predecessors, it can be estimated using CORADMO.

CORADMO Outputs

CORADMO output basically begins by giving the inputs that have driven the model. The sample is taken from my 2011 dissertation. It shows the CORADMO output that corresponds to the Havannah case study from Mike Cohn’s Agile Estimating and Planning book. The estimating method was different, but the results were similar. In any case, the inputs were extracted from a COCOMO II run. COPSEMO is considered a separate model, but it is part of the CORADMO spreadsheet.

The diagram at the top of this post illustrates part of the output of CORADMO. It shows the number of people needed vs. the calendar time. When planning an agile project, consider the sum of the Inception, Elaboration and Construction phases. CORADMO supplies this information in tabular form in addition to the diagram. A sample of  the CORADMO output follows:

Step 4 really gives the answer and step 5 is intended to describe how the diagram is generated. In any case, this sample shows that the project should require 19.6 staff months. They would be delivered in 3.7 calendar months by a team of 5.3 people. Obviously, an estimator should interpret this as 6 people for 4 months.

An agile practitioner’s work is not done at this point. According to agile principles, no release should take more than 2 months. The practitioner must now use this tool to find such a release. Theoretically, the team can use a higher level language or more experience members. Usually, the users must identify a usable subset of functionality that can be implemented more quickly but will still be usable. Then the remainder of the functionality will be delivered by later releases.

The tool performs a breakdown according to the Unified Process. There is an Agile Unified Process. Few agile practitioners will be interested in the breakdown between phases. However, they are part of the tool. Some estimators have made use of these for various purposes. A brief explanation of the phases follows:

Inception Phase

This is basically a feasibility phase. Some agile methodologies call this out and indicate that these steps should be done prior to agile development. Much of it covered when developing the business case to fund the project in the beginning.

Elaboration Phase

Elaboration is where a healthy portion of the requirements are established and the system architecture is validated. In agile development, this is only relatively possible. The requirements are not really nailed down until a story is being implemented. In fact, agile development welcomes changes to the requirements right until the iteration begins. The architecture evolves, constantly staying in the simplest form that gets the job done.

Construction Phase

This is where the code is developed and tested. In all forms of RAD in may be composed of several time boxes. In agile development, it may be composed of several iterations or sprints, depending upon the particular agile variant that is in use.

Transition Phase

This is the final phase. It is intended to be the time when the application is transitioned to its target users. It also contains conversions of data from any previous systems to the new one. User training is also conducted. In agile projects, many of these activities may have already been done in releases that might have been considered components of the Construction phase.

CORADMO Cost Drivers

Step 3 was missing from the outputs above. It is shown here:

These are cost drivers that impact the amount of effort and schedule that will be required for the release. They are explained below:

RVHL – Reuse and Very High-level Languages

This cost driver measures the amount of experience that the agile team has in the use of any prototyping tool that is being used. Reuse in general is a COCOMO II driver. This refers specifically to prototyping tools that will speed up the interaction with users that the developers are working with.

DPRS – Development Process Re-engineering and Streamlining

This is a measure of the amount of bureaucracy in a project or organization. It ranges from heavily bureaucratic to fully streamlined. One indicator of the amount of bureaucracy is the number of people who must approve that a task is done. Related to this is the amount of time that is given to each person for their approval. If either or both are excessive, then rapid application development will become difficult to achieve.

CLAB – Collaboration Efficiency

Basically, this measures the ability of the team to work together. It is multidimensional. It considers the ability of the team to interact seamlessly. It considers whether the team is collocated.  It also considers the capability of the team members. This includes tool experience, experience with the problem domain and experience with the computer language being used for implementation.

RESL – Architecture / Risk Resolution

This is also a scale factor in COCOMO II. In both cases, it has the same meaning. It measures the extent that risks have been mitigated in the project. The amount of staff and time that were spent establishing a system architecture is considered in arriving at this value.

PPOS – Pre-positioning Assets

Assets include processes, tools, architecture and components. This driver measures the extent to which these assets can be furnished to the team on demand. All projects have some assets available to them. However, on some projects, none of the assets have been specifically tailored to the project. At the other extreme, all items have been pre-positioned and tailored.