The document discusses various techniques for prioritizing software requirements for release planning, including: 1. MoSCoW prioritization which categorizes requirements as Must have, Should have, Could have, or Won't have. 2. Cumulative voting where stakeholders distribute a total of points between requirements. 3. Analytical Hierarchy Process which involves pairwise comparisons of requirements to determine their relative value and cost. 4. Visualization techniques help analyze prioritization results, like cost-value diagrams and distribution charts. Integer linear programming can also be used to optimize for highest value within budget constraints.

1. Software Product Management Release planning
Lecture 5
Sjaak Brinkkemper
Garm Lucassen
12 september 2014

2. Introduction
•Recall from the first lecture:
“Release planning is the process that deals with the set of requirements of each release in order to plan, manage, and launch the release.”

3. Balancing forces: technology push vs. market pull
Henry Ford:
If I'd asked customers what they wanted, they would have said "a faster horse".

4. Balancing forces: short-term vs. long-term
•Consider the following situation:
–You have a beautiful product roadmap for the coming three years, which you believe will lead to a competitive advantage and consequently to more new customers
–Existing customer: “I need functionality XYZ within 3 months. If you don’t include that in the next release, I will go to your competitor.”
–This functionality does not fit with your roadmap. What to do?
–The release planning decisions ought to be based on strategic guidelines

5. Balancing forces: product organization vs. development
•The selected requirements need to account for the capabilities and capacity of the product organization
versus
•The selected requirement need to be compliant with time and budget constraints and architectural considerations

6. Why is release planning important?
•Release planning is more than the administrative planning process of releases or “selecting an optimal subset of requirements for realisation in a certain release” (Carlshamre, 2002). It also involves
–Translating the roadmap into requirements to be developed
–Decision-making of what will be developed and what not
–Negotiating to resolve conflicts between stakeholders
•Good release planning
–Improves communication
–Reduces risk and uncertainty
–Supports better decision-making
–Ensures trustworthiness

7. SPM Competence Model

8. SPM Competence Model

9. Release planning
•Requirements prioritization
•Release definition in depth
•Scope change management
•Release definition validation
•Build validation short overview
•Launch preparation

10. Agenda
•Introduction
•Requirements prioritization
•Release definition
•Scope change management
•Release definition validation, build validation & launch preparation

11. Release types
•Update Package - A package that promotes a customer’s configuration to a newer configuration.
–Major Update Package - A package that contains bug fixes and new functionality that changes large aspects of the product, such as the architecture and underlying data model.
–Minor Update Package - A package that contains bug fixes and new functionality that does not change the product structurally.
–Feature Update Package - A package that contains only new features.
–Bug Fix Update Package - A package that contains only bug fixes and no new functionality.

12. Release tree
No universally applicable convention, but in general:
X.y = significant changes
x.Y = improvements

13. Heartbeat principle
•Implement a corporate release heartbeat
•Advantages are:
–Clarity for defining a release agenda
–Professional internal atmosphere
–Professional image
•Whereas otherwise …
–An irregular release process creates unpredictability in the company
–Unclear agenda, eg. “What shall I do today? Did I accomplish anything this week?”
–Unprofessional, stakeholders’ playing ball

14. Stakeholders (1)
•Product management
–Responsible and accountable for contents release
•Development
–Responsible and accountable for carrying out the release project within cost, time, and quality constraints
–Collaboration in scope change management
•Marketing & sales
–Provide input (themes, market trends) for release

15. Stakeholders (2)
•Company board
–Provides input for release (Release Initiation)
–Provides resources (financial, personnel) for release
–Approves Release Definition
•Other internal and external stakeholders
–Provide input for release

16. Agenda
•Introduction
•Requirements prioritization
•Release definition
•Scope change management
•Release definition validation, build validation & launch preparation

17. Requirements prioritization (1)
Goal: to select those requirements, which maximize satisfaction of company objectives related to the software release
–Fitness with product roadmap
–Maximized value/cost ratio
–Stakeholder satisfaction
–Feasibility with respect to time and resources
Need to select what to develop
–Stakeholders (usually) ask for way too much
–Balance time-to-market with amount of functionality
–Decide which features go into the next release
And what if stakeholders disagree?
–Visualize differences in priority
–Resolve disagreements

