(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.
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.
Estimates in IterationPlanning is 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.
- 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
- Are estimates done at the UserStory level or the EngineeringTask level?
Following PlanningExtremeProgramming, a ReleasePlan gives the business people (the OnsiteCustomer) a way of thinking about sets of UserStory~s that togeother tell a good story to the market.
See: UserStory, EngineeringTask, PlanningGame
EditText of this page
(last edited May 30, 2001)
FindPage by searching (or browse LikePages or take a VisualTour)