Introduction
![introduction]()
Image credit
Being a product manager is not an easy task. I manage an eLearning product at Magic Software Inc. 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.
![strategy]()
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 to know what and in what time it has to be developed, again the question is do they actually know how much MUST be developed and how much time it will take to release a shippable product?
Release Planning: The Objective
A strategic release plan serves as the torch bearer to which team can follow and progress. The overall goal of a release plan should be to baseline the product roadmap and team’s commitment to achieving that.
![objective]()
An exhaustive release plan is done against planning for logistics that may vary from what should be the room size ofa meeting 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 problem you wish to solve with this plan?
The Approach
There are two approaches by which you can plan your release, these two are distinct yet are two sides of the same coin. First is “Fixed timeline” and a 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.
- Fixed Timeline.
![fixed time]()
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, 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 a shippable state or is releasable. The left out work or part of user stories may move to the next planning and development cycle. This approach does not allow you to be flexible on changing the major parts or functionalities of the product. All the major critical functionality should be tailored in order to add value to the released product.
- Fixed Scope Of Work.
![scope]()
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 very few features or one major functionality needs to be developed in the product that is adding 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 this may again 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 a part of planning.
- 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 the unreasonable request.
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 is there to do 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 release plan is in its planning itself. Be Agile.
References:
Read more articles on Agile: