Different models and related release planning methods have been proposed over the last decade. In this chapter, six methods are briefly explained. All these methods use some formalized problem description. As such, they are different from informal planning, also called planning on-the-fly. More specifically, the following methods are studied:

• Greedy release planning

• Optimizing value and cost in requirements analysis [Jung ‘98]

• The next release problem [Bagnall et al. ‘01]

• The incremental funding method [Denne and Cleland-Huang ‘04]

• Software release planning: An evolutionary and iterative approach [Greer and Ruhe ‘04]

• Software product release planning through optimization and what-if analysis [van den Akker et al. ‘08]

Creating a release plan based on the information of both the feature priority and the resource consumption is often done in reality using some form of a greedy approach. Greedy algorithms are a widely applied iterative solution technique aimed at finding a good global solution by determining the local optimum choice at each stage [Cormen et al. ‘06].

What is provided here is an easy variant of the general greedy algorithm which does not consider any type of dependencies between features. If there are dependencies, the procedure needs to be adjusted correspondingly. The key principle of greedy release planning is to elaborate the features top down according to their overall value. The process starts with the feature of highest overall value. It is continued with the next best feature. The process is continued as long as the available resource capacities are not exceeded. If the addition of any of the new features violates any of the cost or resource constraints, the feature is dismissed and the next best feature is considered for inclusion. If no further feature can be added that way, the composition of the next release is started with the best of all the leftover features.

The subsequent greedy release planning procedure is based on the following assumptions:

• (4.1)      A set of features F = {f(1) … f(N)}

• (4.2)      Features consume resources called cost (1) … cost(N), respectively

• (4.3)      Features have estimated values called value(1) … value(N), respectively

• (4.4)      Planning is performed for the next K releases

• (4.5)      Each release k has total cost capacity called TotalCost(k) (k = 1 .. K)

• (4.6)      The results of planning are sets of features Release(1) … Release (K)

A pseudo-code description of the process is given in Table 4.1. Its application is acceptable if optimality is not important or is difficult to obtain. The small example presented next, although simplified, is intended to illustrate the risk you take when following the greedy technique and when primarily looking at value.

Example

As an example, a problem with N = 10 features and planning for K = 2 releases is considered. Features are assumed being arranged in decreasing order of value. The sample data is summarized in Table 4.2.

With capacities TotalCost(1) = 100 and TotalCost(2) = 90, the procedure would initially consider f(1) and assign this feature to the first release. As the whole capacity of the first release is already consumed, the procedure subsequently looks at the second release (k = 2). The remaining set F now consists of {f(2) ... f(10)}. Feature f(2) is considered first, as it has the highest value. Again, one feature consumes the whole cost capacity of that release. Consequently, there is no other feature that could be assigned to one of the two releases.

The process terminates with the two sets Release(1) = {f(1)}, Release(2) = {f(2)} and related cost ActualCost(1) = 100 and ActualCost(2) = 90. This would result in a total value of 9 and 8.5 in releases 1 and 2, respectively. However, the result obtained from the application of this procedure is far from optimal. What is (based on the given numbers) a better plan is to assign features to releases as shown in (4.7) and (4.8).

• (4.7)      Release(1) = {f(3), f(4), f(5), f(6), f(7)}, ActualValue(1) = 35

• (4.8)      Release(2) = {f(8), f(9), f(10)}, ActualValue(2) = 15

Features assigned to later releases are typically assumed to create reduced value compared to offering them in the first release. If you weight the value of the second release just half the benefit of the first one, the greedy solution achieves a total value of 9 + 0.5·8.5 = 13.25. This is a portion (9 + 0.5·8.5)/(35 + 0.5·15) = 13.25/42.5 of what is totally possible. In other words, in this case, the greedy assignment of features results in a plan having about 31.2% of the value of the best possible solution.

Even though the numbers were created synthetically, the example shows how badly the greedy approach might perform. While generating relatively good solutions on average, the solution quality is unknown for any specific case in consideration.

