Agile Development and Software Metrics


To further develop our examples, we will now say that there were five defects for sprint number one in each case. Sprint number two introduced one defect for the first example, and seven for the second example. Once again, the difference is due to the amount of rework required for the second example. Now let’s calculate the quality.



Quality Measure

Example 1


5 defects / 21 FPs = 0.24 defects/FP



1 defect / 4 FPs = 0.25 defects/FP



6 defects / 25 FPs = 0.24 defects/FP

Example 2


5 defects / 21 FPs = 0.24 defects/FP



7 defects / 25 FPs = 0.28 defects/FP



12 defects / 25 FPs = 0.48 defects/FP

Table 4. Quality Measurements

We can see that our quality is reduced in example number two when compared to the first example. Again, this is due to the amount of rework involved to deliver the same functionality. 

Project estimation may use any of several methods, with one of the most rigorous and accurate methods employing an estimate of the number of function points to be delivered. From this, as well as additional data, the expected productivity, effort, cost, schedule, and staffing can be derived. For both waterfall and agile projects, these estimation metrics would typically be determined prior to the beginning of project development. For agile projects, however, this means that objectives are determined at the beginning of a sprint rather than at the beginning of development because too little is known, by the development team or even the system owner, about the requirements until each sprint begins.

Estimating agile projects at a complete project level may be done using rough order of magnitude (ROM) techniques. These techniques are used when little else is known about the detailed requirements. If the approximate number of internal logical files is all that is known up front, a ROM count can be done using only that information. You can refine the ROM count as you learn more information, such as maintenance or reporting requirements.

For example, an enhancement project has requirements that five logical files are to be added. If little else is known, you can apply some assumptions (such as an average complexity for most functions) to develop a ROM count as illustrated here:

  • If you have five average internal logical files (ILFs), you have fifty unadjusted function points (UFP).
  • With ten average external input transactions (EIs) (add and change functions for each), this results in forty UFP.
  • With five low EIs (delete function for each): fifteen UFP.
  • If you have five average external output (EOs) transactions (one report related to each ILF): twenty-five UFP.
  • Total = 130 UFP

With this ROM function point count, you can now estimate effort using the productivity measurements from past projects. You can use the effort to determine any resource requirements and expected quality. Additionally, you can use the estimate to break the project up into manageable sprints, depending on what organizational standards and guidelines are imposed on you.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.