The Agile Release Planning Process

Instructor: Bob Bruner

Bob is a software professional with 24 years in the industry. He has a bachelor's degree in Geology, and also has extensive experience in the Oil and Gas industry.

While Agile development relies on planning iteratively at the team level, most software organizations require a higher level of release planning for large releases. In this lesson we explore the basic concepts behind the release planning process.

Agile Release Planning

It is not surprising that most managers have issues dealing with uncertainty in their operations. Having created a business plan and made key investment decisions based on those plans, managers want to understand how their current operations measure up against that plan. On the other hand, Agile development philosophy embraces uncertainty as part of software development, and suggests that planning too far in advance leads to diminishing rewards. Software organizations using an Agile methodology typically rely on some Release Planning processes to try and bridge this gap.

Team Velocity and Release Planning

The key planning metric for any iterative Agile team is its Velocity. A team's velocity is simply the average number of story points that it has proven it can deliver in a single iteration. While a team's velocity may change over time, for example due to changes in the team makeup, longer term planning using the known or estimated velocity of every team working on a release can be attempted.

In order to use each team's velocity in release planning, it is also important to consider a few basic scheduling issues. For example, some cross-team dependencies may require work on one team to occur before work on another team can begin. These schedule dependencies, as well as external factors such as upcoming trade show commitments, must all be factored in when trying to use individual team velocities as part of release planning.

Scope, Schedule and Resource

When putting together a release plan, most organizations will rely on some form of analysis based on Scope, Schedule and Resource constraints. Understanding which of these is considered to be least or most flexible will form a starting point for scheduling discussions, and will help drive any planning trade-offs that may be required.

In determining its planned release scope, each product owner will typically be asked to provide a prioritized wish list of features. As multiple teams will be generating potentially competing lists, it is useful to include a common valuation of the features being discussed, which can be used for relative comparisons when determining the final release scope.

If a release schedule has been mandated, then each team can use its own velocity to provide a list of its scope that fits the schedule. If the schedule is truly flexible, then it is still useful to compile a list of features above and below a cut line for the release. The full list of features above the cut line can be used to ensure that some minimum level of functionality that meets the overall release goals will be delivered.

In this preliminary planning phase there is often an assumption that a known team structure exists. If teams are being reformed then it will be more difficult to determine each team's velocity for the planning purposes. Estimates of velocity should be made, but those estimates will need to be monitored against actual numbers as the schedule progresses.

Release Planning Meetings

All of this information will be reviewed at a Release Planning Meeting. At the initial meeting each team will present its key scope expectations, and possibly an initial mapping of functionality planned to be delivered through the first couple of iterations.

The most important part of the meeting is communication, and one of the key results of the initial planning meeting will be to ensure that any dependencies between teams are well understood. It is often the case that agreement on the full release plan cannot occur in a single meeting. Initial plans are likely to require some adjustments as discussions at the planning meeting uncover issues, and teams will be asked to revise their plans as necessary to handle those modifications.

One or more release planning meetings will then be needed to review and set a final plan in motion. It is important that the last meeting bring full closure to the release plan agreements. This is typically done in a similar manner to agreements made at an iteration meeting. Each team is asked to Commit to the overall plan, and the meeting should end only when any team's outstanding issues have been addressed to the satisfaction of that team.

To unlock this lesson you must be a Study.com Member.
Create your account

Register to view this lesson

Are you a student or a teacher?

Unlock Your Education

See for yourself why 30 million people use Study.com

Become a Study.com member and start learning now.
Become a Member  Back
What teachers are saying about Study.com
Try it risk-free for 30 days

Earning College Credit

Did you know… We have over 200 college courses that prepare you to earn credit by exam that is accepted by over 1,500 colleges and universities. You can test out of the first two years of college and save thousands off your degree. Anyone can earn credit-by-exam regardless of age or education level.

To learn more, visit our Earning Credit Page

Transferring credit to the school of your choice

Not sure what college you want to attend yet? Study.com has thousands of articles about every imaginable degree, area of study and career path that can help you find the school that's right for you.

Create an account to start this course today
Try it risk-free for 30 days!
Create an account
Support