| release | The release designator for the software release being planned. The first digit is changed when a more substantial upgrade is being planned (usually accompanied by a larger marketing campaign - once every couple of years or so). A change in the second digit is used to denote a more standard feature release (every six to nine months or so). |
| design start | The date detailed specification and high-level design activity starts. Before this date, features have only been to the point of a one paragraph description. Based on these initial descriptions, initial sizings were made and an initial plan was put together. At design start, each of the features is specified in detail, and preliminary software designs are proposed where needed. |
| code start | By this date, most of the features should have been fully specified and designed (if appropriate). The developers then begin coding and unit testing. The delta in brackets refers to the number of working days for the phase ending on this date (in this case, design). |
| development cut | Also referred to as "dcut". The date at which coding ends and system test and debug begins. We test if development cut is achieved by asking each developer if they know of any remaining code that needs to be written for the release to be feature complete. If the answers are all "no", then dcut is achieved. The delta in brackets refers to the number of working days for the phase ending on this date (in this case, coding). |
| beta availability | The date the release can be shipped as a beta. Prior to this date the release was being alpha tested. As of this date, the release is not perfect, but it is no longer embarrassing to let some others have a look with the caveat that it is not to be used in production. The delta in brackets refers to the number of working days for the phase ending on this date (in this case, alpha test). |
| general availability | The date the release can be made generally available to new and existing customers. The significance of this date is that prior to it, the previous release of the software was shipped to all new customers. After this date, the new release will be shipped to all new customers. The delta in brackets refers to the number of working days for the phase ending on this date (in this case, beta test). |
| estimates (stochastic) |
All measures stated as
mean±sdev
in this section are assumed to be stochastic variables whose distribution
is Normal with the given mean and standard deviation.
The mean is a number whereby half the time we will expect the realized
actual number to be over, and half the time under.
The quantity mean+sdev is a number whereby we expect the realized
actual number to be less than or equal to it 84% of the time.
There are many other possible ways of giving estimates. For example, giving a 40% best case and 60% worst case. For less-sophisticated, easier to get going release planning, much of the benefit is available from using only a single number for an estimate. We recommend that those new to release planning start with this approach. In this case, there should be agreement when soliciting the estimates that they should all be comparable. For instance, that they should all be 80% worst case estimates (i.e., the actual number is expected to be worse only 20% of the time). In this case, when the release plan balances capacity and requirement, it will then indicate there will be a better than 80% chance of hitting the dates. |
| estimates (deterministic) | When the plan is given in a deterministic mode, all estimates are assumed to be taken on a worst case basis, with the confidence level described in this field. |
| as at |
The plan is up-to-date as-at the date given.
Also indicated is the current phase we are in,
the number of working days elapsed in that phase,
and the total length of the phase in working days.
A plan change would not modify this date. Rather, a plan status update would modify the date. A status update is performed by re-estimating the stochastic quantities given an advance in time. - To re-estimate feature requirement, we first determine the status of each feature (whether the feature is done, work-in-progress, or not-yet-started). For each work-in-progress feature we ask the assigned coders how much time they have spent to date on it, and a re-estimate of how much remaining effort they think it will take. - To re-estimate coder capacity we decrease the available days, and ask coders to re-estimate their vacation and work factor, possibly using information as to what their realized actual work factor has been to-date during the coding phase. |
| average coders | The average number of dedicated coders available per-day during the remainder of the coding phase. A "dedicated coder" is an idealized worker who spends 8 uninterrupted hours each and every working day working at nothing more than coding new features into this release. Flesh-and-blood coders are not expected to live up to this ideal. The units are in dedicated coder equivalents per day. |
| remaining coding capacity | The total number of dedicated coder days (see average coders) available during the remainder of the coding phase. |
| remaining coding requirement | The total number of dedicated coder days (see average coders) required for the remainder of the coding phase to implement all the features in the plan. |
| delta | Remaining coding capacity less remaining coding requirement. Negative delta indicates a danger of slipping the dcut date by this many effective coder days divided by the average number of effective coders available per day. |
| A+B features | Remaining coding requirement and delta for all the features listed in the plan, including both the more essential features (the A list) and the less essential features that it would not be overly painful to drop from the plan if the need arises (the B list) (see priority of features). |
| A features only | Remaining coding requirement and delta for just the essential features listed in the plan (the A list), and excluding the less essential features that it would not be overly painful to drop from the plan if the need arises (the B list). (see priority of features). |
| confidence | Various confidence levels. We would expect to slip dcut or the projected GA date by no more than the indicated amounts, with this level of confidence. |
| DCUT slip | Estimates with the given level of confidence for the worst-case number of working days expected to slip (-'ve numbers) or be ahead of (+'ve numbers) the planned dcut. |
| projected generally available | Estimates with the given level of confidence for the worst-case generally available date for the release. This is computed by assuming that any slip in dcut is augmented by a matching slip in the following phases. |
| coder | The name of the coding resource. Anybody on this list is capable of, and available to, do coding work on this release. |
| class | The type of the coder. Certain types of coding resource would be expected to have different ranges of work factors than others. This is (in some way) an explanation of the work factor. |
| days | Working days remaining during the coding phase to work on the release. Coders not available for particular days in the coding phase (with certainty) will have lower numbers. The maximum is the number of days left until dcut. |
| vacation | An estimate of the number of vacation days for this coder during the remainder of the coding phase. |
| work factor |
An estimate of a multiplicative factor used to convert working days into
dedicated coder day equivalents
for the remainder of the coding phase.
By definition, on average during the coding phase this coder
is expected to put in 8 hours times this work factor of
uninterrupted hours working on nothing but coding new features
into this release.
The work factor does not take into account any differences in productivity (this is accounted for in the feature estimates that take into account who will be assigned to each given feature). |
| effective days | An estimate of the total number of dedicated coder day equivalents this coder will work during the remainder of the coding phase. |
| to date | The (measured) actual number of dedicated coder day equivalents that this coder has put in so far during the coding phase. This "to date" and the "to date" on the requirement side are two different ways of slicing the same effort spent, similar to the two entries in a double-entry accounting balance sheet. |
| w (act.) | Based on the to date measure, the actual measured work factor for this coder so far during the coding phase. |
| A features | For the given coder, the difference between their available effective days and the number of effective days assigned to them in the plan for the remainder of the coding phase. Negative numbers indicate an over-commitment. This column is for the A priority features only. |
| A+B features | For the given coder, the difference between their available effective days and the number of effective days assigned to them in the plan for the remainder of the coding phase. Negative numbers indicate an over-commitment. This column is for both the A and B priority features. |
| totals | The sums of the columns. The ± numbers are the square root of the sums of the squares. |
| unassigned | The number of dedicated coder days for features that have not yet been assigned to any coder. Always negative. |
| final totals | The total over or under -commitment of dedicated coder days for all features in plan. These must tally with the delta measures in the current status summary section. |
| fid | A unique feature identifier used for cross-referencing back to this feature. |
| description | A brief description of the feature, intended to be an evocative mnemonic. |
| pre-req | Indicates a dependency amongst features for the purposes of release planning. If any of the listed pre-requisite features are removed from plan, then the features listing them must either be removed as well or have their scope changed significantly. |
| priority | A letter-grade assigned for the priority of a feature. Letter "A" is the highest priority. If possible, all higher priority features should be completed before any work is begun on lower-priority features. "A" features are assumed to be very painful to have to remove from the plan. "B" features are considered expendable in a crunch, but nice to have if they can be managed. |
| promised | A list of (external) customers who have been promised this feature and are counting on its delivery. |
| assigned | The coders that are assumed will work on this feature. The sizing initial estimate and remaining estimate is made assuming that this set of coders will be working on the feature. If the set of assigned coders changes, the sizing estimate should be re-considered. If this field is blank, no decision has yet been made and the sizing estimates assume the average coder's productivity. |
| initial |
The initial estimate (as at the start of coding) of the total number of
dedicated coder days
it will take for the
assigned
coders to complete this feature during the entirety of the coding phase.
The purpose of this column is to act as a historical baseline for comparing estimates against actuals. It should represent the best sizing available at the start of coding. If subsequent to the start of coding the scope of the feature is explicitly modified, this column may be adjusted accordingly to remain comparable. All other changes in sizing estimates after coding start (including assigned personnel changes and refined estimates) should be made into the remaining column (even if no work to-date has been done on the feature). |
| status |
One of four possible status values for the feature.
- DONE: The feature has been fully coded, unit tested, and reviewed. - CC: (Code Complete) The feature has been fully coded and unit tested. - WIP: Work-in-progress. - NYS: Not yet started. Generally features that are NYS are vulnerable for removal from the plan. |
| to date | The (measured) actual number of dedicated coder day equivalents that has been put into working on this feature from the start of the coding phase to the as-at date. This "to date" and the "to date" on the capacity side are two different ways of slicing the same effort spent to-date, similar to the two entries in a double-entry accounting balance sheet. |
| remaining | A re-estimate of the number of dedicated coder days it will take for the assigned coders to complete this feature during the remainder of the coding phase. |
| spec |
Indicates if a specification for this feature is available,
has been reviewed, and is approved.
- A blank entry indicates that a specification document is not yet available. - An "x" indicates that the specification has been reviewed but rejected. - A "p" indicates the specification is available, but has not yet been reviewed (pending). - A "y" indicates either the specification has been reviewed and is acceptable, or that no specification is required and the reviewers agree. A specification should come in the form of a document that describes all of the (even potentially) user-visible aspects of the feature. When available, the document should be provided as a link from this field. |
| design |
Indicates if a software design for this feature is available,
has been reviewed, and is approved.
- A blank entry indicates that a design document is not yet available. - An "x" indicates that the design has been reviewed but rejected. - A "p" indicates the design is available, but has not yet been reviewed (pending). - A "y" indicates either the design has been reviewed and is acceptable, or that no design is required and the reviewers agree. A design should come in the form of a document that describes how the feature will be implemented into the software, and that includes a task breakdown used to come up with a feature sizing. When available, the document should be provided as a link from this field. |
| test | Indicates how many test cases for this feature are available and have been successfully executed. The entry is in the form x/y/z, where z is the total number of test cases planned, y is the number that exist and have been run against the feature, and x is the number that have been successfully run. |
| docs |
Indicates if end-user documentation for this feature is available,
has been reviewed, and is approved.
- A blank entry indicates that documentation is not yet available. - An "x" indicates that the documentation has been reviewed but rejected. - A "p" indicates the documentation is available, but has not yet been reviewed (pending). - A "y" indicates either the documentation has been reviewed and is acceptable, or that no documentation is required and the reviewers agree. |
| totals |
- For
status
gives the number DONE relative to the total number of features.
- For spec, design, and docs, gives the percentage of features with a "y" in this column. - For all others, gives a sum. The ± numbers are the square root of the sums of the squares. |
| version | The plan's version number (not the number of the software release). A given release plan will go through many different revisions before the software is eventually shipped. |
| last plan change | The date of the last change to the feature list or dates. There are two kinds of revisions to the plan: revisions that take place routinely to bring the status up-to-date (see as-at), and revisions that reflect changes to the plan (feature additions, deletions, and scope changes, and date changes). This date is the last time the latter (the plan) was changed. |
| last approval | If the last approval is after last plan change, the plan is valid. Otherwise the change is understood to be just a proposal. |
| last modified | The last time this document was modified in any manner. |
Copyright © 2001, David A. Penny. All rights reserved.