Akhil Mittal ">
Click here to Skip to main content
14,975,931 members
Articles / DevOps / Agile
Article
Posted 30 Mar 2016

Tagged as

Stats

7.6K views

Agile Release Planning: Considerations

Rate me:
Please Sign up or sign in to vote.
4.73/5 (6 votes)
30 Mar 2016CPOL5 min read
Here are some considerations on agile release planning.

Introduction

Image 1

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.

Image 2

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.

Image 3

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

Image 4

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

Image 5

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

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

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Akhil Mittal
Architect https://codeteddy.com/
India India
Akhil Mittal is an Ex-Microsoft MVP(Most Valuable Professional), C# Corner MVP, Codeproject MVP, a blogger, author and likes to write/read technical articles. Akhil has an experience of around 12 years in developing, designing, architecting enterprises level applications primarily in Microsoft Technologies. Akhil enjoys working on technologies like MVC, Web API, Entity Framework, Angular, C# and BlockChain. Akhil is an MCP( Microsoft Certified Professional) in Web Applications (MCTS-70-528, MCTS-70-515) and .Net Framework 2.0 (MCTS-70-536). Visit Akhil Mittal’s personal blog CodeTeddy for some good and informative articles.
LinkedIn: https://www.linkedin.com/in/akhilmittal/
Group type: Collaborative Group

772 members


Comments and Discussions

 
-- No messages could be retrieved (timeout) --