sample use case templatesample test plan templateexample project plan template
ICS 125: Planning and scheduling releases
Planning a release > The product roadmap
- 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.
Planning a release > Scope each release
- 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
- Track all issues with the release milestone
- Continue refining requirements
Scheduling a release > Making the schedule
- 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
- 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
Scheduling a release > Evaluating the schedule
- 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