Instead of looking into the planning of just one product, often a suite of related products is offered. This increases not only the functionality, but also allows for better customization and selection of the most appropriate products of the suite. As the development of a product suite typically follows the same paradigm of staged development, the problem of release planning for one product can naturally be generalized into a problem with multiple products. At this point, a product suite can be either software or hardware related or a mixture of both.

The higher complexity of planning for a product suite results from the demand that the individual products of the suite should be offered simultaneously. If this cannot be achieved, then a substantial part of the overall value expected from offering a product as a suite is jeopardized, and the release of the suite needs to be delayed until the last product is finished.

The process of synchronization of individual release cycles is illustrated in Figure 14.2 for the case of three products P1, P2 and P3. The planning process considers the next three releases. These release dates of the suite are called R1, R2 and R3, respectively. Without synchronization, the release dates for each product are expected to be different. Consequently, if the products of the suite are to be offered in conjunction for each release, the latest release date among the products determines the release date of the suite.

This situation is assumed to change after synchronization has been applied. As a consequence, for each release, the individual product’s release dates become the same and the overall release date of the suite is expected to be earlier than without synchronization. This can be achieved by better allocation and utilization of the resources needed for the three products. Instead of a local perspective (just looking at the individual products), a global perspective ensures that the best result for the whole suite is achieved.

In addition to synchronization, additional complexity in the case of planning for multiple products results from more complex structures of resource utilization. Some of the (human or non-human) resources can be specifically assigned to one product only, while others might be used across products. This creates additional complexity in the planning process. The ability to manage this additional complexity adds to the advantages of more systematic planning for the case of one product as described in Chapters 5 and 6.

In what follows, the key ideas of reducing the roadmapping for multiple products problem to the modeling assumptions of solution method EVOLVE II are described. Applying the problem template, the problem is characterized as follows:

In order to avoid additional and complex notation, the idea of the re-formulation is illustrated by a simple example. For that, a set of 12 different candidate features is considered. Utilizing the modeling capability of defining groups of features, the features are arranged linearly in correspondence to their grouping. That means, with N1, N2 and N3 being the number of candidate features for products P1, P2 and P3, respectively, there are in total N = N1 + N2 + N3 candidate features in consideration. Features f(1) ... f(N1) correspond to the first product, features f(N1+1) ... f(N1+N2) to the second and f(N1+N2+1) ... f(N1+N2+N3) to the third product.

If there are features that occur in more than one product, this can be easily modeled using the coupling relationship. As the feature in fact is implemented only once, the effort is shared in equal portions between the products where it is included. Even though this is a simplification of the truth, it could serve as a reasonable initial approximation.

The whole transformation approach is illustrated in Table 14.1 for the case of planning with three products. For simplicity, the three products are assumed to have N1 = 3, N2 = 4 and N3 = 5 features, respectively. There is one (core) feature which is supposed to be the same for all three products. The case of one joint feature for all three products is modeled by introducing coupling relationships. As shown in Table 14.1, features f(1), f(4) and f(8) are coupled to express the fact that the features are actually the same. Applying ReleasePlanner™, this whole process is supported by the option to edit coupling and resource constraints by using Microsoft Excel®. As a result of this process, globally optimized feature sets are obtained.

From Table 14.1 it also becomes clear that resource types 1, 2 and 3 are specific to products P1, P2 and P3, respectively. Resource type 4, however, is used across the individual products. Its proper allocation is of key importance to achieve proper synchronization between release dates and to achieve maximum stakeholder satisfaction from the proposed product-suite roadmap.

The traditional view of release planning favors delivery of added or revised pieces of functionality (called features or requirements) on top of an evolving product in the best possible way. For a feature to become part of a product release, it needs to be implemented and thus consumes resources. The core question at this point is how to utilize the resources to provide the best (in terms of total stakeholder satisfaction) combination of pieces of functionality. What is completely lacking in this view is the quality aspect of the resulting release product(s). Quality here refers to one or more of the non-functional requirements such as reliability, security, performance or maintainability.

While there is the implicit assumption that effort is related to a fixed level of (standard) quality, it is also assumed that increasing this level of quality results in the increase of the related effort to achieve this quality (under the premise that there are no changes in the process or the technology applied). [Regnell et al. ‘08] have studied this question for the case of mobile-phone development. In their approach, they combine cost and benefit views into a roadmap of each important quality indicator for the particular domain.

Independent of how precisely quality is defined, there is a quality-effort dependency as illustrated in Figure 14.3. The curve indicates how much more effort is expected for achieving a higher than standard level of quality. In general, the increase in the total effort for implementation is expected to grow stronger than just linearly, eventually even exponentially. To determine the specific function, goal-oriented measurement programs [Basili et al. ‘01] need to be set-up collecting the data related to effort and the quality aspect under consideration. Of course, the overall assumption at this point is that the defined standard quality measure is not yet the maximum achievable.

