Release Planning
The development team needs to release incremental versions of the system to the customers as often as possible. Release Planning is used to discover small units of functionality that make good business sense and can be released into the customer’s environment as soon as is possible, and makes sense to the business. This is critical to getting valuable feedback in time to have an impact on the system’s development. The longer you wait to introduce an important feature to the system’s users, the less time you will have to fix it.
After User stories have been written you can use a release planning meeting to create a release plan. The release plan specifies exactly which user stories are going to be implemented for each system release and dates for those releases. This gives a set of user stories for customers to choose from during the iteration planning meeting to be implemented during the next iteration. These selected stories are then translated into individual programming tasks to be implemented during the iteration to complete the stories.
The acceptance criteria for the User Stories are also considered at this point. These acceptance tests are run during the iteration, and subsequent iterations to verify when the Stories are finished correctly and continue to work correctly.
When the project velocity changes dramatically for a couple iterations, or in any case after several iterations, schedule a release planning meeting with the customer and create a new release plan.
Release Planning Meeting
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. The essence of the planning meeting is for the development team to estimate each user story, and have the Product Owner decide the relative priority of the Stories.
User stories are printed or written on cards. Together programmers 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 until the release is ready. Individual iterations are planned in detail just before each iteration begins and not in advance.
The Release Plan
For a team new to Agile, it may seem that the amount of work scheduled in a Release is small. They key difference is that each individual User Story is completed to the point of being ready to ship – this is the Done State. By working this way there is real, tangible progress and the rate at which the team was able to deliver Stories can be used to forecast their progress in the future (Yesterday’s Weather).
Another key point about the Release Plan is that it is going to change. The Plan only represents that the team knew at that single point in time, and any changes in the business that occur or anything the people learn about the system as it is being developed will be factored in. This is crucial to being Agile – you must embrace this change rather than fighting it! That doesn’t mean that every single change will be accommodated, but they will be considered and if the Product Owner deems something a high enough priority then it should be added.
That said, you can’t simply add more to a Release – you need to remove something of equal size in order to make room. So, if a new User Story is added that has an estimate of 2 points the Product Owner must select a Story or Stories of equal size to be removed.
This is scope-based management, where the Release Date remains fixed and scope becomes variable. It is possible that the the Release Date can be changed to allow more functionality to be added. The point, though, is that you can’t simply add more functionality to be delivered in the same amount of time.
Sample Release Plan
These posts may also be interesting...
Smaller User Stories?We are the Borg
Every little thing
What problem are you trying to solve?
There’s a new look around here
Product Management
comments powered by Disqus