Introduction

Every time a product is released the product manager has to make sure that the limited resources, assigned to the project, are balanced out between the needs of the market and those of the stakeholders. If the planning process is not addressed correctly, important decisions may be based on intuition, which decreases the reliability of the given products. The main goal of this method is to include the stakeholders in the planning process of product releasing. This way stakeholders will have control or influence on the different features of the product. However, when many stakeholders are involved a face-to-face communication is not feasible, therefore there is a need for a decision support system, which will aid the stakeholders in communicating as well as deciding on the features of the product (Heikkilä, Jadallah, Rautiainen, Ruhe, 2010). The authors of this paper Heikkilä, Jadallah, Rautiainen and Ruhe created a method to address this very issue called SCERP. The proposed SCERP method identifies the key features of the to-be-released product. In this case the definition of feature is: a product feature as a set of logically related requirements that provide a capability to the user and enable the satisfaction of business objectives (Wiegers, 2003). At the very beginning a group of stakeholders (usually the most important ones) is chosen in order to assess the different features of the system. Each of the stakeholders is given a certain vote weight for the ranking process and all the features are ranked on a nine-point scale. "Possible criteria for prioritization are overall business value, urgency (time dependency), dissatisfaction if feature is not included in a release, risk (using an inverted scale), frequency of use" (Heikkilä et. al, 2010, p. 3). Furthermore, the features are divided into several release plans, each having a different combination of the given features. The aim of each plan is to implement the most important features of the products, while still being within the budget of the project. It is important to take into account that different features have different costs, so the perfect balance has to be found. As a final stage of the process the different plans are again assessed by the stakeholders on a nine-point scale. All of the ranking and assessment is done using an integrated tool called ReleasePlanner? a web-based decision support system. The tool enables different stakeholders from different locations to be involved in the decision making process. All of the release features and the next resulting plans are ranked using this tool. The main deliverable of this method are the different alternatives for the final release plan, which will include all the features picked by the stakeholders. To sum it up the main goal of this method is to include the stakeholders in the decision making process for next release of a certain product. As well as to support the judgment of the different features, which are to be included in the next release. The authors of this paper all come from two universities. Dr. Günther Ruhe and Anas Jadallah are both from the University of Calgary and Kristian Rautiainen together with Ville Heikkilä are from the Helsinki University of technology. Dr. Ruhe is a researcher and his main field of interest is software engineering and release planning (Ruhe, 2010). Jadallah is a former university student and now works as a Software Engineer at Sandvine inc (Jadallah, 2011). Kristian Rautiainen works as a researcher and his main research focus is software product development and planning (Rautiainen, 2010). Another one of the contributors is Ville T. Heikkilä a former Helsinki university student, who now works in Aalto University, School of Science and his specialization is software development methodologies (Heikkilä et. al, 2011).

Example

When a new product is to be launched the company has to decide on what kind of features and functionality will the product have. The aim of this method is to help in the decision making process by including the stakeholders. Therefore, a good cooperation between the stakeholders, project manager and developers has to exist for the SCERP method to be effective. The whole SCERP process is divided into five steps.

Step 1: Selection of critical stakeholders and pre-selection of candidate features

The main purpose of this method is to include the stakeholders in the decision making. Therefore, the first step is to select the stakeholders that will be included (usually the stakeholders with the most shares are picked). Each stakeholder is also given a different weight for his vote in the following stages. Next is a pre-selection phase, where the requirements and customer needs are combined to create a list of features. Several features are pre-selected from this list to be included in the next release of the product. The result of this step is the pre-selected list of candidate features. An example list can be seen in Table 1.

Table 1 List of all features from which several will be pre-selected. (The bold ones are the selected ones)

Step 2: Prioritization of features

As it can be seen in Table 1 only several features are selected to move to the next phase (the bold ones). Next the stakeholders assess the features according to the needs, priority, costs or the undertaken risk when not implementing the given feature. All of the assessment is done using the ReleasePlanner? tool as I have described in the beginning. Each feature is judged on a nine-point scale (Likert 9 point scale). The scores are then added together, as each stakeholder's vote has different value, all of the data is calculated accordingly and the resulting values can be seen in Table 2, column "Mean". The result of this step is a table with all the ranked features, together with their scores from the stakeholders. An example result can be seen in Table 2.

Table 2 - result of the step 2: table with all the features to be included in the next release, together with their scores.

Step 3: Collective effort estimation

The next step is to calculate the effort estimation of each of the features. Jørgensen (2002) describes expert estimation as the most commonly used method for effort estimation, which is conducted by experts in the given field. Important parts of the estimation process are based on non-explicit, non-recoverable reasoning processes, i.e., “intuition". Therefore expert estimation is a combination of educated judgment, which is supported by historical data, process guidelines or other data and on the other hand the intuition or "gut feeling". The experts work in groups to critically discuss the effort needed for implementing a certain feature. Using this method the experts (usually the developers) make an effort estimation for each of the features picked in Step 2. An Example Result can be Seen in Table 3.

Table 3 - Result of Step 3: table with all ranked features now including their effort estimation.

Step 4: Calculation of optimized release plan alternatives

One of the greatest advantages of this system is that it uses the optimization-based planning method, which creates not only one plan for the release, but rather several different plans. An automated algorithm creates five different alternative plans, each having a different combination of features. This way the stakeholders can decide not only which features will be included, but also what combination of features. These plans are later judged by the stakeholders. The result can be seen in Table 4 the left side. The different plans are marked as Os (on the top) and the different features are on the left side as Fs. In the center we can see the different combinations of features for each of the plans.

Step 5: Prioritization of alternative plans

The final step of SCERP is the stakeholders' assessment of the five alternatives created in Step 4. The assessment is carried out the same way as in Step 2 using the ReleasePlanner? . The result of this Step is a table with all the different alternatives together with the scores from the stakeholders.

Table 4 - Table with all the different alternative solutions for the next release

The final deliverable of this method is displayed in Table 4. The left is a table with all the alternative plans for the product release. At the top we have O1 - O5, which represents the alternatives and M which is a manual plan created just for control. On the left side there are all the features, which are to be included. The numbers 1, 2 and 3 inside the table mean 1 - the feature is to be released in the first release 2 - in the second release and 3 - the feature is postponed. At the very bottom of the left table are the percentages of how well is the specific plan fits the ideal situation (as it can be seen the first plan O1 has a 100% correlation, which means it is the most suitable plan). As for the table on the right we can see the different scores that the alternatives got from the stakeholders. This table is the final deliverable, for which the template can be seen in Appendix A. Here the most important variable is the Sum, which is the total score for each of the plans. Based on these scores the stakeholders make their final decision.

PDD

Activity Table

Concept Table

Related Literature

The main focus of this method is prioritization of the product features according to costs, value and the risk of not implementing the given feature. "Software developers are often faced with many requirements and not enough time or money to implement them all. They must therefore find a way to prioritize the requirements to select those that will add the most to a system implementation and eliminate those not worth the cost" (Jung, 1998, p. 74). Jung's idea was to create a list of features together with their value for the product release as well as the costs of the features. The resulting features are picked according to their relative cost to value ratio.

Natt och Dag, Regnell, Gervasi and Brinkkemper (2005) argue that requirements management bridges market interaction with product development. They distinguish between two types of requirements: customer wishes and product requirements. Customer wishes are expressed via the market demands and needs where as the product requirements are those that the company finds important to include for the next release. While the requirements are being gathered many of the customer wishes and product requirements have the same basics or are literally the same. Therefore, the linguistic-engineering approach, which is being used in this method, identifies the similarities in the requirements and adjusts them appropriately. After all the similarities are sorted out the relationships between the requirements are identified. Based on relationships the requirements are evaluated and sorted in a list by value. To support this method a program called ReqSimile? is used, which is used to store the list of all requirements together with their information. The main purpose of this program is to calculate the similarities between the requirements as well as to evaluate them accordingly.