Jung first proposed a cost-value requirements analysis using mathematical programming [Jung ‘98]. This was an improvement of the manual inspection method proposed by [Karlsson and Ryan ‘97] who proposed to use the Analytical Hierarchy Process [Saaty ‘80] and subsequent application of intuitive inspection to determine the most valuable requirements. Instead of relying on intuition alone, Jung applied a rigorous algorithm to decide which requirements should be assigned to the next release.

Jung’s approach is to formulate the optimal feature selection as a knapsack problem (see [Kellerer et al. ‘04] for knapsack problems). The approach is applicable whenever the problem is not too large and if the only interest is on cost-benefit ratio optimization. Each feature f(n) of set F has an associated cost and an associated benefit. For a given capacity, a two-stage method was proposed. At the first stage, the maximum benefit Value* was determined as the solution of the knapsack problem having variables x(n) in correspondence to features f(n) for all n = 1...N. The knapsack problem is known to be NP-complete [Garey and Johnson ‘79]. The maximum value Value* can eventually be achieved by different compositions of feature sets. In a second phase, the set causing the least cost among the ones having maximum benefit is determined.

The next release problem as approached by [Bagnall et al. ‘01] looks exclusively at the cost per feature. There is no involvement of stakeholders in the prioritization of features because a customer gets either all or nothing. The scope of planning is just the next release. Compared to [Jung ‘98], this approach allows modeling of some feature dependencies. The specific model the authors considered assumes a list of features and a weight for each customer. Feature dependencies are expressed by an acyclic graph. Each feature has an associated cost which is the total cost created from all types of resources involved in its implementation.

Each customer has a wish list of features. Some of them are requested exclusively, others are requested jointly by a number of customers. In general, a feature can only be offered when all the enabling features are provided. These enabling features do not directly contribute to the satisfaction of a customer, but they are needed as enablers for the features being on the wish list.

The objective of planning is to achieve the highest value subset of customers under the condition that the total cost consumed for achieving this does not exceed total capacity. In general, it will not be possible to fulfill the expectations of all customers. The reason for this is that all the features consume some cost, and the total amount of cost is limited. Some of the customers are more important than others, and some of them have higher expectations than others.

The authors have mapped this problem formulation to a knapsack problem with some additional constraints. They have applied three solution methods to solve the resulting problem. On the smallest problem with 100 customers and 140 features, the integer programming algorithm was successful in providing the optimal solution. For larger problems with up to 500 customers and 3250 features, the exact algorithms were unable to find a solution, and the simulated annealing technique [Van Laarhoven and Aarts ‘87] proved more applicable.

The incremental funding method aims at delivering functionality in chunks of customer-valued features, carefully sequenced to optimize the project’s net present value [Denne and Cleland-Huang ‘04]. The method plans for what is called minimum marketable features (MMF). These MMFs are small, self-contained features that can be delivered quickly and that provide market value to the customer. The model assumes business dependencies between the MMFs. The method relies on estimates for the projected net present value of each MMF for each feasible period. It performs a greedy-type of heuristic to decide in which sequence the MMFs should be offered.

The method does not make any consideration of resources. It is very focused on the maximization of the overall financial value. The method was proven to generate good (in terms of the stated financial objective) solutions for randomly generated examples with 10 to 12 MMFs. The scalability of the method, however, was not investigated.

An iterative approach for solving release planning called EVOLVE has been offered and is described in more detail in [Greer and Ruhe ‘04]. EVOLVE conceptually differs from the former methods in the following aspects:

• It is the first method to look ahead for more than one release.

• It is based on the opinions and input of the stakeholders. It assumes prioritization of features by all selected stakeholders in terms of urgency and value of the features. The method tries to balance the conflicting stakeholder opinions to achieve the highest degree of satisfaction with the resources available.

• It considers technological constraints for coupling and precedence relationship between features.

• It assumes an evolutionary process of planning with features added and removed between all planning iterations (releases).

• As a solution method, it generates more than one alternative. Each alternative represents a trade-off between fulfillment of stakeholder expectations and the total benefit of the proposed plans.

