Agile Development and Software Metrics

[article]

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.

Example

Sprint

Quality Measure

Example 1

1

5 defects / 21 FPs = 0.24 defects/FP

 

2

1 defect / 4 FPs = 0.25 defects/FP

 

Total

6 defects / 25 FPs = 0.24 defects/FP

Example 2

1

5 defects / 21 FPs = 0.24 defects/FP

 

2

7 defects / 25 FPs = 0.28 defects/FP

 

Total

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. 

Estimation
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

Dan Horvath's picture Dan Horvath

Dan Horvath, Senior Management Consultant, Q/P Management Group, specializes in project management and software engineering metrics, including function point analysis. Prior to joining Q/P, Mr. Horvath was with General Electric, Federal Mogul Corporation, and Electronic Data Systems Corporation. In his fourteen years with EDS, he held the positions of Senior Systems Engineer and Senior Project Planning Specialist. His most recent position was that of Senior Consultant in EDS' Project Management Consulting Group. In this and prior roles, he was responsible for the project management of several large software development projects, including training, biochemistry and air sampling and attendance applications for General Motors. He employed the use of software engineering metrics on his own projects, and also consulted with other groups to assist in areas such as function point analysis.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03