QSM provides unparalleled support throughout the product acquisition, installation, and implementation process.
For nearly five decades, QSM has helped organizations bring data-driven discipline to software project estimation, tracking, and benchmarking. Our methodology and tools turn project complexity into measurable, defensible outcomes.
After spending the past few weeks working with the Agile projects in QSM’s historical database, I’ve become interested in Agile Development Theory, particularly due to its popularity. While spending days at a time examining our database, I’m left with numerous data-driven questions. Therefore, I thought I would take this opportunity to write a series of Agile-related blog posts.
QSM’s database contains over 100 Agile projects from the U.S. and abroad. The projects include a variety of application types and their top three programming languages were JAVA, C++, and VB.NET. Seeing this, I thought it might be interesting to examine the “typical” Agile project according to our data.
So what does the “typical” Agile project look like? For consistency purposes, I limited the sample to IT systems projects completed in the last six years. I measured the Duration, Effort, Average Staff, and MTTD at various project sizes to see how they compare.
Below are two figures that give demographic information about our “typical” Agile projects:
This scatter plot shows the individual Agile projects compared against QSM’s Business Agile trends.
Size (SLOC)
Duration (Months)
Effort (PHR)
Average Staff
MTTD (Days)
10,000
3.9
3,420.0
7.3
2.3
25,000
5.2
6,200.0
10.4
1.8
50,000
6.3
9,740.0
13.0
1.4
100,000
7.8
15,320.0
16.4
1.2
The table above shows the values of previously mentioned metrics at various sizing units. The purpose of this table was to give a benchmark of how Agile projects in our database typically perform. It is a good way to measure your organization against the industry. This can also be done using QSM’s Business Agile benchmark trends. However, the most accurate way of estimating your projects should be from your own historical data. Since the data in this table are merely descriptive, I’m going to leave the interpretation of the results up to the readers.
In upcoming posts I will further examine the effects of these individual metrics on one another and how that relates to Agile Development Theory. In the meantime I hope this table can help give some insight on the “typical” Agile project. How do your Agile projects compare?
Operational Definitions of Metrics Measured: