Agile Development and Software Metrics

[article]

‘Time boxing” may be an additional consideration for you on agile projects and you can use it in different situations. You can use time boxing when the requirements for the sprints, or the sprints themselves, are not initially well defined. In this case, you can break the project up into time segments, each of which you can estimate. If historical data is available, such as the function point counts of previous projects, the organization will be able to determine the number of FP that can be delivered in a certain period of time so that you can plan time boxes. Alternatively, when the requirements are well-defined and a good function point count exists, you can use time boxing to determine how much functionality will be delivered within each sprint.

Change of Scope
According to A Guide to the Project Management Body of Knowledge (PMBOK Guide) , the project scope is defined as “The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.” Any changes to project scope can result in changes to the work that had originally been defined, and these changes may result in changes to the project cost or quality. The amount of change can be expressed as a function point difference, or an effort to make the change or changes.

You can measure the change of scope at the time the changes occur, at specific points within the project development, or at the completion of the project. Since scope changes may occur more frequently during agile projects, it may be better for you to consider scope changes at a higher level for the entire set of software delivered rather than at project intervals, because it is best to define upfront what constitutes a scope change. Doing so will allow you to distinguish any changes to functions that are inherent in agile projects.

As in the second example, if a function is added in one sprint and changed in a later one, you can consider this a change in scope and you can measure this change if each sprint is counted.  Once again, because the data may be available at various stages, agile development provides the opportunity to gather this additional information in an accurate and timely manner.

Conclusion  
Although the function point counting process itself is the same for the various development methodologies, there are some additional considerations you must account for when counting projects developed using an agile methodology. For example, the sprint artifacts may be different than the documents you use when counting projects using other development methodologies. In order to be properly utilized for the counting process, these artifacts must describe in detail the functionality added, changed, or deleted by the project.  You also need to consider that in the case when multiple sprints are considered part of the same project, it’s possible that some application functions may be affected more than one time.

As noted, you can perform the function point analysis at various stages during the agile development effort. These cases would be different than the function point counts performed at various stages of development using waterfall methodologies, because the stages themselves are self-contained. In the case of waterfall development, there is a defined point in the project to perform the count, such as after the analysis or functional design phases. Any counts performed during the course of agile development would measure an intermediate work product at the completion of one or more stories or sprints. This may be for the purpose of assisting the customer or project manager in monitoring or controlling the project, or measuring the functionality of a sprint as part of the overall project.

By analyzing the data to determine the impact of quality, productivity, schedule, and cost, software development organizations may be better able to choose the most appropriate development methodology for their projects. The development methods you utilize for projects should not impede you from measuring the project.  As demonstrated in the examples presented above, you can use the function point analysis measure an agile projects, however, several considerations need to be addressed depending on how the project is defined. These considerations include the goals and objectives of the organization as well as the supporting measures. Using FPA and the other software metrics I discussed will provide you new opportunities to apply metrics to your projects.

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