Release Plan (Formerly called CommitmentSchedule.)
	* Estimate each UserStory in IdealProgrammingTime.
	* Determine your ProjectVelocity in IPT per iteration.
	* Arrange stories into 2-4 week iterations.  
	* Put higher-risk and higher-priority stories in early iterations. 
	* Make sure that the system is recognizably running after  the first iteration. 
	* Put only as many stories into each Iteration as your resources will permit.
	* Put a rubber band around the pile of stories for each iteration.
	* Put a different colored card on top with the iteration number and a theme.

The stack of iteration bundles is your ReleasePlan.

Redo your ReleasePlan every few Iterations, in the light of what you have learned. Expect it to change - but not too much. (I question this. You're saying that at the beginning of the project I'm spending time doing estimates of UserStories that will be delivered at the end of the project, and those estimates are going to be sufficiently accurate that the ReleasePlan won't change "too much" over time? This sounds like BigPlanUpFront to me. --BillSeitz)

A ReleasePlan is time-driven. There is a definite heartbeat to developing this way. This is reflected in the team's vocabulary- First Tuesday Syndrome, Third Thursday Syndrome. For a development culture more driven by a large number of changes coming into the commitment schedule, try a WorkQueue instead.

----
A couple of questions that have me confused.
	1. Is planning and estimating done on an iteration by iteration basis or for the project as a whole?  What I mean is, do we only plan for the next iteration and push everything else back to be reviewed again in the following iteration?
	2. Are estimates done at the UserStory level or the EngineeringTask level?

''Estimates in IterationPlanning are done at the EngineeringTask level, estimates in the ReleasePlan are done at the UserStory level. The ReleasePlan estimates are initially done in advance, but they are likely to be adjusted every iteration.''

----

Following PlanningExtremeProgramming, a ReleasePlan gives the business people (the OnsiteCustomer) a way of thinking about sets of UserStory~s that together tell a good story to the market.

See: UserStory, EngineeringTask, PlanningGame

----

In his book ExtremeProgrammingExplored, William Wake mentions ZeroFeatureRelease as a way to test your release mechanism. The first release does contain software, but no features. You go through the complete release process as a way of testing it. Do people actually use this? -- FrankNiessink

----

There are two important things not mentioned here. Firstly, thanks to the unavoidable uncertainty in every project, we must EXPECT the release plan to change over time as we and the customer learn. Secondly, we should measure progress against the release plan objectively - using acceptance tests (ie, anything that doesn't pass the test is 0% complete) and update the release plan after every iteration. People often mistakenyl think that release planning only goes on at the start of the project. It goes on throughout the project as the circumstances evolve.

Check out http://parlezuml.com/blog/?postid=18 for a better explanation of release planning vs. iteration planning

----
CategoryCustomer CategoryPlanning