Depending on the granularity of the planning, the specific effort attributed to higher target levels of quality can be feature-related or can be related to the whole product release (as a form of cross-cutting concern). The latter case can be modeled by introduction of a dummy feature, which consumes effort but has no direct contribution to functionality.

With this formulation given, the problem no longer is just to find a plan implementing the most comprehensive and attractive set of features. Instead, the problem now becomes a trade-off analysis where the balance needs to be found between providing the most comprehensive and attractive functionality and the level of target quality of the product release. In consideration of the additional amount of uncertainty resulting from determining the quality-effort dependency, just the next release is considered for planning.

Applying the problem template introduced in this section again, the problem can be characterized as follows:

The problem can be approached by a two-staged process. Both stages follow the EVOLVE II process structure. At the first stage, quality considerations are not addressed explicitly. The assumption is that the estimated effort includes effort devoted to achieve the “standard” level of quality. As a result of this phase, a release plan xl is received with specific sets of features in each release. Following the first stage, increased target levels of quality are considered in the second stage. Under the premise that the total capacities are not changed, higher levels of target quality imply a reduction in the amount of resources available for feature development, consequently reducing the number of features that can be offered.

As an illustrative example, five different alternatives for allocation of cost between generating functionality (for new or revised features) of standard quality and cost devoted to achieve higher than standard target quality levels are considered. In Figure 14.4, the left-most bar represents the traditional view of allocation. This means ignoring cost spent for additional quality, that is, the view of just looking at functionality of standard quality. With each increase in the amount of effort exclusively devoted to improve quality of the release product, this effort is no longer available for providing the original amount of functionality. Consequently, less functionality can be offered. The resulting trade-off curve with the five points G1, G2, G3, G4 and G5 generated from the five different effort allocation scenarios from Figure 14.4 is shown in Figure 14.5.

The five alternative points are non-comparable in the sense that an improvement along one criterion can only be made by getting worse in terms of the other. G1 represents the alternative incorporating the highest amount of functionality. However, the (estimated) quality level is lowest among the five alternatives. On the other hand, G5 (corresponding to alternative 5) is best when just looking at quality, but lowest in the amount of functionality offered. In total, the different alternatives provide an important input to the human decision-maker who can now better balance between the two competing criteria and select the alternative representing the most appropriate compromise under the given circumstances.

Agile development differs from the more plan-driven approaches in putting less emphasis on up-front plans and strict plan-based control, while relying more on mechanisms for change management during the project [Nerur and Balijepally ‘07]. Does this mean that the suggestion is to make planning obsolete? No, the idea is not to replace planning completely by communication and self-organization, but to plan just as much as needed. While this sounds very reasonable, the most difficult part is to find out how much is needed.

[Cohn ‘06] presented methods and techniques for agile estimation and planning. To reduce the overall effort for product release planning, one can do several things such as reducing the effort spent on estimation, reducing the scope of planning, reducing the number of people involved, or reducing the level of detail. While all these considerations will likely contribute to an overall effort reduction, it will eventually also reduce the quality of the results. But where is the “sweet spot”, the best compromise between effort invested and quality of results gained out of it?

One of the most frequently used agile methods is called Scrum [Schwaber and Beedle ‘02]. Originating from the early work of [Takeuchi and Nonaka ‘86], Scrum has matured into a project management technique for iterative development. It consists of three phases: (a) pre-sprint planning, (b) sprint and (c) post-sprint meeting [Cohen et al. ‘04]. During the pre-sprint planning phase, features and functionality are selected from the release backlog and placed into what is called the sprint backlog (a prioritized collection of tasks to be completed during the next sprint). During the sprint phase, the Scrum team implements a working version of software that meets a small set of high-priority customer needs. Finally, during the post-sprint meeting, developers demonstrate working software to their customers, adjust their priorities and repeat the cycle. The proposed decision support is for the phase of pre-sprint planning.

The Scrum phase of pre-sprint planning is considered for reformulation applying the problem template again. The decisions to be made are related to prioritization and selection of features considered for implementation during the next sprint.

Agile development is associated with many claims such as the achievement of higher job satisfaction, higher productivity and increased customer satisfaction. A rigorous empirical analysis revealed that, so far, there is insufficient evidence for these claims [Dyba and Dingsoyr ‘08]. Most of them are not confirmed yet and are relying on explorative case studies or even anecdotal evidence. [Moe and Aurum ‘08] study the decision-making process in Scrum. The authors found that a prerequisite for introducing Scrum is the alignment of decisions on a strategic, tactical and operational level.

In [Heikkilae et al. ‘10], a method is described trying to combine the strengths of Scrum with a stakeholder-centric decision-making process exploiting fact-based decision-making wherever appropriate. The same idea was applied in this section when complementing Srum by the modeling capabilities given in EVOLVE II. As described in detail in Chapter 6, the systematic planning method gives a lot of flexibility in how to instantiate the process (granularity in terms of objects, type and number of stakeholders, time intervals, type and number of resources considered, number and type of constraints, type and depth of analysis done). It depends on the concrete situation how far the planning should go. Running an optimization for proposing best combination of features to be implemented next has the potential to improve decision-making of the Scrum master and the product owner.

For any product or service company, one of the key questions for success is: How do you ensure a strong competitive position in the future? Products are expected to contain all the mandatory “standard” features. But in addition to them, unique selling propositions are sought to distinguish from competitors and to attract additional customer interest. Often, the differentiating features might have a higher risk of implementation or risk of customer acceptance or are more cost-intensive. How to balance between being unique on the one hand and encountering high risk and increased cost on the other hand?

In a product developing unit, one needs to find an answer to the question: Which are the key product differentiators when compared to our main competitors? The question investigated in this section is: How to select product release feature sets toward becoming the most competitive? This planning objective is called competitiveness and is based on some assumptions which need to be fulfilled to run the proposed process:

Following the template used previously, the problem of planning for competitiveness of products can be characterized as follows:

There are two main phases to model the above planning for competitiveness. The first phase is to define your key competitors to become the stakeholders in the subsequent planning process defined by EVOLVE II. The difference to “traditional” release planning is that stakeholders are not really asked for their opinion (as they probably would not be willing to tell you). Instead, the degree of differentiation compared to the competitors is based on the degree of knowledge about their future products. This evaluation can be an individual or a collective one.

To accommodate the inherent uncertainty in this judgment, an additional factor is introduced. This factor describes the degree of certainty in the competitor evaluation performed for the candidate features. For feature f(n) and stakeholder stake(p) (representing competitor p), the factor certainty(n,p) defined on the interval (0,1] describes the perceived degree of certainty in the evaluation. The more confident the acting product manager is in the evaluation of being different from the competitor p with the proposed feature f(n), the closer certainty(n,p) comes to 1.

The second main conceptual step is to define the criterion of planning. One criterion in this case should be the degree of differentiation. What that means is that the nine-point scale of scoring is defined from 1 being extremely low to 9 being extremely high in terms of the level of differentiation from the competitor under consideration. If the feature under consideration is completely new with nothing comparable expected from that competitor, then a score of 9 would be appropriate. On the other hand, if the feature is expected to be offered more or less in the same way or even better by the competitor, then a low score needs to be applied.

What results out of all this is a planning objective function similar to the one introduced in Section 5.9. The only difference of this application scenario is the multiplicative factor given to all the stakeholder scores for each feature. With all the existing modeling capabilities expressing dependencies between features and describing the consumption of (limited) resources remaining the same, the objective of planning still is to maximize the number of stakeholder feature points. However, the interpretation of features points is different because now it is the measure of the degree of differentiation to customers.

Project portfolio planning is focused on the selection of the right projects versus performing projects right. The latter is the focus of project management. A project portfolio is a collection of all projects and programs of an enterprise or business unit to be performed. Consequently, planning for project portfolios includes the balancing of resources, business needs, business risks and changing parameters for maximum return on investment.

Project portfolio planning is part of Project Portfolio Management [Levine ‘05]. Prioritization among a larger set of candidate projects is expected to help find the right mix of projects in terms of their value, expected benefit, risk and alignment with the organizational business objectives. Once started, constant project monitoring needs to be done to support the decision if the project should still remain in the pipeline even if it no longer serves the company’s best interest.

Following the template, the problem is characterized as follows:

[Levine ‘05] introduced five maturity levels of project portfolio management:

Following [Levine ‘05], the current maturity status of organizations on project portfolio management is low (being 1 or 2 for most of the organizations analyzed). Among others, project portfolio planning can also be applied to the IT projects. A survey [www.scribd.com ‘09] of Fortune 1000 CIOs found that they believe, on average, that 40% of their IT spending brought no return to their organization. 20% of the investments is wasted, which represented an estimated annual destruction of value totaling $600 billion US. A more systematic and qualified planning process is necessary to decide where to invest and to what extent. Considering the different forms of IT spending as individual projects, the provision of optimized portfolio alternatives generated from the application of EVOLVE II might help to at least reduce the amount of wasted investment.