18. Triage
•Before applying prioritization techniques: perform triage
–Origins in medicine
•Some requirements must be included
•Some requirements should definitely be excluded
•That leaves a pool of nice-to-haves, which we must select from.

19. Requirement evaluation concepts (1)
•Importance
–Business value / benefit
•Absolute values (“How much extra money will we earn when we develop this requirement?”)
•Relative values (“Requirement A will generate two times as much revenue as requirement B.”)
–Penalty if not developed / harm avoidance
•Absolute values (“How much money will we lose due to decreasing sales if we do not make a web version of our product?”)
•Relative values (“The harm done will be higher if we leave out the requirements submitted by customer C than customer D.”)

20. •Cost of development
–Monetary: in € or $
–Workload: in man days
–Relative effort: “Requirements 1 costs twice as much as requirement 2”
•Development risk
–Requirement volatility / stability (“Is the requirements likely to change?”)
–Development difficulty (“This requirement concerns a new technology, which our developers have never used before.”)
Requirement evaluation concepts (2)

21. Prioritization: estimation before analysis
•Can we?
–Yes, we can estimate
–No, it will not be perfect
It is better to be roughly right than precisely wrong.
John Maynard Keynes
•Estimation types
–Range: “Development time take between 5 and 7 mandays”
–Relative value: “Requirement A is 3 times as important as Requirement B”

22. Estimates do not improve themselves
•Estimates improve
–When we collect data
–Reflect on estimates
–Remove variability
•Making decisions
•Keeping team stable

23. Simple prioritization techniques
1.MoSCoW
2.Cumulative voting
3.Numerical assignment
4.Top-10 requirements
5.Binary search list

24. MoSCoW
•M - Must have this requirement in the current release, in order to make it a success.
•S - Should have this requirement if possible, but is not critical for the release.
•C - Could have this requirement since it is a nice to have, but it should not affect anything else.
•W – Won’t have this requirement this time but possible would like to have it in the future.

25. Cumulative voting (or: 100$ test)
•Each stakeholder distributes a total of 100 points (or $ or € or coins) on the requirements.
•The product manager sums up the points and presents the derived ordering of the requirements.
•Facebook example:
Requirement
Consultant
Sales
Board
Total
Layout customization
10
20
5
35
Dislike button
30
20
25
75
Picasa integration
25
20
20
65
Profile visit stats
25
30
35
90
Email integration
10
10
15
35

26. Numerical assignment (or: priority groups)
•Each stakeholder groups requirements into different priority groups (e.g. critical, important, useful).
•The product manager sums up the weights (e.g. critical = 9, important = 3, useful = 1).
•Facebook example:
Requirement
Consultant
Sales
Board
Total
Layout customization
useful
important
useful
5
Dislike button
critical
important
important
15
Picasa integration
important
important
important
9
Profile visit stats
important
important
critical
15
Email integration
useful
useful
useful
3
9+3+3

27. Ranking (or: sorting)
•Each stakeholder sorts requirements in decreasing order.
•Product manager sorts requirements by considering the average or median priority of each requirement.
Consultant
Sales
Board
Average
Requirement
Rank
Req. 2
Req. 4
Req. 5
3,67
Email integration
4
Req. 3
Req. 1
Req. 2
2
Dislike button
2
Req. 4
Req. 2
Req. 3
3
Picasa integration
3
Req. 1
Req. 3
Req. 4
1,67
Profile visit stats
1
Req. 5
Req. 5
Req. 1
4,67
Layout customization
5

28. Top-10 requirements
•Each stakeholder selects 10 favorite requirements.
•Product manager sorts requirements by considering fairness and satisfaction of stakeholders.

29. •Based on binary search tree sorting algorithm
•Example
Binary search list
Prioritized requirement list:
•Requirement 4
•Requirement 2
•Requirement 3
•Requirement 1
•Requirement 5
Req 2
Req 5
Req 4
Req 3
Req 1

30. Binary search list: Facebook example
•Email integration
•Dislike button
•Picasa integration
•Profile visit stats
•Layout customization
•Integration with Google calendar

