Release Planning

A release
planning meeting is used to create a release
plan, which lays out the overall project. The release plan is
then used to create iteration plans for each individual iteration.It
is important for technical people to make the technical decisions and
business people to make the business decisions. Release planning has a
set of rules that allows everyone involved with the project to make
their own decisions. The rules define a method to negotiate a schedule
everyone can commit to.The
essence of the release planning meeting is for the development team to
estimate each user story
in terms of ideal programming weeks. An ideal week is how long you
imagine it would take to implement that story if you had absolutely
nothing else to do. No dependencies, no extra work, but do include
tests. The customer then decides what story is the most important or
has the highest priority to be completed. User
stories are printed or written on cards. Together developers and
customers move the cards around on a large table to create a
set of stories to be implemented as the first (or next)
release. A useable, testable system that makes good business sense delivered early is
desired.You
may plan
by time or by scope. The project
velocity is used to determine
either

how
many stories can be
implemented before a given date (time) or how long a set of stories
will take to finish (scope). When planning by time multiply the number
of iterations by the project velocity to determine how many user
stories can be completed. When planning by scope divide the total weeks
of estimated user stories by the project velocity to determine how many
iterations till the release is ready.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. No
one can control all 4 variables. When you change one you
inadvertently cause another to change in response. Note that
lowering quality to any less than excellent has unforeseen impact on
the other 3 variables that may not become obvious until your project
slows to a crawl just before the deadline. In
essence there are only 3 variables that you actually want to change.
Management can set 2 of those variables and the third will be set by
the development team. Also let the developers moderate the
customers desire to have the project done immediately by hiring too
many people at one time.