The goal of the optimization procedure is to maximize a function G(x) defined for each plan x. G(x) is composed as a linear combination of a penalty function G1(x) and a benefit function G2(x) by a factor α as

• (4.9)      G(x) = (α - 1) G1(x) + α G2(x) (with 0 ≤ α ≤ 1)

The penalty function G1(x) defined for plan x is describing the degree of violation of the consistency property between all pairs of features for all stakeholders having expressed their priorities. Consistency is looking at the partial order between features defined by the scoring of one stakeholder in comparison to the releases the features are assigned to.

The benefit function G2(x) is based on feature scores of the stakeholders and the actual assignment of features to releases according to the plan x under consideration. The function (4.9) is supposed to become of maximum value. For the different values of α, more emphasis is lead to minimize the penalty (low value of α) or to maximize the value (high α).

van den Akker et al. applied mathematical programming to provide a solution for the next release problem [van den Akker et al. ‘08]. Their main planning criterion is based on projected revenue of the features. Different types of feature dependencies are taken into account:

• Implication (one feature can only be implemented if another feature is implemented)

• Combination (one feature only makes sense in combination with another one)

• Exclusion (either the one feature or the other, but not both of them)

• Revenue-based (revenue of groups of features is no longer just additive)

• Cost-based (cost of groups of features is no longer just additive)

The emphasis of their next release planning approach is on different scenarios related to teams needed to implement the feature. In the easiest case, there is only one team, and this team is assumed to execute all parts of the features. This option is a simplification of reality as mostly there are teams having specialized skills and expertise for doing the individual types of jobs. This situation is considered in a second scenario to have different teams with specialized expertise, but to not allow any type of exchange between teams. Finally, different teams and exchange between teams is considered as well as hiring external personnel or extending the release date.

Managerial steering mechanisms are used to run what-if analysis for changed project parameters. The individual models and their possible integration ended up in an integer linear programming problem. The authors developed a prototype tool based on the ILOG CPLEX software library [ILOG]. The largest problem studied included 99 requirements and 17 teams. Near optimal solution of proven degree of optimality could be generated for that problem.

For two of the methods described in this chapter, a comparative analysis is done in this section with what is called on-the-fly planning, which performs release planning exclusively based on intuition and some form of communication. On-the-fly planning assumes an experienced product manager and is often used in practice. The results of this approach are considered to become more risky, the more complex the planning situation becomes (size, number of resources, dependencies, number and involvement of stakeholders, planning criteria). In Chapter 6, another comparison is done with a new method called EVOLVE II.

In Table 4.3, the comparison between methods is related to some of the key aspects of release planning:

• Time horizon considers the number of releases looked ahead when planning for the releases.

• Objectives looks at the number and the definition of the objectives considered for planning.

• Stakeholder involvement asks for the degree of involvement and the number of stakeholders involved. This aspect of the comparison also includes the type of involvement.

• Solution method considers the way actual release plans are generated.

• Quality of solutions is judged against the stated objectives.

• Feature dependencies looks at the dependencies between features, which are considered by the respective methods.

• Human resource constraints ask if there is the possibility to handle constraints related to human resources.

• What-if analysis asks for the explicit support of running different scenarios with varying problem parameters.

• Integrated tool support looks at the possibility for the user to enter and maintain online all the relevant release planning information.

Over the last decade, there has been progress in the capability to solve product release planning problems more systematically. However, there is still lack of methods with associated tools maintaining a feature repository, thus allowing ongoing updates of features and their data. This, on the other hand, is in general the strength of existing general-purpose commercial tools. These tools, however, mostly do not aim at quality of release decisions. Another current deficit is the lack of industrial evaluation of the proposed methods. Most methods have just been initially evaluated by small or randomly generated test examples.