31. Binary search list: tool support
•Paper written by former MBI student Thomas Bebensee
•Excel spreadsheet
•Bebensee, Th., Weerd, I. van de, & Brinkkemper, S. (2010). Binary priority list for prioritizing software requirements. Proceedings of 1the 6th International Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ 2010), LNCS 6182.

32. Questions?

33. Prioritization: advanced
•Wiegers’ prioritization model
•Analytical hierarchy process / cost value approach
•Integer linear programming

34. Wiegers prioritization model
•Prioritization based on value, cost and risk
•Karl E. Wiegers (1999)
•More information: http://www.processimpact.com/

35. Evaluation concepts
•Relative value
–Relative benefit
• Low benefit: 1, high benefit: 9
–Relative penalty
•Estimation of penalty for not developing the requirement
•Low penalty: 1, high penalty: 9
•Relative cost
–Low costs: 1, high costs: 9
•Relative risk
–Estimation of development risk of a requirement
–Low risk: 1, high risk: 9

36. Approach
1.List all requirements that you want to prioritize
2.Estimate the relative benefit for each requirement, scale 1-9
3.Estimate the relative penalty for each requirements, scale 1-9
4.Calculate the total value (= relative benefit + relative value)
5.Estimate the relative cost for developing each requirement, scale 1-9
6.Estimate relative risk for each requirement, scale 1-9
7.Calculate priority and sort the requirements list, ordered by calculated priority

37. Example
total value = (relative benefit * relative weight) + (relative penalty * relative weight) total value ‘Print a material safety data sheet’ = (2 * 2) + (1 * 4) = 8
priority = value % / ((cost % * cost weight) + (risk % * risk weight))
priority = 5,2 / ((2,7 *1) + (3 * 0,5)) = 1,238 (with rounded numbers: 1,22)

38. AHP / Cost-value approach
•Prioritization based on relative cost and relative value
•Analytical Hierarchy Process (AHP) pair wise comparison of requirements
–Requirement A is 3 times costlier than Requirement B
–Requirement A will have a revenue of 5 times Requirement B
•Karlsson & Ryan (1997)

39. Approach
1.Review requirements for completeness and to ensure that they are stated in an unambiguous way
2.Apply AHP pair wise comparison method to assess the relative value of the requirements
3.Apply AHP pair wise comparison to estimate the relative cost of developing each requirement
4.Plot the found values on a cost-value diagram
5.Use the cost-value diagram as a conceptual map for analyzing and discussing the candidate requirements

40. AHP pairwise comparison method
1.Set up the N requirements in the rows and columns of an NxN matrix.
2.Perform pair wise comparisons of all the requirements according to the criterion.
3.Normalize figures and calculate weight per requirement
Req1
Req2
Req3
Req4
Req1
1
Req2
1
Req3
1
Req4
1
Req1
Req2
Req3
Req4
Req1
1
1/3
2
4
Req2
3
1
5
3
Req3
1/2
1/5
1
1/3
Req4
1/4
1/3
3
1
Req1
Req2
Req3
Req4
Sum
Priority
Req1
0,21
0,18
0,18
0,48
1,05
0,26
Req2
0,63
0,54
0,45
0,36
1,98
0,50
Req3
0,11
0,11
0,09
0,04
0,34
0,09
Req4
0,05
0,18
0,27
0,12
0,62
0,16
Total
1
1
1
1
4
1
1 / 4,75 * 1 = 0,21
Total
4,75
1,86
11
8,33

41. AHP in large-scale RM
•In large-scale requirements management, requirements are often structured in a hierarchy, where the most general requirements are placed on top. This hierarchy can also be used in AHP.
•Approach
–List all unique pairs of requirements at the same level in the hierarchy.
–Compare all pairs of requirements of the highest level with the AHP pairwise comparison method.
–Compare the requirements pairs on the lower levels of the hierarchy.

42. Tool support
•E.g. IBM Focalpoint

