Estimate and Measure Agile Projects with Function Points

Transcription

1 Estimate and Measure Agile Projects with Function Points Radenko Corovic, MBA Abstract Agile development methods have much improved during the last few years, and despite some open questions, there is no doubt that agile methods are becoming a reality in many organizations. This growth has resulted in the maturation of agile methods which are becoming more structured and beginning to incorporate some elements of other practices and development methods. In this sense, agile methods have developed their own estimation and progress monitoring metrics that seem to work well and which are, according to the practitioners, very useful for agile teams. However, the portrait is different if we analyze these metrics from the perspective of the organization s needs. One of the major limitations of agile methods 1 concerns size and effort estimation as well as performance monitoring of agile projects. Indeed, there are no methods for estimating and monitoring the performance of agile projects based on a standardised procedure. This makes it very difficult, if not impossible, to measure and compare the development productivity between projects within an organization and between projects of one organization and those of the industry. We believe that the appropriate solution can be found in the application of measurement methods based on functional size; these methods are based on the customer s requirements which allow the organization to estimate and measure the performance of its projects/portfolios on a comparable basis. The method we propose is based on the COSMIC concept; it is relatively easy to use and can be applied to different phases of the project life cycle, regardless of its development methodology. It is flexible, can be adapted to the reality of each organization, and provides satisfactory results. 1. Estimation of Agile Project When talking about the possibility of using functional estimation methods for agile projects, we must first find the relationship between the basic notions in functional size estimation (project, customer requirements, elementary process, function points, etc.) and those of agile development (release, sprint, user stories, story points, etc.). In fact, the notion of project in agile development is not one defined by the PMBOK. The agile method speaks rather of "release", which designates the final delivered software that is ready to be deployed. For estimation purposes, we can consider "release" as a project and, in this article, we will use these two terms as synonyms. In agile development, User Stories (US) are used to capture the customer's functional requirements and their sum defines the product to be developed. The size of US is based on the relative complexity of each User Story and is expressed by a measure called Story Points (SP). 1 In this article we are referring to SCRUM

2 The User Stories are prioritized based on several factors; the most important among them their business value and relative complexity. They are then broken down into Work Items that are grouped together and developed in an iteration called Sprint. It should be mentioned that a User Story may be implemented into more than one Sprint. The efforts of each Work Item are estimated with a technique based on Delphi methods (Planning Poker) in order to plan the efforts of a Sprint. The estimation of the size (Story Points) and the estimation of the effort (Planning Poker) are thus done separately. After the first Sprints are completed, the team has to estimate its Velocity, i.e. the number of points it can achieve in one Sprint. This Velocity is regularly re-evaluated. By linking the Velocity and the number of points to be developed (Product Backlog), the agile team can estimate the number of Sprints required to complete the project. They can then get an idea of the end date of the project/release. 2. The Limitations of the Agile Estimation Concept Based on Story Points (SP) Some authors propose to use Story Points (SP) as the measure of software s functional size. Without performing an in-depth analysis, it is clear that SP do not provide an accurate measure of the software s functional size: Story Point calculation is not based on a standard method. There is no relationship between Story Points and Function Points. Story Point calculation is not based on the elementary processes, which are at the core of Function Point calculation. Story Points differ from one team/project to another and have meaning only to the members of the team who estimate them. The fact that a Sprint refers to a period of time in which a set of functionalities has to be developed and not to functionalities that are already completed and delivered, which is standard in the calculation of Function Points, represents another difficulty for the application of Function Points in agile development. Indeed, the functionality developed in one Sprint can be improved in a subsequent Sprint in a way that the sum of the FP of all Sprints in one project is usually higher than the functional size of software measured at the end of the project. The limitations mentioned previously do not necessarily concern the accuracy of agile project estimates and do not mean that agile projects are poorly estimated. What we wanted to analyze here is rather how the current practices of estimating agile projects are aligned with the need of organizations to have a standardized estimation method that can be applied to all projects, regardless of their development methodology. Here we can see how the current agile practices meet the requirements of organizations in project estimation as well as in project performance monitoring: 1. Obtain and Analyze the Estimate of Project Size and Efforts Early in Project Life Cycle In most organizations, before authorizing a project, it is necessary to estimate its cost and duration. The same estimates are required in the contractual process. During the design phase (upfront) of agile development, it is difficult to estimate project efforts and to determine appropriate budgets. The difficulty resides in the fact that the project functionalities (product backlog) are estimated very roughly via User Stories whose size is

