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.
Continued
on page 2
|