To evaluate the current state-of-the-practice of product release planning, a survey and 25 semi-structured interviews with product and project managers were performed. All these subjects were involved in product release planning in their organization. The companies were from different domains with different types of offerings (software products, services, embedded products). In addition to these interviews, practical experience as reported in [El Emam and Madhavji ‘95], [Carlshamre et al. ‘01], [Carlshamre ‘02], [Amandeep et al. ‘04], [Ruhe and Saliu ‘05], [Lehtola ‘06], [Momoh and Ruhe ‘06], [Ebert ‘07], [Cao and Ramesh ‘08], and [Lindgren et al. ‘08a] was included. Most recently, a comprehensive product management survey was conducted by [Paquet ‘09]. Some of these results are included in this analysis, too.

The results reported from all these efforts are providing some significant findings, but do not claim to be general practices or statistically significant. In what follows, the most significant observations are summarized.

The role of the product manager and its impact for the success of a product was studied by [Ebert ‘07]. The product manager is often titled the mini CEO because of the broad range of responsibilities and the need to link marketing, sales, engineering, finance, quality and operations. Following [Paquet ‘09], 90% of the 789 responding companies have a dedicated product manager. More than two thirds of the companies report having even more than one.

The results of an empirical field study at Alcatel covering 178 projects of one business unit revealed that duration (time to market), schedule adherence and product quality improve with strengthening of a coherent product management role [Ebert ‘07]. It was demonstrated that with a focus on systematic and rigorous product management techniques, cycle time in the business unit was reduced by 36% compared to the stated initial baseline.

Project delays are defined as the relative delay of the actually achieved milestone compared to the milestone committed at project start [Ebert ‘07]. It was shown that project delays were reduced by 80% as the result of the application of systematic and rigorous product management techniques. The same level of improvement was achieved for quality, defined here as the percentage of total defects found after handover of the product to the customer compared to the totality of reported defects found during the product life-cycle.

Performing an electronic survey, 12 product and project managers answered detailed questions about the expected impact of performing a more rigorous release planning process. Their answers were given on a five-point scale ranging from very strong to no impact. The results of the survey are shown as Figure 4.3. More than 70% of the respondents expected from more rigorous release planning processes a strong or even very strong impact on a better match of customer expectations. Similarly, about 25% expected very strong impact on a reduced rate of failed projects and products.

Typically, companies have a process in place, and the process is also largely followed. There was no evaluation possible at this point about the quality of this process. When asked for potential improvements of the existing processes, a number of directions have been mentioned. Only those are given, which were mentioned by at least 50% of the participants:

• Stronger emphasis on strategic objectives

• More objectivity of the planning process

• Broader involvement of stakeholders, especially of customers

• Stronger consideration of resources and budgets required

• Consideration of risk factors

• Ability to run proactive what-if analysis

• Documentation of the process for better transparency

It is difficult to find the “right” set of features. Almost all respondents agree that this is typically not achieved. Cases have been reported in which features have been offered which were never used. In parallel, attractive features requested by customers have been missed (for example, the copy & paste feature in the first versions of the iPhone). Lack and quality of stakeholder involvement was considered one of the key reasons for both of these weaknesses by the participants.

The decision about inclusion of features is partially based on the anticipated value of the feature. However, the value of a feature is mostly hard to predict and often time-dependent. A given feature might create value if delivered in the next release but might be of much less value afterward. Another difficulty comes into play when looking at features in conjunction. Certain combinations of features create additional value, which is considered hard to model and hard to predict.

In most cases, offering of features in a new release is largely a response to (key) customer demands or fixing existing deficiencies of features. This type of reactive planning mode only acts on demand and makes it unlikely that new, innovative or even breakthrough features are taken into account. However, these are the features that potentially create a competitive advantage.

Proactive planning mode tries to look ahead with features not yet known or expected. It is less applied than reactive planning. And in case proactive planning was performed, it was seldom done following an organized and controlled process.

