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 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 has to be developed, but again the question is that do they actually know how much MUST be developed and how much time will that take to release a shippable product?
Release Planning: The Objective
A strategic release plan serves as a 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.
An exhaustive release plan is done against planning for logistics that may vary from what should be the room size of meeting to market standards. The objective should be to mitigate risk factors, to be able to agree and make our commitments. There are certain other factors that need to be considered while you plan a release. Some are as follows:
- Present state of team.
- Team velocity.
- Product backlog.
- Existing issues.
- Plan definition.
- Prioritization.
- Estimation gave by team.
- Logistics.
- 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, these twos 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.
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 does not fit in.
- Constraints And Flexibilities.
Though there is no scope for timelines 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 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 very 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 but 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 which may again question the planned release. When you develop in agile model, it is common understanding that there may be slippages but again including buffer in this kind of approach should be the 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 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 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:
- Agile Best Practices: SVP Of Engineering Jeff Nielsen On "Release Planning”
- Scrum Values: The Agile Manifesto
