Release planning is simply the act of determining what functionality you’re going to be able to deliver in a certain time frame. Obviously you want this data to be as accurate as possible. The greatest accuracy is gained by basing the Velocity on actual historical data.
When developing software it is a fact that we spend way to much time and effort on implementing things that will only be used sometimes, rarley or NEVER! There are several studies covering this. One example is the famous survey by The Standish Group in 2004 that says:
The Agile community are trying to solve this in SCRUM by an approach of really focusing what is important for the customer right now, instead of the approach of focusing on everything-at-once. One examplary example of a product that focused only on the features used always and/or often is the.. iPod!
One of the biggest challenges working with agile development is the paradigm shift of how we view and handle scope management.
There are two completely different approaches towards handling a project’s scope. On one side you have the plan-driven approaches which work hard to prevent any changes in the scope. While, on the other side, having the value-driven approaches which are expecting and embracing scope change. Hence, as a result, the agile way is to fix resources and schedule, and then simply work to implement the highest value features defined by the customer. This way, the scope remains flexible. However, at the same time the traditional way is trying to define the features (scope) in detail, driving the cost and schedule estimates.
Imagine a pilot flying a a-330 from Copenhagen to Japan. The plan is to land at the Narita International airport. Once airborne though, unexpected winds, other aircraft traffic, mid-ocean storms, even solar flare activity affect and alter the airplane’s course. Unmanaged, the pilot would just as likely land the plane in Seoul rather than in Tokyo. The flight plan sets an initial course and a final destination, but the process of planning ensures that the pilot takes the appropriate corrective action to get the airplane where it needs to go.
Now, just imagine what the plan is for your own project. It is telling you where you are planning of going with your project, and it is not much different from the illustration above; it doesn’t consider any of the unexpected things that will pop up and affect you and your plan. While working on the project new and/or changed requirements will occur, your senior developer lead will leave the company, the sales and marketing department promised the customers functionality that simply isn’t in the scope, and now even the market has changed its mind and is requiring your product to come in orange (instead green). Your project plan sets the initial course and final result, but it is the process of planning that ensures your project to take appropriate corrective action to get the product that the customer really wants. The bottom line here is that the plan itself is worthless, while the activity of planning is everything!