ICS 125: Planning and scheduling releases

Each release should be part of a larger product roadmap
A roadmap typically looks into the future 2-5 years
A roadmap identifies a few defining features of each release, and the approximate dates of the release. E.g., mozilla roadmap schedules release dates and support life-time, but it does not describe the contents of each release.
Across the roadmap, you can plan for technology change. E.g. Moore's law, the price of RAM, the availability of new standards, or the release of a new operating system.

Enumerate and prioritize
- Time-box the release, e.g., a maximum of 3 months (from the roadmap).
- List "defining features" (from the roadmap).
- List contractual obligations (from customers).
- List known high-priority defects (from the issue tracker).
- List "nice-to-have" features in priority order (from the issue tracker).
Roughly estimate effort, schedule, dependencies
Design the release requirements
- Select groups of issues that logically go well together
- Select groups of issues that roughly fit available resources
- Identify any process improvements needed for this release
- Identify and mitigate risks. Limit total risk in the release.
Communicate the release scope to other stakeholders
- Write and post a release mission statement. E.g., Mozilla 1.0 Manifesto.
- Track all issues with the release milestone
- Continue refining requirements

List tasks
- List things that need to be done. Don't forget time to learn, and to repair defects.
- Organize the overall plan into tasks in a Work Breakdown Structure
- Reality check: do you have enough requirements detail to complete the list?
Estimate each task
- Estimation formulas: Shalls, Function points, Feature points, Object points, CoCoMo
- The person who will do the task should have input on the estimate
- Estimate = (best_case + 4 * most_likely_case + worst_case) / 6
Assign each task to a resource
Determine the critical path
- Try to shorten the critical path by removing dependencies or slipping features
- Try to keep resources interchangeable
Add together the estimates along the critical path
Factor in risks, buffer time
Consider externally imposed deadlines

What could make your schedule too short?
- Unplanned tasks, requirements changes
- Underestimates for particular tasks. Wrong coefficients.
- Missed dependencies
- Excessive defects
- Loss of resources
What can you do to get a release back on schedule?
- Best: Find specific cause of delay and fix it
- Good: Slip features to a future release
- Good: Simplify features (slip half a feature to a later release)
- OK: Add resources (but that also adds training and communications)
- Bad: Lower acceptance criteria: quality, performance, usability, polish
- Bad: Change the schedule to give more time
- Worst: Work overtime (can be OK once in a while)
McConnell: As projects get larger, construction activities (detailed design, coding, debugging, unit testing) take a smaller percentage of time and other activities (planning, architecture, integration, system test) take a larger percentage of time.
Ballpark productivity figures:
- Ideal conditions: 100 LOC / developer / day
- Average conditions: 10 LOC / developer / day
- Very challenging conditions: 1 LOC / developer / day