43. Approach
1.Review requirements for completeness and to ensure that they are stated in an unambiguous way
2.Apply AHP pair wise comparison method to assess the relative value of the requirements
3.Apply AHP pair wise comparison to estimate the relative cost of developing each requirement
4.Plot the found values on a cost-value diagram
5.Use the cost-value diagram as a conceptual map for analyzing and discussing the candidate requirements

44. Example cost value diagram

45. Visualization: Risk exposure
Risk exposure
Relative Loss
Relative Probability
High Risk Exposure
Low Risk Exposure
5
10
15
20
25
30
5
10
15
20
25
30
x
x
x
x
x
Park, Port & Boehm (1999)

46. Visualization: distribution chart
•Distribution chart for showing how the different stakeholders voted and the resulting priority ranking.
0%
2%
4%
6%
8%
10%
12%
Percentage of total value
M1
M2
M3
M4
M5
M6
M7
M8
M9
M10
10 Stakeholders:
Regnell et al. (2001)
1
2
3
Variation coefficient
(right hand scale)
“Level of disagreement
for each feature”

47. Visualization: Satisfaction chart
•Satisfaction Chart visualizing the correlation of each stakeholder’s priorities with the resulting priorities.
–Influence of each stakeholder on the group?
Regnell et al. (2001)

48. Visualization: Influence chart
•Influence chart visualizing the weighting of stakeholder influence
•Weight each stakeholder
–E.g. to reflect credibility?
–E.g. to reflect size of constituency represented?
Regnell et al. (2001)

49. Integer linear programming
•Origin: mathematics
•Linear programming (LP) problems involve the optimization of a linear objective function  knapsack problem
•Applied in release planning, since release planning is a optimization problem
–Carlshamre (2002): The pragmatic planning algorithm
–Ruhe & Saliu (2005)
–van den Akker, Brinkkemper, Diepen & Versendaal (2008)

50. Problem statement
Maximize the total value of the selected requirements, while this selection is bounded by budget contraints.
More formally:
where n is the total number of requirements
v is the value
r is the estimated resource demand
b is the total available resources (budget)

51. ILP example (1)
•A product manager has 6 candidate requirements for the new release.
•Due to time constraints, not all requirements can be developed.
•For each requirement, an estimation needs to be done concerning the costs and revenues.

52. ILP example (2)
• Maximize revenues:
• Constraint: maximum costs <= 800
• X=1 if requirement is selected
• X=0 if requirement is not selected
Requirements Revenues
Costs
1 – PPE (Personal Protective Equipment) supply & replacement records 100 10
2 – PPE servicing 500 10
3 – Attendance records for emergency training 100 30
4 – Policy & procedure for health monitoring 250 750
5 – Records that health monitoring is provided 600 150
6 – PPE Training records 1000 200
max(100 500 100 250 600 1000 ) 1 2 3 4 5 6 x  x  x  x  x  x
(10 10 30 750 150 200 ) 800 1 2 3 4 5 6 x  x  x  x  x  x 

53. Release planning with ILP
•Extendable with constraints for different teams, team transfers, dependencies (AND, REQUIRES, CVALUE, ICOST), etc.
•Releaseplanner.com (Guenther Ruhe)
–Not only ILP, but extended with stakeholder voting, scenarios, staffing

56. Agenda
•Introduction
•Requirements prioritization
•Release definition
•Scope change management
•Release definition validation, build validation & launch preparation

57. The release definition
•To be written by Product Manager
–Co-authors: Architect & Marketing
•Scope
–Whole product release
–Only for major and minor releases; not for bug fixes
•Content
–Major theme(s) of the release
–Listing of product requirements to be incorporated in the next release (copied labels from RDB)
–Critical dependencies between product requirements
–Distributed ownership of envisaged work
–Planned release date

58. Release definition principles
•Include short descriptions and references to requirements
–Not entire requirement specifications / conceptual solutions
–100 pages do not suit a managerial decision process
•Include strategic content
–Use release themes
–Indicate release fit to overall product roadmap
–Identify strategic direction
•Use consistent and sufficient detail
•Document sources of requirements
–Source information: who and when

