Metrics and scope management in agile projects Marcel Pereboom, Mediaan April 2009
Just Software Motivation The Sydney opera house Development? Misunderstanding the requirements Not managing change properly Failure to manage expectations Lack of effective project management methodology Unclear/misunderstood scope/objectives Changing scope/objectives Start of construction: March 1959 Original cost estimate: $ 7.000.000 Original launch date: Jan 26th, 1963 Phase I: Podium Phase II: Roof Phase III: Interiors Actual costs: $ 102.000.000 Actual launch : in 1973 2
Metrics or Scope related principles Adaptive planning Timeboxed iterations Continuous project controlling Adaptive requirements engineering Continuous Quality controlling Flexible change management 3
Metrics or Scope related principles Adaptive planning Timeboxed iterations Continuous project controlling Adaptive requirements engineering Continuous Quality controlling Flexible change management 4
Metrics or Scope related principles Focus on value rather than costs Avoid waste Listen to your customer Measure and adapt Continuous process improvement Continuous learning Amplify Feedback Skilled Workers 5
Metrics or Scope related principles Focus on value rather than costs Avoid waste Listen to your customer Measure and adapt Continuous process improvement Continuous learning Amplify Feedback Skilled Workers 6
Continuous measuring of velocity Adaptive planning daily! SCRUM: Metrics or Scope related Continuous controlling of progress Volunteering instead of Command & control Self organizing teams 7
Continuous measuring of velocity Adaptive planning daily! SCRUM: Metrics or Scope related Continuous controlling of progress Volunteering instead of Command & control Self organizing teams 8
Management tools in SCRUM: Metrics or Scope related Sprint backlog Velocity chart Burn down chart Team commitment 9
Management tools in SCRUM: Metrics or Scope related Sprint backlog Velocity chart Burn down chart Team commitment 10
Motivation Benefits from introducing agile methods 88% of organizations cited improved productivity, and 84% improved quality. Cost of development: 46% stated no change and 49% stated it was less expensive with agile methods. Overall 83% claimed higher satisfaction and 26% overall claimed significantly better satisfaction. Most frequently cited positive feature of agile methods (48%) was respond to change rather than follow a predefined plan. How can this objectively be measured? Source: Corporate Report, 2003. Agile Methodologies Survey Results, Shine Technologies Pty Ltd. 11
Story points Use case points Sizing usually used in agile methods Ideal man days Not objective No formal standard Each new team, each change in teams and changing experience over time will lead to different size estimates Comparisons between teams and iterations are invalid Velocity Quality Backlog 12
FPA Introduction The task of the software industry is providing functionality (develop, maintain and operate) Objective functional size needed in order to measure FUNCTION POINTS ISO standards: Nesma Fisma IFPUG COSMIC Mark II Analogy functional size and distance Functional size Function point Project Programming language Productivity (hours/fp) Worked time Distance Meter Trip Means of transportation Speed (km/hour) Travel time Fog increases the travel time, not the distance 13
Why use only 1 sizing method? Use FPA when objective figures are vital Benchmarking Progress control Quality control Pricing Use other methods for Ease of use in the developers planning Ease of use in the burndown chart within an iteration Validation of the formal estimates 14
unclear and changing requirements (un)vailability of resources Why northernscope is needed Issues with fixed price new technology Inherent uncertainty Changing environment Fixed price contains a large sum to cater for risks Inflexibility Each change in requirements is a fight and/or is costly Disturbed relationships between client and supplier Lacking quality 15
northernscope: the solution Independent certified scope manager (PM, RM, FSM) Formal estimation with situation analysis Function point based pricing, progress control and change management Realistic expectations Increased flexibility Reducing risks for client and supplier Measured quality Fair pricing of changes Accurate progress control Successfully completing projects Value for money, budget over-runs less than 10% customer and supplier satisfaction 16
northernscope explained Overview 17
Agile Approach & 12 steps of northenscope Complete PRD Baseline requirements and size Prepare RFP Engage supplier /fp Measured change control (fp) Measured progress control (fp) Engage scope manager Divide into subprojects Early functional sizing Determine quality requirements Improved planning, risk reduction en process optimisation by using FPA Payment on size of delivered software Collect data in experience repository Objective evaluation and benchmarking by using FPA 18
northernscope explained Divide into subprojects / work packages TYPE of Projects 1. CUSTomer specific new development 2. Software PRODuct new development 3. Software VERSion enhancement 4. ICT SERVice development project 5. PACKage software configuration Create subprojects for: 6. Data CONVersion project 7. Software INTeGration development 1. other development work 2. every increment or iteration 3. different types of ICT development work 4. restart after a long break 5. different development technologies 6. different development environments 7. different development team experience 8. different quality requirements 9. different stakeholder dependencies 10. different risk levels 19
Formal estimation in northernscope Situation Multiplier Project, Process, Product, People Reuse Multiplier Development specific Functional Size FP Delivery Rate from company data h/fp Estimating Process Effort Estimate h 20
Benefits SouthernSCOPE results 21
Lessons learned from metrics Metrics show high productivity from Small experienced stable teams (sufficient duration) Sophisticated development environments with generators Projects/iterations having ideal size (not too large, not too small) Development approach is not an impact factor! Conclusions/teasers? Agile is more effective, not more productive Iterations are often to short (= not productive) Waterfall projects of 6 weeks total duration will work too 22