"The challenge for the company is to select a set of requirements that is deliverable within their own budget and which meets the demands of their (important) customers." (Bagnall, Rayward-Smith, Whittley, 2001, 884) This model is focused on involving the customer representatives into the process of decision making. It has some important insides on which features to include, however the involvement of the stakeholders is still minimal.

Greer and Ruhe (2004) are one of the first ones to include stakeholders inside the decision making process. They proposed a method called EVOLVE. Given a set of requirements with their effort estimations and a their categorization into priorities by representative stakeholders, the method uses a genetic algorithm to derive potential release plans within predefined technical constraints. This can be considered as one of the most influential papers for the SCERP method due to the fact that these two methods are very similar.

Ruhe (2005), also being one of the authors of the SCERP method, created a very similar method to SCERP. In his paper "The Art and Science of Software Release Planning" he created a method, which focuses on stakeholders involvement in the decision making process. The specific steps of this method are almost identical to SCERP, with one exception. Ruhe introduces dependencies between the features: "two types of dependency constraints are considered: Features can be in a coupling relation called C, or in a precedence relation called P" (Ruhe, 2005, p. 49).

References

van den Akker, M. (2008). Software product release planning through optimization and what-if analysis. Information and Software Technology, 50(1–2), 101–111.

Bagnall, A. J., Rayward-Smith, V.J. Whittley, I.M. (2001). The next release problem. Information and Software technology, 43(14), 883 - 890.

Barney, S. (2008). A product management challenge: Creating software product value through requirements selection. Journal of Systems Architecture, 54(6), 576–593.

Greer, D., Ruhe, G. (2004). Software release planning: an evolutionary and iterative approach. Information and Software Technology, 46(4), 243–253.

Heikkilä, V., Jadallah, A., Rautiainen, K., Ruhe, G. (2010) Rigorous Support for Flexible Planning of Product Releases - A Stakeholder-Centric Approach and its Initial Evaluation. System Sciences (HICSS), 43rd Hawaii International Conference. 5-8 Jan, 1 - 10 Heikkilä, V. T. (2011). Aalto University. Retrieved March 25, 2012, from https://wiki.aalto.fi/display/~vtheikki@aalto.fi/Home

Jadallah, A. (2011). Software Engineering Decision Support Laboratory. Retrieved March 25, 2012, from http://www.seng-decisionsupport.ucalgary.ca/alumni.htm

Jørgensen, M. (2002). Top-down and bottom-up expert estimation of software development effort. Information and Software Technology, 46(1), 3 - 16.

Jung, H. W. (1998). Optimizing value and cost in requirements analysis, IEEE Software, 15(4), 74-78.

Karlsson, L. (2006). Pair-wise comparisons versus planning game partitioning—experiments on requirements prioritization techniques. Empirical Software Engineering, 12(1), 3-33.

Natt och Dag J., Regnell B., Gervasi V., Brinkkemper S., (2005). A linguistic-engineering approach to large-scale requirements management. Software, IEEE, 2(1), 32-39.

Ngo-The, A., Ruhe, G. (2007). A systematic approach for solving the wicked problem of software release planning. Soft Computin, 12(1), 95-108.

Rautiainen, K. (2010). Kristian Rautiainen. Retrieved March 25, 2012, from http://www.soberit.hut.fi/~kqr/

Ruhe, G. (2005). The art and science of software release planning. IEEE Software, 22(6), 47-53

Ruhe, G. (2010). Software Engineering Decision Support Laboratory. Retrieved March 25, 2012, from http://www.seng-decisionsupport.ucalgary.ca/research_chair.htm

Sharp, H. (1999). Stakeholder Identification in the Requirements Engineering Process. Database and Expert Systems Applications, 387 - 391.

Wiegers, K. (2003). Software Requirements, Microsoft Press, Redmond, WA

Appendix A

SCERP Template

This is a template for the final deliverable of the SCERP method (see Table 4), which lists all the possible plans for the next release of the product together with their respective scores from the stakeholders.