Few software products come into their full, ultimate form with the initial release. Most products begin with an initial version that contains enough capabilities to make it useful. Then they evolve as new features are added and existing features are enriched through a series of releases.
As requirements are developed for such a product, the stakeholders must allocate requirements to forthcoming releases. They need to plan a release strategy that provides the maximum customer value consistent with budgets, schedules, resources and business objectives. This article describes two techniques for planning such release strategies.
Feature roadmaps
Many project teams, particularly those that are building commercial products, talk about product features. Many features can be implemented in multiple levels of detail or enrichment. You might begin with a rudimentary implementation of a particular feature and then add more capabilities to it over time. During release planning, you can determine which features will be implemented to what extent in each release. This results in a feature roadmap.
Here's an example. Suppose we've identified eight features for our product that we would ultimately like to implement to their full extent. We are planning four releases, adding more capabilities and enriching the various features from one release to the next. In analyzing these eight features, we've identified either four or five levels of increasing capability for each feature. A feature roadmap defines which levels of each feature we plan to implement in each release.
As an example, suppose our product is a computer security package and one feature is antivirus protection. In the first release we might begin with basic virus detection on incoming email. Feature level two for the antivirus feature might provide the ability to download virus signature updates automatically. The third feature level would let the user scan disk files and disinfect or quarantine any suspicious files found. Level four could provide the option of using advanced heuristics for detecting viruses and Trojans. Finally, the fifth feature level might enable automatic reporting of virus infections and suspicious files to the vendor.
You don't plan to implement all of these feature capabilities in the first release because that would delay your ability to get your product on the market in the desired time window. So you can plan which feature levels to allocate to each intended upcoming release.
Use case flows
Use case descriptions are made up of three major elements: the normal flow, zero or more alternative flows, and zero or more exception flows. The normal flow represents the default, most typical success scenario. Alternative flows describe other successful scenarios that involve variations from the normal flow, such as an optional pathway that the user selects. Exception flows address error conditions that have the potential to prevent the use case from successful completion. Each exception is associated with a specific success flow, either the normal flow or an alternative flow.
During release planning, the stakeholders need to decide which portions of which use cases to implement in each forthcoming release. It's essential to prioritize the use cases for alignment with satisfying the project's business objectives. Within a use case, you can further prioritize the various success scenarios.
The normal flow is the starting point for implementing each use case. In addition, you must implement any exceptions associated with the normal flow. You can allocate alternative flows to the release that includes that use case's normal flow or to any other future planned releases. With each alternative flow that you implement, be sure to implement the associated exceptions. You might never implement certain alternative flows simply because their priority is too low.
Release planning involves reaching a balance between customer value, implementation cost and technical risk. Feature roadmaps and use case flow analysis are valuable techniques for planning releases by clustering related requirements into manageable packages.
----------------------------------------
About the author: Karl E. Wiegers is Principal Consultant with Process Impact in Portland, Ore. He is also the author of More About Software Requirements: Thorny Issues and Practical Advice, Software Requirements, 2nd Edition; Peer Reviews in Software: A Practical Guide; and Creating a Software Engineering Culture.