3 expressed in Story Points. This size is relative and cannot be used to estimate the effort/cost of the project. The goal of agile development team is to get an idea of the relative size of each item without associating a value in terms of effort. 2. Compare the Performance/Productivity - Internal and External Benchmarking Without a standardized measure of size, it is not possible to compare the development productivity of agile projects with the productivity of other projects in one organization (internal benchmarking), and even less with other outside projects (external benchmarking). This makes it difficult, if not impossible, to perform process improvement efforts based on credible and documented data. For the same reasons, the Velocity (the number of points that a team can achieve in one Sprint) cannot be used as a measure of development productivity. In fact, it can be used in this sense, but only to measure the productivity of one specific team or, eventually, one specific project. Therefore, it is meaningless to compare the Velocity of different teams, because each team may have different estimating approaches. 3. Integrate Agile Projects in Project Portfolio Management One of the biggest challenges facing agile methodologies is the integration of agile projects in project portfolio management. The estimating and measuring tools in agile projects are useful for the project team, but they do not have a "portfolio view" and do not support strategic investment management. In order to do so, it is necessary that the portfolio includes all projects in the organization, regardless of their development methodology, whether it is agile or waterfall. This implies that all projects in the portfolio should be managed according to the same standardized metrics. It is evident that Story Points, despite their usefulness in estimating of agile projects, cannot be used as a measure of size at a portfolio level. 4. Monitor the Progress of Agile Projects Some authors recommend the use of Earned Value Management (EVM) to analyse and monitor the progress of agile projects. They try to establish a relation between the measures used in EVM with those used in agile development, but there is no conclusive evidence regarding the applicability of this method for agile projects. The main difficulty is due to the fact that the EVM is based on delivered (completed) functionality, and not on developed functionality, as it is the case in agile. Also, we already explained that Story Points are not standardised measure and so non comparable from one team to another. It does not mean that the current practices for measuring the progress of agile projects provide wrong results; it is crucial, however, that this progress becomes visible at the organizational level and that the method and the calculation of this progress are harmonized with other projects that do not use agile methods. 5. Collect Data on Past Projects in Order to Improve Future Projects Performance In agile development, historical data is rarely collected because the project team is more interested in what remains to be developed (product backlog) than in what has been developed. On the other hand, even if we decide to collect the data of agile projects (example: Effort per

4 Story Point, Story Points per month, etc.), their usefulness for other projects is very limited due to the fact that they are not based on a standardized calculation method. The fact that Story Points cannot be used to calculate quality, as it is the case with Function Points (ex. defects per function point), makes it very difficult to compare the quality of the software within similar projects. 6. Reduce the Total Cost of Ownership (TCO) Agile methods do not encourage the systematic production of system documentation. The team can produce documentation that it considers relevant but, as the emphasis is on the rapidity to obtain the operational software, documentation is often overlooked. This often results in additional maintenance costs. 3. Measure the Size of Agile Projects Despite many attempts and proposals regarding the application of functional size measurement methods (Function Points) for agile development, there is not yet a standardized approach describing the use of Function Points to measure the size of agile projects. In order to estimate and measure the size and efforts of agile projects with a functional size measure, we propose a method 2 that is based on the COSMIC method. The COSMIC method (originally - Full Function Points) is a method of software functional size measuring that is internationally recognized and is ISO standardized. It is based on the following principle: the functional size of the software is directly proportional to the number of data movements. The main advantages of this model are its simplicity and clarity. In fact, COSMIC data transfer is precisely defined and ambiguous interpretations are very rare. In addition to the reasons mentioned above, we chose the COSMIC method because it is more appropriate in order to measure the size of agile projects, as opposed to the IFPUG method. The elementary process defined by COSMIC is more granular than with the IFPUG method, which allows the measurement of the small functionalities of the software. In addition, the COSMIC method is easier to automate because it associates one point to each data movement and does not use the levels of complexity of the components, which is the case with the IFPUG. The characteristics of the proposed method are as followed: It can be performed in different phases of the project: design phase (estimate project size and efforts for budget purposes), before each sprint (estimate the size and effort of sprint/iteration) and at the end of the project (final project size for benchmarking and process improvement purposes). Being based on the standardized method of functional size measurement, this method allows the application of earned value management (EVM) for progress monitoring of agile projects. The methodology is easy to use and does not require a training in Function Points calculating. The estimating process is user friendly and very easy to perform. The estimator has to answer questions about the functionalities of the software and the tool calculates itself the software s 2 Detailed method and the tool will be presented in the forthcoming article

