Define: Release Plan 2


What’s a “Release Plan?”
Release planning is usually the first step when launching an agile project. It involves requirements gathering, developing use case examples and filling the product backlog with large user stories/high level requirements. A high level requirement in Agile is often referred to as an “epic.” Although the release plan shown below is very detailed and even includes requirements estimates for low level user stories, most of the time this is NOT necessary. In this case the project is relatively small and estimating the requirements for the entire release was not a significant task. If you are working on a larger project it is advised to provide estimates only for epics in order to get a general sense of the velocity needed per iteration.

The best strategy with creating the release plan is to start out with high level groups of features and epics. When the epics are too large to estimate size and complexity, break them down into smaller epics. Only as epics approach iteration planning will they need to be broken down into user stories. This is referred to Just-In-Time-Planning, a component of Lean principles. Requirements descriptions should initially be much higher representations of a group of user stories which will be broken down in the future. The example below is fairly broken down but is also fairly small in size.

The total release planning stage should take 8 hours or 1 business day. 4 hours should be for filling the product backlog and 4 hours should be for developing the sprint themes and creating a timeline/burnup chart. Time boxing this planning stage encourages the level of detail in the requirement descriptions and discussions that is appropriate for this stage of planning.

Setting the Vision
Often times while ordering the backlog arguments come up out of what should be on top. This usually makes a very nice opportunity to set the vision of project. When ordering the backlog we are really showing what is the most important thing to accomplish out of the project. During this exercise, team members begin to really understand the importance of setting the vision for the project. If the vision is not clear the order of the backlog usually doesn’t make sense.

Mike Cohen, an Agile software PM, describes how retiring the term “Release Plan” altogether might be called for due to the overwhelming confusion that often comes with release planning. As one commenter suggested “Milestone Planning” might even serve as a much better term. He gives a great illustration of the essence of a Release Plan’s goal as being able to say “Six months from now, we’re 90% sure we’ll be able to deliver between 150 and 200 story points of work.”

Release Plan Deliverables
The goal behind a release plan is to determine an estimate of required velocity needed in order to complete the project on time. Or it is to determine an estimate of the required time based on the available velocity. The outcome of a release planning session should be an ordered product backlog and a list of iteration themes describing the groups of functionality that will be created in each.

Usually features would NOT be allocated to each iteration in release planning. That is what iteration planning is for. In the example given below features are allocated to each sprint to show what features would most likely will be created. This was done in order to adapt to a customers demand for deliverables by date. Release planning can be used to adapt to older expectations but try to avoid allocating features to iterations during release planning because it may create a sense of contractual obligation in the customer’s mind. Most likely these features will be moved, added, subtracted, updated which is why in Agile we merely create an iteration theme and not deliverables by date. If epics are allocated to iterations during release planning, it should be very clear that the features may be changed in each iteration throughout the project.

During release planning once we have an idea of how much velocity we need/have we can estimate how many iterations will be needed and if an iteration-zero is necessary. Then a general theme name and a summary of the type of functionality which will be created during a sprint should be given for each sprint. Technology selection, information, and other pre-project design functions are better suited for an iteration called iteration zero than it is for release planning.

Iteration Zero
Often times people get quite carried away with design work because it has been such a strong part of traditional development approaches. Iteration zero is an opportunity to mitigate some of the necessary design work which must be done before any functionality can be developed. There are extremely rare cases where more than 1 iteration is needed for design. There should only be 1 iteration 0 and iterations should not ever be negative numbers.

Each iteration should deliver a group of valuable working software. Iteration zero delivers value but not value which can be readily seen by the customer which is why it should be used only if necessary and only be 1 iteration long. The whole point of the agile methodology is to gain feedback from features developed as soon as possible in order to deliver the most value first. If your team finds itself having more than one iteration zero for design purposes you may need to investigate your development life cycle as it applies to test driven development and whether or not your team is really using Agile.

In Agile we don’t need to get every detail of every page or functionality up front. If iteration zero is used it should be to develop the basic information architecture, database design patterns, technology selection, etc. in order to start iteration 1 which will deliver a group of usable and valuable features and functionality. Often times the reason iteration zero is greater than 1 iteration is because too much is being designed. The finer details of design should be included with the features when they are being created. Keep in mind that feature specific design should be included with the creation of the feature when estimating its size and complexity.

Josh Woodcock, PMI-ACP

release_plan_example.pdf
backlog_template.xlxs









Leave a comment

Your email address will not be published. Required fields are marked *

2 thoughts on “Define: Release Plan

  • Aryo

    I don’t think there is anything wrong with the move it farrowd’ philosophy. In fact, isn’t that exactly the reason why agile is so powerful of a methodology? If something is in danger of not being finished, the team is agile enough to either adjust the scope of the story or swap in another shorter story.Simply due to the nature of development work, very rarely does every story get completed in any given sprint. We have to deal with fires, newly created high priority tasks, and other necessary housekeeping chores that are not considered when planning out a future sprint.If a story is partially completed, it should stay out of the release branch for the current sprint and saved for the next iteration. When doing point roulette, just make sure any carried-over work gets discussed and the remaining points from that story are considered. As long as the product manager & stakeholders are informed early in the process that something will slide, this shouldn’t be a problem.Agile is built specifically for these types of issues

    • admin Post author

      That’s an interesting point of view. If your team is putting out fires often, could it benefit your team to assign one team to putting out fires and another team to focus on development?

      Also are the stories you are working on changing during the iteration? If so would it be more beneficial to decrease the iteration length in order to give your business partners the flexibility to make changes while still enabling the team to focus on completing their work?