Introducing The Release Definition Challenge

Software products are rarely fully finished in one single shot. Rather, they are developed and improved over time, in iterative development cycles (often called releases). Each such cycle typically includes a mixture of features, bug fixes, change requests, technical refactorings, etc.

Whereas the typical product life cycle used to span several years, software builders operate today in a much more challenging environment. They need to transform into highly optimized release-driven organizations, delivering product release after product release at a startling pace. Due to an ever-faster rush-to-market race, they are urged to deliver on time in order to be ready for a product’s window of opportunity. Additionally, the innovator’s dilemma (Christensen, 2003) is no longer a dilemma, as innovation is required in order to survive in a highly competitive market. Increasing the speed by which innovations are brought to market is thus crucial: a competitive advantage is the result if a software builder is able to respond quickly to new market needs and customer requests.

In their quest for innovation and ultimate customer satisfaction, software builders are installing all kinds of processes for idea harvesting (e.g. IdeaScale). Various actors (prospects, customers, competitors, internal stakeholders and many more) bring many different innovative ideas for improving and extending the product. Emerging new technologies, such as Web 2.0, that facilitate collaboration and interaction, result in even more exciting ideas (e.g. IdeaStorm).

As a consequence, software builders are now confronted with an ever-growing number of potential wishes, ideas and requirements to be included in the next release. Implementing all these at once is impossible, because of limited available resources, time restrictions or conflicts in the wishes and needs formulated by different stakeholders. Choices have to be made and priorities have to be set.

Release definition —the decision of what to include in the next product release and the definition of upcoming releases in a product roadmap— fulfills a strategic role. Making incorrect choices may significantly impact the competitiveness of a software builder.

Given this strategic relevance, it is remarkable to observe that release definition is not yet considered an explicit and standalone software engineering discipline. Rather, release definition is handled in a fragmentary way, scattered across many different software engineering disciplines. For example, requirements prioritization in the domain of requirements engineering, prioritized product backlogs in agile methodologies such as Scrum, and configuration management and version control in the domain of release management all address the release definition topic in one way or another.

In Sirris we offer a service to optimize the release definition process. Parts of it have been published in the seventh chapter of the book Building Blocks of Agile Innovation. Do not hesitate to contact us is you would like to know more about it.