Release Planning Methodology Overview CSC 444 F05 Lecture

Release Planning Methodology Overview CSC 444 F'05 Lecture 3 1

Release Planning Framework • Provide a software release planning framework – that balances • business concerns • software development concerns – provides better predictability of • end-date • delivered debugged feature set – provides early notification of slips – allows for re-planning as events unfold – deals explicitly with uncertainty CSC 444 F'05 Lecture 3 2

The Product Lifecycle CSC 444 F'05 Lecture 3 3

Follow on Lifecycles CSC 444 F'05 Lecture 3 4

Eliciting Potential Requirements ? Potential Requirements Next Release • Starts with a wish list • Stated as business requirements – Features or architectural enhancements CSC 444 F'05 Lecture 3 5

Sizing Potential Requirements • Cost / Benefit analysis – Cost: financial + opportunity = person days • Sizing in ECDs – Inherent size of the work item – Who will work on it – The productivity of that person on that work item • Ensure units are well-understood (more later) CSC 444 F'05 Lecture 3 6

Sizing the Available Resources • Who can work on the next release? – Must have skills and familiarity to contribute • For how long? – Must count workdays in the coding phase – Each resource available all that time? – Subtract estimated vacation • How dedicated to the next release – Work factor = w – Converts 8 -hour (nominal, arbitrary) days to time available to code and unit test during the coding phase – E. g. w=0. 6 means can dedicate 0. 6 x 8 = 4. 8 hours/workday – Accounts for • Other tasks, sickdays, meetings, weekends, . . . – Range is 0. . 9, usually 0. 6 or so CSC 444 F'05 Lecture 3 7

The Capacity Constraint • After all is done in a release Actual Resource Used == Sum of Actual Times for Features • This is always true. It is a constraint. • In planning, knowing that this must work out at the end, can estimate both sides and force the estimates to be equal Resource Estimate == Sum of Feature Estimates CSC 444 F'05 Lecture 3 8

A Geometric Analogy - Capacity p e r s o n s 1 person-day days CSC 444 F'05 Lecture 3 9

A Geometric Analogy - Requirement CSC 444 F'05 Lecture 3 10

A Geometric Analogy - Capacity Constraint CSC 444 F'05 Lecture 3 11

A Simple Release Plan Dates: Coding phase: Jul. 1—Oct. 1 Beta availability: Nov. 1 General availability: Dec. 1 Capacity: CSC 444 F'05 Fred Lorna … Bill total days available 31 ecd 33 ecd … 21 ecd 317 ecd Requirement: AR report Dialog re-design … Thread support total days required 14 ecd 22 ecd … 87 ecd 317 ecd Status: 317 effective coder-days 0 effective coder days Capacity: Requirement: Delta: Lecture 3 12

Non-Coding Time and Resource • In RP, we explicitly plan coding only. – Other • types of resources: – Testers, documenters, managers • phases: – Specification, testing – These are sized relative to the coding phase and the coding resource • Why? – Debugged code is the ultimate target • Can’t be 90% done on that and still ship intended feature set – How much time to devote to documentation? – How much time to devote to testing? – When is enough, enough? • How? – – – Establish ratios Measure what works for ratios for a given product Adjust next time around Converges rapidly Initial guess is usually pretty good CSC 444 F'05 Lecture 3 13

Resource Ratios • Typical ratios I have used • Adjust to taste • Assumes availability throughout the (overlapping) release cycle. CSC 444 F'05 Lecture 3 14

Phase Length Ratios • • Typical ratios I have used Adjust to taste CSC 444 F'05 Lecture 3 15

Release Overlap • Overlapping release cycles smoothes resource utilization CSC 444 F'05 Lecture 3 16

Shipping The Release • • After dcut, proactive management is gone. Can only watch defect arrivals and hope for the best. – If your ratios are off: forgetaboutit, CSC 444 F'05 Lecture 3 17