59. Release compatibility (1)
•Upward compatibility
–Existing functions of release n continue to be supported in release n+1
–Data from release n can be transferred and used in release n+1 without changes
–Interfaces of release n remain unchanged
•Downward compatibility
–Data from release n+1 can be transferred to release n without changes
–Release n+1 can communicate to release n (release n interfaces are supported)
Kittlaus et al. (2009)

60. Agenda
•Introduction
•Requirements prioritization
•Release definition
•Scope change management
•Release definition validation, build validation & launch preparation

61. "To change and to change for the better are two different things."

62. •Definition
Scope Change Management is the orderly procedural handling, decision making, and monitoring of requirements change requests on the scope of the current release.
•Scope Management is ...
–part of the overall Release Planning process
–executed jointly by Product Manager(s) and Release (or Project or Developement) Manager(s)
–essential for achieving predictability on deadlines
What is scope change management?

63. Scope change management
•Discipline in timely responding to the information requests is key
•Don’t let others wait for you, as you don’t like waiting for others
•Four simple steps:
1.Submit change request
2.Analyze change impact
3.Decide on development
4.Implement change

64. Good Scope Management pays off
•Prevention of:
–Delay
–Postponement of work
–Waste of time and results
–Frustration
•Important to do it together

65. Agenda
•Introduction
•Requirements prioritization
•Release definition
•Scope change management
•Release definition validation, build validation & launch preparation

66. Release definition validation
•To validate the contents and planning of the release definition before the software is realized
–By internal stakeholders
–Possibly with formal approval form the board
–Possibly with a business case (i.e. an estimation of the total costs and revenu expectations for the release)

67. Business case
•A business case is a decision-support and planning approach that compares likely financial results and other business consequences with the required investment for a given undertaking, in the case of software typically a development effort.
•To offer a basis for a go / no-go decision of the board concerning a new investment

68. Business case contents
•Business case should contain information about:
–the description of the undertaking including the underlying assumptions
–an estimate for the required investment
–the approach to generate business benefits with impact on earnings over time
–a sensitivity, risk, and contingency analysis

69. Build validation
•To find out whether the software
–meets the requirements that guided its design and development
–works as expected.
•Carrying out the tests is the responsibility of of development, but product management is involved

70. Launch preparation
•Communicating information about the upcoming release to internal and external stakeholders
–New functionalities
–How to update
–Packaging (content, configurations, APIs)
–Pricing scheme
•Preparation of demos, trainings
•Launch impact analysis
•Updating of all external expressions (website, brochures, etc.)

71. Next Wednesday, 17th September
•Deadline Interview Plan at 14.00h
–Via email to g.g.lucassen@students.uu.nl!
•Lecture at 17.00h
–Product Planning

72. Questions?

73. References (1)
•Kittlaus, H.-B., & Clough, P.N. (2009). Software Product Management and Pricing: Key Success Factors for Software Organizations. Berlin: Springer- Verlag.
•Carlshamre, P., Sandahl, K., Lindvall, M., Regnell, B., & Natt och Dag, J. (2001). An industrial survey of requirements interdependencies in software product release planning, Proceedings of the 5th IEEE Intern. Symposium on Requirements Engineering, pp. 84-91.
•Wiegers, K.E. (1999). First things first: prioritizing requirements. Software Development 7(9), 48–53.
•Ruhe, G., & Saliu, M.O. (2005). The Art and Science of Software Release Planning, IEEE Software 22(6), 47-53.

74. References (2)
•van den Akker, M., Brinkkemper, S., Diepen, G., & Versendaal, J. (2008). Software product release planning through optimization and what-if analysis, Inf. Softw. Technol. 50(1-2),101-111.
•Karlsson, J., & Ryan, K. (1997). A Cost-Value Approach for Prioritizing Requirements, IEEE Software 14(5), 67-74.
•Park, J.W., Port, D., & Boehm, B.(1999). Supporting distributed collaborative prioritization, Sixth Asia-Pacific Software Engineering Conference, Takamatsu, Japan, pp. 560 – 563.
•Regnell, B., Höst, M., Natt och Dag, J., Beremark, P. & Hjelm, T. (2001). An industrial case study on distributed prioritisation in market-driven requirements engineering for packaged software. Requirements Engineering 6, 51–62.
•Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley.