SPM 5 - Release Planning

Software Product Management Release planning

Lecture 5

Sjaak Brinkkemper

Garm Lucassen

12 september 2014

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.”

Balancing forces: technology push vs. market pull

Henry Ford:

If I'd asked customers what they wanted, they would have said "a faster horse".

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

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

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

SPM Competence Model

SPM Competence Model

Release planning

• Requirements prioritization

• Release definition in depth

• Scope change management

• Release definition validation

• Build validation short overview

• Launch preparation

Agenda

• Introduction

• Requirements prioritization

• Release definition

• Scope change management

• Release definition validation, build validation & launch preparation

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.

Release tree

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

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

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

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

Agenda

• Introduction

• Requirements prioritization

• Release definition

• Scope change management

• Release definition validation, build validation & launch preparation

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

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.

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.”)

• 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)

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”

Estimates do not improve themselves

• Estimates improve

– When we collect data

– Reflect on estimates

– Remove variability

• Making decisions

• Keeping team stable

Simple prioritization techniques

1. MoSCoW

2. Cumulative voting

3. Numerical assignment

4. Top-10 requirements

5. Binary search list

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.

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

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

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

Top-10 requirements

• Each stakeholder selects 10 favorite requirements.

• Product manager sorts requirements by considering fairness and satisfaction of stakeholders.

• 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

Binary search list: Facebook example

• Email integration

• Dislike button

• Picasa integration

• Profile visit stats

• Layout customization

• Integration with Google calendar

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.

Questions?

Prioritization: advanced

• Wiegers’ prioritization model

• Analytical hierarchy process / cost value approach

• Integer linear programming

Wiegers prioritization model

• Prioritization based on value, cost and risk

• Karl E. Wiegers (1999)

• More information: http://www.processimpact.com/

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

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

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)

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)

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

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

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.

Tool support

• E.g. IBM Focalpoint

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

Example cost value diagram

Visualization: Risk exposure

Risk exposure

Relative Loss

Rela

tive P

robabili

ty 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)

Visualization: distribution chart

• Distribution chart for showing how the different stakeholders voted and the resulting priority ranking.

0%

2%

4%

6%

8%

10%

12%

Pe

rcenta

ge o

f to

tal valu

e

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”

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)

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)

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)

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)

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.

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

)1000600250100500100max( 654321 xxxxxx

800)200150750301010( 654321 xxxxxx

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

Agenda

• Introduction

• Requirements prioritization

• Release definition

• Scope change management

• Release definition validation, build validation & launch preparation

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

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

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)

Agenda

• Introduction

• Requirements prioritization

• Release definition

• Scope change management

• Release definition validation, build validation & launch preparation

"To change and to change for the better

are two different things."

• 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?

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

Good Scope Management pays off

• Prevention of:

– Delay

– Postponement of work

– Waste of time and results

– Frustration

• Important to do it together

Agenda

• Introduction

• Requirements prioritization

• Release definition

• Scope change management

• Release definition validation, build validation & launch preparation

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)

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

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

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

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.)

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

Questions?

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.

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.