|
Continued from page 1
 Individual iterations are planned in detail just before each iteration begins and not in advance. The release
planning meeting was called the planning game and the rules can be found at the Portland
Pattern Repository.
When the final release
plan is created and is displeasing to management it is tempting to just change the estimates for the user stories.
You must not do this. The estimates are valid and will be required as-is during the iteration
planning meetings. Underestimating now will cause problems later. Instead negotiate an acceptable release plan.
Negotiate until the developers, customers, and managers can all agree to the release plan.
The base philosophy of release
planning is that a project may be quantified by four variables; scope, resources, time, and quality. Scope is
how much is to be done. Resources are
|
how many people are available. Time is when the project or release will be done. And quality is how good the software
will be and how well tested it will be.
Management can only choose
3 of the 4 project variables to dictate, development always gets the remaining variable. Note that lowering quality
less than excellent has unforeseen impact on the other 3. In essence there are only 3 variables that you actually
want to change. Also let the developers moderate the customers desire to have the project done immediately by hiring
too many people at one time.  |
