In a previous posting I wrote about the need for creating a detailed release plan, which will serve as a features guide and time frame guide. The following sample release plan was presented.

Looking at this plan, you can see that it contains a lot of details. Where does one get all these details from? Especially when we operate in an Agile environment. We after all don’t collect all the detailed requirements upfront.

If you agree with me that some discovery work needs to be done before any project can be properly planned and started, than read on, because all the information you need to create this detailed release plan can be captured in one, two hours (initial discovery meeting) with the customer.

User stories, the foundation of the release plan
A key requirement for creating a product release plan is that the initial requirements collection (discovery) session must have been conducted already. This requirements collection meeting will provide the foundational material to create a release plan.

Please realize that the feature areas (themes), epics and many of the stories identified in this initial session will still be high level. No detailed requirement such as business rules, data elements will or should be collected at this juncture. Leave that for just before the first iteration is about to start. To create the initial release plan (using the basic information from the initial discovery session), you therefore must employ deduction and estimation techniques, as well as your domain and software engineering knowledge. Once again, it will not be perfect, but this plan will be extremely useful for the development team and the rest of the organization (resource planning, marketing).

Why a release plan is needed, long before development work starts
We all know that when a project is identified by the business (in moderate size organizations or larger), no Scrum team has been formed yet to work on it, and that we therefore simply don’t know who will work on the project.
Companies, typically, have several projects on their overall product roadmap. All these projects need a detailed release plan, and proper resource planning must be conducted to know which resources will be assigned to work on these various projects. Release and resource planning therefore take place weeks or months before the actual development work starts.
The various release plans assist Product Management and Development Management in significant ways, long before a Scrum team starts to  actually work on the project.

In essence, a release plan being a Product Management tool is not something the development team needs to see or worry about. The development team works with the prioritized product backlog. A reasonable release plan will facilitate the creation of the prioritized product backlog.

What do you need in order to create a reasonable release plan?

• The initial themes, epics and stories
• The delivery date of the product (when the customer wants it)
• The established length of the iterations in your company (if iteration lengths fluctuate, choose a length and convince the future Scrum team that will work on the project to adopt it)
• The average velocity of Scrum teams in your organization (choose the velocity of teams that work in iterations cycle with the same iteration length as you choose for this project)

If you have all the above variables, you will be able to create a reasonable release plan. Once more, please be cognisant that product release plans are very high level plans. We must realize that this plan will certainly change.

However, refrain from changing a release date agreed on with the customer or a release date imposed on you based on your domain of operations. For example, a Student Management System may need to be released by April 30th, because schools are getting ready to process transcripts, and need the product to be ready.

There is no way the software team can delay the release date, in this case. If for some reason the team is in danger of not meeting the release date, the Product Owner must negotiate with the customer to remove certain stories from the current release and schedule those stories for a subsequent release.

Dangers of Not Having a Release Plan
The dangers of not having a product release plan are in my opinion:

  • Not knowing which features areas or features to build first

If no time is spent identifying the feature areas that have more value for the customer, we may focus on the areas that the customer may not want.
Why spending time building something that the customer may reject?

  • Not knowing when the product must be released exactly

If no time was spend identifying when the customer wants the software to be operational, the project will quickly become a low priority project and no resources will be assigned to it. Or on the other hand, the team will start working without really having a sense of urgency. No fixed release date, means no time box.

  • Not knowing when development should really start (because you don’t know when the product must be deliver)
  • Not knowing when resources should be made available for the project, because we don’t know when we must start in order to hit the deadline.

Who creates the release plan?
The Product Owner must be the one to create and groom the release plan. Product Owner must ensure a knowledgeable development lead ( if dev team was not yet officially formed or available) is present while creating and reviewing the release plan.

I have seen many successful implementations of release plans in several organizations. Being structured and organized always helps. Main stream Agile is now ten years old and we have learnt a lot in the last decade. Remember the time when some Agilist were advising you wrongly not to create any documentation at all. Similar to that, you will have many Agilist tell you not to create release plans.

My advice is simple. If you have a small organization, with just a handful of teams, you probably could survive without a detailed release plan. If you have more than a handful of teams, then you should seriously consider proper release planning.