Prioritization of features is considered key input for release planning. The current practice is to look into the next release. [Lehtola ‘06] interviewed 25 practitioners from seven software companies in order to understand the existing practices. It was found that prioritization practices are informal and prioritization methods are not widely used in the industry. However, they appear to be similar mental models that practitioners use as a basis for their prioritization decisions. The most common hidden idea in the practices is to evaluate implementation costs versus the business value gained by implementing the feature. In addition, the companies aim to utilize their product development resources evenly as a function of time used for the implementation [Lehtola ‘06].

The survey [Paquet ‘09] analyzed 715 responses on the number of product releases per year. Including major and minor releases as well as patches, the average number found was 4.4 releases, with a distribution shown in Figure 4.4.

In terms of release times, there are two fundamental types of release planning problems: (i) release planning with fixed and pre-determined time intervals for implementation, and (ii) planning with flexible intervals. In the second problem type, the decision about the length of the interval to implement the assigned features is not pre-determined. Release dates are often driven by business logistics. External events such as peak sales periods or the capability of the user to upgrade the running system are considered for deciding the release date. The same is true for features and releases offered by main competitors

There is a general lack in consideration of more specific resources other than just effort. One reason for that is the lack of a qualified estimation procedure. This is partially due to the strong variation between software features, where it is more difficult to find similar cases from the past as, for example, in the case of hardware features. The existence of an effort database with effort, and feature-related attributes is more the exception than the rule. The same is true for post-mortem analysis of project performance where former estimates are compared with actual efforts and reasons for deviations are analyzed.

A study of requirements repositories in telecommunications domain by [Carlshamre et al. ‘01] analyzed that only about 20% of the features were singular or independent of each other. The authors discussed six different types of possible requirements interdependencies (all of them are studied in more detail in Chapter 5). Ideally, the user would receive support in the elicitation, formulation and verification of feature dependencies. Among the companies interviewed, dependencies have been largely ignored. This causes later changes in the implementation process (when detected later) or makes certain features impossible to use for some time (when detected after delivery).

There is a continuous need for re-planning due to changed or new requirements, modified constraints, or priorities [Stark et al. ‘99]. Once the model and the initial project data are made available to apply a computer-supported solution procedure, the actual re-planning becomes easier to perform as well. Even after implementation commences, requirements could change or projects may be heading toward crisis because of unrealistic release plans.

The frequency of re-planning strongly varies between organizations. This has a lot in common with the volatility of features (less volatile features imply less need for re-planning) and the stability and maturity of the overall development process (stable and more mature processes tend to require less re-planning).

Re-planning in general is considered important. The actual re-planning process is often coordinated by the change control board. This process and the resulting decisions are largely based on intuition. In some cases, acceptance of new features also implies hiring more people to get it done by the pre-determined release date.

For the degree of change, there are limits to how much can be modified of an already announced product feature. An at least 90% conformance level to features already committed to customers was reported. This is equivalent with the limitation of the degree of change by 10% of an announced product release after its implementation has started.

Most companies maintain a variety of products. The survey [Paquet ‘09] revealed that the average product manager is responsible for 3.3 products. Resources for implementation of product features are largely allocated on a per-product base. Usage of resources across products is more the exception than the rule. In most cases, each product is largely planned independent from the other. If synchronization is needed between the products, then this is often tried to be achieved on-the-fly, which makes it hard to achieve the goal without additional delays.

In case of embedded product where software is an (essential) part of what is creating the overall value of the product, release planning for software features was reported determined by the cycles of the hardware features.

Different types of tool support are used to facilitate the planning and to implement its results. The support ranges from spreadsheets, requirements management tools (such as DOORS®, Requisite Pro®) to the different forms of project management tools (such as Microsoft Project®, Primavera®). The survey conducted by [Paquet ‘09] asked for the disposition in terms of importance and usefulness for a variety of tool functionality. The results of the 686 responses are shown in Figure 4.5.

According to [Paquet ‘09], Microsoft technologies (specifically the Office suite) are the most commonly used tools to document requirements. From the 25 conducted semi-formal interviews, tools are seen to be limited in two directions: (i) they do constitute the status quo and do not offer any new ideas or strategies, and (ii) tool support is more happening on a micro level than on the strategic or macro level.