1. Z26 Project Management Metrics appropriate metrics for iterative projects Lecture 4a Graham Collins, UCL graham.collins@ucl.ac.uk

2. Development Metrics (measurements)  Measurements have traditionally included lines of code (LOC) and there are several models based on this including the hierarchy of cost and effort models COCOMO (COnstructive COst MOdel) developed by Boehm  More recently other metrics have been used such as function points, which give a better indication of size and complexity  Recent development work (Bittner and Spence) indicates that a move to working software is perhaps one of the best measures of progress. What is iterative development? Part 3: The management perspective 15 May 2005 www-128.ibm.com/developerworks/rational/library/may05/bittner-spence/index.html

3. Iterative projects  From the project managers perspective iterative projects can be viewed as a series of self contained projects with the application of all the disciplines of software development (requirement, analysis, design, implementation, and testing) to produce a release of the project  With the Unified Process initial iterations may establish design including architecture. With agile methods emphasis is placed on releases of working software  Bittner and Spence outline this at its simplest as series of stages.

4. Simplest level (Bittner-Spence) 1. Agree with the team the objectives for the iteration, including evaluation criteria, timescales, and constraints 2. Agree on a plan for how the team will achieve the objectives 3. Execute the plan 4. Assess the achievements of the team against the initial set of objectives and evaluation criteria 5. Assess the impact of the iteration’s results on the project as a whole 6. Start the next iteration.

5. Fundamental shift in measurement Progress ( % complete measured in scenarios 100% 0% Iteration 1 2 3 4 codedtestedTested & Passed

6. Developer Perspective  Developers are less interested in the business value, benefits realization and return on investment  They work on a small number of requirements or change requests from their list of outstanding work  They anticipate a decreasing number of requirements and change requests as the product is developed  Outstanding requirements and change requests is termed the product backlog  The developer will therefore be aware of progress via work completed, product backlog and new work allocated.

7. Rate of work - velocity

8. Work Remaining

9. Additional Measures  At different levels, release; defects, total critical, Working as Designed (WAD) iteration; velocity and stories delivered (or as a ‘burndown’ i.e. remaining), and daily; delivered and remaining  The iteration metrics could be developed further to include moving average for velocity, and for stories delivered; planned, delivered, % achieved and moving average. This would give an indication of the average rate of work and also a comparison of planned against delivered each iteration.

10. Earned Value  EV could be applied to these figures, although measuring this could be considered unnecessarily complex especially if more stories are added as the work progresses (e.g. agile projects).  This however would be useful if the figures have to be shown to senior managers who are used to EV figures, or comparison to other projects where EV figures have been tracked  When additional story points are added to the planned work it does not necessarily affect the original plan in terms of EV or business value (as often the additional work is to ensure adequate functionality). In effect although there may be more story points added the overall business value planned within a specific time frame can remain the same, and depending on how the planned (budget) is calculated, this can also remain as initially calculated.

11. Business Value  More importantly business value (or contribution) should be considered and evaluated  Often units of measure such as story points can be valued as 0.5 or 1.0 units  The key issue in agile project management is to continually assess with the client the most important work that should be done.

12. Further reading  Agile Estimating and Planning, Mike Cohn, Prentice Hall (Pearson Education) 2006 ISBN: 0-13-1479041-5  Managing Agile Projects, Sanjiv Augustine, Prentice Hall (Pearson Education) 2005 ISBN: 0-13-124071-4