Release Planning Methodology Overview

1
Release Planning Methodology Overview
2
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

3
The Product Lifecycle
4
Follow on Lifecycles
5
Eliciting Potential Requirements

• Starts with a wish list
• Stated as business requirements
• Features or architectural enhancements

6
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)

7
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. w0.6 means can dedicate 0.6x8 4.8
  hours/workday
• Accounts for
• Other tasks, sickdays, meetings, weekends, ...
• Range is 0 .. 9, usually 0.6 or so

8
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

9
A Geometric Analogy - Capacity
10
A Geometric Analogy - Requirement
11
A Geometric Analogy - Capacity Constraint
12
A Simple Release Plan
Dates Coding phase Jul.1Oct.1 Beta
availability Nov.1 General availability Dec.1
Capacity days available Fred 31
ecd Lorna 33 ecd Bill 21
ecd total 317 ecd Requirement days
required AR report 14 ecd Dialog
re-design 22 ecd Thread support 87
ecd total 317 ecd Status Capacity 317
effective coder-days Requirement 317 effective
coder-days Delta 0 effective coder days
13
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
• Cant 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

14
Resource Ratios

• Typical ratios I have used
• Adjust to taste
• Assumes availability throughout the (overlapping)
  release cycle.

15
Phase Length Ratios

• Typical ratios I have used
• Adjust to taste

16
Release Overlap

• Overlapping release cycles smoothes resource
  utilization

17
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,