5 size and effort. Function Points are calculated automatically, which should not slow down or impact the dynamics of agile teams. The calculation of COSMIC Function Points is based on functional user requirements - FUR, which are also the basis for User Stories estimation. We can therefore estimate the functional size of User Stories in the early project phases. The method allows the estimation of project efforts/costs using the historical data of the organization (hours per unit of size). The calculation approach is based on the following steps: 1. Obtain functional user requirements (US) The functional user requirements are obtained in the form of User Stories. Given that the User Stories are sometimes described with one or two sentences only, it is advisable to demand a little more explanation from the client in order for him to express clearly his requirements. In this phase, we should not insist on technical language; the client can express his requirements in his own terms. 2. Identify the functional processes In this step, the client s requirements (needs) are translated into functional processes. The identification of the functional processes is defined during the mapping step of the COSMIC method. However, given that the User Stories are often presented as a group of functional processes and that we do not have enough information to distinguish them, it is not always possible to identify each elementary process in this phase of the project life cycle. To overcome this obstacle, the approach that we recommend provides the opportunity to estimate the size of User Stories, regardless of the level of granularity (aggregation) of functional processes. 3. Determine the functional size of each US in Cosmic Function Points - CFP The difficulties associated with functional size estimating in the early project phases are not exclusive to the agile method. Traditional development methods, such as Waterfall, experience the same problems. The functional size calculating methods are based on the elementary process; they therefore target the smallest software functionalities. Given that, in the early project stage, the functionalities are defined only approximately, it is very difficult to measure the functional size at this stage. On the other hand, it is important to estimate the project s size during this phase, not only because of budgetary and contractual requirements, but also in order to make a good project plan and to estimate the size of the development team. In order to give the best estimate at this stage of the project life cycle, we automated the calculation of the User Stories size by simplifying the COSMIC calculation method. In fact, since a User Story is a group of functional processes, its size is estimated at a higher level of aggregation than the elementary process. This size is not calculated, but rather estimated with an error margin determined by the level of granularity of the functionalities. 4. Estimate project (release) efforts

6 To calculate the effort required to develop functionalities defined in US, a value in effort per Cosmic Function Point (CFP) is associated with each CFP. This value, or unit cost (hours or $ per CFP), represents in fact the average organizational development productivity. It may be based on projects developed in the organization or on the industry data. By adding the efforts/costs of all estimated User Stories, we obtain the effort/cost estimates of the project (release). It is important to mention that we can have different unit costs within one organization. Although the software size does not depend on development methodology, technology or the programmer s productivity, development productivity does depend on these and on some other factors not mentioned above. If, for example, the two parts of the software are developed with two different technologies, it is likely that the effort/cost per unit of size will be different for each part. 5. Refine the estimate to measure the size and effort of each Sprint Detailed estimating parameters allow to refine the size estimated previously and to estimate the smallest functionalities of software. The estimate made earlier is simply refined in order to get more accurate results. 6. Calculate the final software size At the end of the project, we can calculate the final (delivered) size of the software. We already mentioned that the final software size is not the sum of the sizes of all Sprints. It is therefore necessary to obtain the size of the delivered software in order to calculate the unit cost of the project and to compare its performance with the performance of other projects. It is also useful to compare the final (real) size of the software with the size estimated in the early project phases. The differences between these two estimates will allow us to improve the estimation process and to better calibrate its parameters. About the Author: Radenko Corovic has over 25 years of experience in the public and private sector. He is specialized in the areas of project portfolio management, software measurement, IT performance, business process improvement and IT strategy. His interest focuses on IT management, particularly on the business aspect of IT and IT contribution in organizational productivity. He wrote many articles, including the measurement of project performance based on earned value management (EVM); some of them have even been published in the specialized journals of PMI. He is currently the president of RSM Technology, a company specialized in project portfolio management, IT projects estimating and IT performance.