Agile Release Planning: Considerations

Introduction

Being a product manager is not an easy task. I manage an eLearning product and I typically follow Agile’s Scrum model for the development process. Trust me, after every release, I ask only one question to myself: What more could I have done to make this release more of a success? Here are some considerations on agile release planning.

Considerations on Agile Release Planning

Release planning is one of the challenging tasks in overall scrum methodology. Though challenging, it is the most important part of the overall agile development process. A release plan (if done correctly and strategically) clears and sets the model on what actually has to be developed along with its timelines. But here is the catch: Is timeline more important than what actually needs to be developed or vice-versa? Eventually, the answer comes out to be very enigmatic. Though a release plan helps a product owner and the development team members know what has to be developed and in what time period, the question is do they actually know how much MUST be developed and how much time will it take to release a shippable product?

Release Planning: The Objective

A strategic release plan serves as a torch bearer which a team can follow as they progress. The overall goal of a release plan should be to baseline the product roadmap and team’s commitment to achieving that.

An exhaustive release plan is done against planning for logistics that may vary from meeting room size, to market standards. The objective should be to mitigate risk factors, to be able to agree and make our commitments. There are certainly other factors that need to be considered while you plan a release. Some are as follows:

• The present state of a team
• Team velocity
• Product backlog
• Existing issues
• Plan definition
• Prioritization
• Estimation gave by a team
• Logistics
• The presence of stakeholders
• Dependencies
• Clarity
• Vision
• Business value
• Communication plan

And last, but not the least, is: What is the purpose you wish to solve with this plan?

The Approach

There are two approaches in which you can plan your release, each approach is distinct yet are two sides of the same coin. The first is "Fixed timeline" and the second is "Fixed scope of work." These approaches (if adopted and implemented correctly) will solve most of the questions we encountered in the first paragraph of this article.

1. Fixed Timeline

This fixed timeline/deadline/date approach defines a line through which you cannot extend your development and your project needs to get completed by this date. There is no scope for extending or negotiating on the defined date. So if you know you can fail, fail fast. Do not include user stories in the release plan that do not fit in.

Constraints and Flexibilities

Though there is no scope for timeline negotiation, but we get a scope on the flexibility of the action items. The project team will commit to a fixed date but may not commit to a 100% functionality baseline to get completed by the end of a release. In this approach, the objective should be to achieve as much as possible and freeze the development by the end date in a way that the product is still in shippable state or is releasable. The left out work or part of user stories may move to next planning and development cycle. This approach does not allow you to be flexible on leaving the major part or functionalities of the product. All the major critical functionality should be catered in order to add value to the released product.

2. Fixed Scope Of Work

This approach, on the other hand, helps to identify what actual work you need to freeze in the release. It specifies what features and functionalities should be the part of release irrespective of the tight deadline. In this case, timelines may get extended or will be subjected to flexibility but actual work items and functionality cannot be negotiated. This approach could be taken if there are fewer features or one major functionality needs to be developed in the product that is adding the actual value to the product.

Constraints and Flexibilities

Though you get flexibility on timelines, its diversity should be reasonable. If the development cycle is around 12 weeks, then the extended time should only limit to extend by (at most) one more week. Exceeding that may again put into question the planned release. When you develop in the agile model, it is the common understanding that there may be slippages, but again, including the buffer in this kind of approach should be the part of planning.

3. Fixed Timelines and Fixed Scope of Work

This is a call you have to make being a product manager. You could be flexible about taking the challenge, but on the other hand, you need to be rigid to say, "No" to unreasonable requests.

Conclusion

The first two approaches may certainly help to baseline the critical criteria of your release. The main purpose of release planning is not "what must get done," but rather "how assertive are we to get it done." We may not end up building a perfect plan, but we should be confident about what is to be done at the end of the day. The overall objective of release planning is not to produce a well-documented plan, but rather, the value of a release plan is in the planning itself. Be Agile.

References

• Agile Best Practices: SVP Of Engineering Jeff Nielsen On "Release Planning"
• Scrum Values: The Agile Manifesto

First Published: http://elearningindustry.com/agile-release-planning-considerations