Agile Release Planning Best Practices

Our clients often ask us: how do you know when to release a software product or website? No product manager wants to release if functionality is broken or not usable, yet good business mandates regular progress to users and stakeholders. How do you know your product is good enough without being gold-plated?

Knowledge and information management system deployments are commonly delayed in a quest for perfection. Releasing too early will yield a “so what effect,” where your end users don’t see sufficient value, or will potentially alienate them via frustrating bugs or lack of functionality. Releasing too late delays your business value and often creates a situation where meaningful analytics and feedback are lacking from your design and development cycle. The “just right” release date requires an understanding of your system, your users, and your organizational culture.

Agile Release Management - Enterprise Knowledge Visual
The graphic above displays a playful take on Agile release management for building an airplane. Starting from the paper airplane prototype, each release of the product is usable and, because it can “fly,” it can be validated with customers. This data informs what gets built next and maximizes your return on investment. Customer feedback from the example above might have included requests for passenger seats for the glider or the speed and long-distance range of the jet airplane. The advantage of releasing your product in this iterative manner and collaborating frequently with your customers is that by the time the end product is built, you know that it provides value to your customers without investing money on features they won’t use. This approach can be used with any type of product – software, a marketing campaign, or even a business process.

In our experience, there are two common approaches to release planning. Consider the four project success factors: quality, resources, time, and scope. Most teams want to hold resources and quality constant, so they can release based on:

  1. Fixed date with variable scope: this is a traditional Agile approach. This is typically the best approach when you want to release on a regular schedule (e.g., monthly or quarterly), when you have a complex or long-term product or when you need lots of customer feedback. This approach also allows for emergent requirements as the product is developed and helps to manage risk of putting out functionality users do not want or need.
  1. Fixed scope with variable timeline: this is a traditional project management (or “waterfall”) approach. It is the best approach when requirements are known fully up front, the timeline is relatively short and customer input is not needed until the project/product is done. Truly knowing all requirements up front is very unusual, so this type of approach will only work well for a small percentage of products.

Let’s say you decide to take an Agile approach. How do you make sure you give your team just enough time to develop working software that brings value to users?

  1. Show users value in your minimum viable product. From a business planning perspective, the concept of a minimum viable product suggests that you develop just enough functionality for users and customers to provide feedback. This feedback will let you know if you’re on the right track and will help you prioritize functionality in your next release. This approach could involve prototyping or a smaller release audience like in a private beta – the key is to pick whatever approach is the best test for the market viability of the product.
  1. Create a “Definition of Done” checklist for a release to set technical standards. From a technical perspective, these pre-determined criteria help you decide if your product/platform functions well enough to go live. The best criteria are clear and measurable and are referred to throughout the development process, not just prior to release. A few examples of criteria include a) No critical priority bugs, b) Passes quality assurance tests, c) Passes performance testing (bandwidth requirements, load distribution, etc.), and d) Passes user acceptance testing (UAT) with a minimum number of users.

Overall, taking an Agile approach to release planning for the majority of your products will ensure you gather user feedback on a regular basis and build the right functionality in the future. Thinking strategically about your minimum viable product will ensure you are testing the right functionality with users, while a definition of done checklist for your release will make sure your product is working properly.

Taken together, these principles will ensure you release with the right functionality at the right time, maximizing success for your product. Of course, no release is complete without careful planning regarding change management, adoption analytics and messaging. This will ensure that end users understand the benefits of your product and that your project team is accurately able to measure success.

Need some additional help planning your product release or working in a more Agile fashion? Email us at [email protected].

Joe Hilger Joe Hilger A senior technologist with expertise in search, content management, and unstructured information. He focuses on creating solutions that have a meaningful impact for his clients. More from Joe Hilger »