Agile Software Development
Although agile development traces its roots back as far as the first incremental development methods in the 1950s, in most circles, it’s considered the next evolutionary step of RAD. Most of the agile principles were developed, defined, and documented in the Agile Manifesto, published in 2001. The manifesto describes a type of RAD methodology that favors small projects with team-oriented development groups and close customer contact and involvement. Project management of agile projects consists mainly of monitoring and measuring progress toward goals.
Given this new direction, it is understandable why it might appear that there may be difficulties in applying traditional software measures to agile projects. When a project used to be clearly defined up front (in the planning and analysis phase) with a clear beginning and end, it was easy to identify points in the lifecycle where data collection could occur and measures could be created. The same can be done with projects utilizing agile methodologies, but the approach must be flexible.
Agile Software Development “Projects”
In order to gather and apply project-related software metrics for projects developed using an agile methodology, we must first define the concept of a project in this context. Regardless of what development methodology is used, a project is still defined as a temporary undertaking with a predetermined beginning and end with the purpose of bringing about a change or producing a product. For agile development, a project may consist of one or more “stories” or “sprints” that are required to produce this final result.
In agile projects, a user story is a high-level definition of a requirement containing enough information so that the team can produce an estimate of the effort and then develop and implement the functionality. Eventually, the story may become one of the main artifacts to use in function-point counting. A sprint is an incremental piece of work used by the Scrum practices as part of an agile methodology project.
What is included or excluded from a sprint (and therefore the function point count) is determined by the project manager as well as the customer. This article generally refers to a project as a series of sprints, although it is recognized that one sprint or story may make up an entire project. Once the project is defined in this way, project-related software metrics gathering may take place. Function point analysis may be performed at the completion of the agile project or at any point during its development, just as it would for any project.
Agile Software Development and Function Point Analysis
Story points are considered by agile developers and devotees as a method of measurement for agile projects. The rate or number of story points produced during a sprint or set of sprints is called the velocity. Although there is no industry standard method of measuring story points, some organizations may measure them the same way across projects, while others will vary.
FPA provides the base measurement of several metrics; it may be performed for a sprint or an entire project. For example, there may be requirements to add a new logical file, along with functions for maintaining and viewing the data, as well as a new report to the existing system functionality. If the entire project is counted, these functions would be considered together in one project function point count (this is also the approach used to count traditional waterfall methodology projects). Considering a sprint using agile methodology, the logical file, view, and maintenance functions may be added in one sprint and the report in another. If counts are performed for each sprint, it may be possible to add the results together for the total size, which is the same as the project count. This enables all of the stakeholders to be aware of the project’s size as well as how much effort the team is expending.
Function Point Analysis can indeed be used to measure agile projects. Consideration must be given to the way in which such projects are defined. In part two of this series, we will demonstrate the use of FPA in agile development through hands-on examples. Part three will expand on the FPA examples in order to show how the metrics are applied to produce productivity, quality, and estimation measurement information.
Pages
About the author
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.
