A Sample Release Plan Establish release plans Identify plan owners Establish a plan change process Track the plan Track defect arrival rates Conduct post-mortems Schedule maintenance releases Maintain a one-year plan Things not to overlook
First we will need to establish release plans for each software
development initiative (each release of software).
These plans are a kind of balance sheet that identify
a release time horizon,
state the available development capacity
for that release in effective person-days,
and list the business features that will be implemented into
that release with attached sizings (also in effective person-days).
At the bottom of the plan is a summary showing the delta:
the amount by which the capacity exceeds the requirement.
Positive deltas are good. Negative deltas are problematic and
must be addressed by adding capacity or reducing the requirement.
An example of a release plan can be seen
here.
Identify plan owners
Next we need to identify a representative on the business side to
maintain the release plans.
For example, in a software vendor organization this can be a
product manager in the marketing department.
This individual is responsible for accepting requests for
new features,
maintaining this list,
proposing initial release plans,
coordinating the approval process for the plans,
and suggesting and coordinating the approval of any
changes to the plan.
The product manager must chase after development, getting them
to supply a rough sizing for any newly proposed features that
may stand a chance of making it into the plan.
Establish a plan change process
We then need to establish an approval process for release plans.
Typically there will be a cross-functional committee
(the RPC - release planning committee) chaired by the
product manager that can approve plans and plan changes.
The committee will consist of stake-holders from various parts
of the organization (for example, marketing, development, sales,
client services) who each have something positive and creative
to contribute.
There may be two levels of committees: one for smaller changes
(e.g., less than 50 person-days) and one for larger changes
(that would properly constitute changes in direction).
The product manager should also be empowered to make certain
changes unilaterally under certain conditions.
Of course, no change is allowed unless the capacity constraint
is respected (delta >= 0).
The organization soon comes to realize that the capacity
constraint must always be respected in the end.
By the end of the release cycle, it will be proven that
the capacity exactly equaled the requirement!
The only issue is whether the product manager deliberately
chose what to sacrifice with an eye towards the most
important business needs, or whether what was sacrificed was
chosen arbitrarily by a set of overworked developers that
simply could not get everything done on time.
Track the plan
As development begins,
in-plan features are more fully specified and designed.
This will lead to a refinement of earlier sizing estimates,
and this in turn will necessitate iterative re-planning.
As development proceeds,
software development management must update the release plans each week.
To do this, they first update the remaining capacity
(given that a week more has elapsed towards the end of the release cycle).
Next they update the remaining requirement.
They do this by classifying each feature into one of
NYS (not yet started),
WIP (work in progress),
or DONE.
For all WIP features, development must re-estimate the remaining
requirement in effective person-days.
It is possible (dare I say, even likely) that an estimate starts
out at, say, 10 person-days, and then 5 person-days into the effort
the remaining estimate changes is given as 15 person days.
What this says is that with what the developer learned after
the first 5 days, they now realize that the original feature
should have been sized at 20 person days, not 10.
Once again, situations like this will necessitate re-planning,
the usual rule being that NYS features may be reduce in scope
or removed, and WIP features may be reduced in scope if feasible.
Track defect arrival rates
Once the release is code complete (there is no further code that anybody is aware of that needs to be written to fully implement the features in the release), we must manage to the eventual beta and final release dates by closely monitoring defect arrival rates and comparing them to historical norms. If the arrival rates are at a sufficiently low threshold, the product may be released.
If the eventual software winds up being of poor quality,
or if the amount of time spent in testing and debugging seems
inordinately high, we must look for techniques to increase
quality before and during the coding phase.
These inevitably fall to more stringent unit testing,
and reviews of various types.
Conduct post-mortems
After development finishes,
initial estimates should be compared against the actual numbers
so that estimation accuracy can be improved on the next go-round.
Tool support is critical here.
Schedule maintenance releases
After the feature release, a series of maintenance releases will be
scheduled that fix defects only and do not introduce any new
features.
The QA group must carefully regression test each maintenance release
of the software.
This group can be managed by having them establish some form of
coverage metrics for each product, and then monitoring the % coverage,
and # of times covered, over time. This metric may start small,
but should increase over time.
Maintain a one-year plan
Often, after an initial release of a program,
the pool of developers that can work on the immediately next release
is limited.
This is because we are now dealing with a pre-existing collection of
code.
Adding a developer to the team will not be effective in the short-run,
as they will typically consume as much capacity of the other developers
in getting up-to-speed as they contribute.
The activity of growing capacity occurs on a longer time-scale
than an individual release.
To manage this effect, software development must have a business plan
that looks out over a one-year horizon, typically updated each quarter.
The plan should clearly show the existing capacity and how it is
deployed across product lines, architectural levels, and functional skills.
It should then propose a series of initiatives to build additional
capacity. These initiatives can include hiring and training developers
into specific areas, bolstering the ratios of testers or documenters
to developers, or proposing projects that will improve productivity
(such as tools initiatives, or software engineering initiatives).
Things not to overlook
We will need to watch out for the following gotchas.
Copyright © 2003, David Penny