5. Product Management - Software Research and the...

5. Product Management

Prof. Dr. Dirk Riehle, M.B.A.

Friedrich Alexander-University Erlangen-Nürnberg

Version of 22.03.2012

Agile Methods by Dirk Riehle is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Based on a work at dirkriehle.com.

http://dirkriehle.com/

http://creativecommons.org/licenses/by-sa/3.0/

http://creativecommons.org/licenses/by-sa/3.0/

http://dirkriehle.com/courses/agile-methods/

Agile Methods - Summer 2012

© 2012 Dirk Riehle - All Rights Reserved 2

Focus of Product Management Chapter 1 / 2

What?



Focus of Product Management Chapter 2 / 2

Cost

Scope

Quality

Time



Contents of Product Management Chapter

1. Product Management● Strategic product management● Technical product management

2. Scrum Roles● Scrum roles

● Product owner

● Team member

3. Scrum Practices● Feature specification● Feature prioritization● Product backlog maintenance

4. Scrum Process● Product Planning● Release Planning



Product Management (Definition)

Product management is an organizational life-cycle function within a company dealing with the planning or forecasting or market-ing of a product or products at all stages of the product life-cycle. (Wikipedia)

A product manager investigates, selects, and develops products for an organization, performing the activity of product manage-ment. (Wikipedia)



Two Sides of Product Management

Strategic Product ManagementFocuses on assessing and defining the opportunity

Owns the Marketing Requirements Document

Technical Product ManagementFocuses on defining the product and its features

Owns the Product Requirements Document



Product Manager Responsibilities

Strategic Prod. Mgmt.● Key process

● Opportunity assessment

● Portfolio planning

● Product planning

● Key practices● Market research

● Competitive analysis

● Focus groups

● User interviews

● Key artifacts● MRD

Technical Prod. Mgmt.● Key process

● Product planning

● Release planning

● Key practices● Feature specification

● Feature prioritization

● PRD maintenance

● Key artifacts● PRD



Product Manager in Context

C: CustomerAM: Account ManagerMM: Marketing ManagerPM: Product ManagerEM: Engineering ManagerSD: Software DeveloperSE: Support EngineerQA: QA Engineer

AM

MM

EM

QA

PM

SD

SE

C



Marketing Requirements Document 1 / 2



Marketing Requirements Document 2 / 2



Product Requirements Document 1 / 2



Product Requirements Document 2 / 2



Video Excerpt From “The Pentagon Wars”

The Bradley Vehicle(Ten years in the life of a product manager.)



Video Lessons

● Multiple stakeholders● Bargaining leads to suboptimal

results

● Meddling stakeholders● Intervening in the tank design

process

● Unclear market● From US military to foreign

markets

● Cost explosion● With changing requirements,

costs explode

● Inconsistent requirements● From fast and small to big with

firepower

● Changing requirements● Lack of focus invalidates prior

work

● Requirements creep● From troop carrier to tank



Describing Processes

PM

FeatureCapture

PRD

Roles

Artifacts

Practices



Scrum Prod. Mgmt. Roles and Resp.

Product Owner● Envisions product● Plans product● Plans releases● Defines features● Prioritizes features● Plans sprints● Reviews results

Team Member● Estimates effort

SM

PO

TM



Product Owner (Definition)

DefinitionThe product owner holds overall responsibility for the product being developed; s/he is focused on delivering value to the business.

Artifacts● Product vision● Release plan● Product backlog● Sprint backlog● Feature archive

Responsibilities● Product management● Engineering management

Practices● Product definition● Feature definition● Feature prioritization● Release planning● Sprint planning● Sprint reviewing● Progress tracking



Traditional to Scrum Role Mapping

Traditional Scrum

Product Owner

Scrum Master

Team Member

QA Engineer

Software Developer

Engineering Manager

Product Manager



Flowers Product Vision (Scrum's MRD)



Product Vision (a.k.a. Concept) (Definition)

DefinitionThe Product Vision captures the essence of the product and of the reasons for its existence as the business value it provides to users.

It captures the main value and names the users and customers; it embodies the core structure of an underlying business model.

Properties● Inspiring

● It inspires users / customers

● Timeless● It is not bound to a schedule

● Focused● It reduces to the essentials

● Decision aid● It is the ultimate arbiter



Flowers Product Backlog (Scrum's PRD)



Product Backlog (Definition)

DefinitionThe product backlog is a detailed prioritized list of upcoming features to be implemented.

It is Scrum's PRD (but differs in important aspects) and the Product Owner's primary artifact.

The Product Backlog does not contain any task descriptions or assignments.

Properties● Focused

● On creating value

● Complete● For current iteration

● Prioritized● According to current needs

● First by value, second by risk

● Evolving● Used in future iterations



Feature (a.k.a. Requirement) (Definition)

A feature is a distinguishing characteristic of a software item (e.g., performance, portability, or functionality) (IEEE 829)



Flowers Main Page Screenshot



Flowers Tell a Friend Screenshot



Simple Tell a Friend User Story



Two Types of Feature Specifications

Example Illustrations● Naturally incomplete● Used to create discussion● Foster collaboration

Specification Methods● Prose● User Story

● Simple user story

● Regular user story

Model Specifications● Try to be complete● Used in contracting

Specification Methods● Prose● Use Case



Simple User Story (Feature Specification)

Tell a FriendAs a Flowers user, I need a function to tell a friend about a flower photo, so that I can share my passion for flowers and increase my network.

Properties● Follows pattern

● As a user role

● I need a function

● So that I get business value

● Applicability● Used to start discussions

● Unsuitable for contracts



User Story (Feature Specification)

Tell a FriendUser Story

The user clicks on “Tell a Friend” and is sees a new dia-log. The user enters their email address, the friend's email ad-dress, a subject and a message to that friend. Upon clicking OK, an email is sent to that friend.

Acceptance Criteria● A valid email is sent

● Proper from: and to: fields

● Proper content incl. valid links

● Sender is cc:ed on email

Properties● Tells a story

● Told from user perspective

● Is exemplary, not complete

● Provides acceptance criteria● Should not add to specification

● Used in validating implementation

● Applicability● Used to start discussions

● Unsuitable for contracts



Prose (Feature Specification)

Tell a FriendA user can click on TELL A FRIEND in the menu and below each photo. If s/he does so, he sees a new page with an email dialog. The fields are FROM, TO, SUBJECT, and BODY. The user can fill in only valid email addresses. The body is prefilled with the photo link. Upon OK, the email is sent, with the user cc:ed. Upon CANCEL, no email is sent. After this, the dialog re-turns to the main page with a status message EMAIL SENT above the main viewing area.

Properties● Describes a model

● Tries to be complete

● Can be used in contracting

● Used in implementation validation

● Open to interpretation● No specification is complete

● May contain inconsistencies

● Still dominant in industry!!



Use Case (Feature Specification) 1 / 2

Name: Tell a Friend

Description: Allows a user to tell a friend by email about Flowers

Actors: User, Visitor

Includes: None

Triggers: Menu Selection on Photo Page

Preconditions: Defined photo function is launched from

Invariants: None

Postconditions: On OK, email is sent; upon cancel, no email is sent

Default Scenario

1. User clicks on link

2. System provides dialog

3. User fills in fields

4. User clicks OK

5. System sends email

6. System returns to main page

Alternative Scenarios

1. User clicks on link

2. System provides dialog

3. User clicks cancel

4. System returns to main page



Use Case (Feature Specification) 2 / 2




● Applicability● Used in implementation validation

● Used for specification guarantees

● Used in industry● Second most common spec. type

● Part of UML, good tool support

Flowers Service

Tell aFriend

user guest




● Applicability● Used in implementation validation

● Used for specification guarantees

● Used in industry● Second most common spec. type

● Part of UML, good tool support



Quality Criteria for Feature Specifications

I ndependent: Features are orthogonal (independent) of each other.

N egotiable: No feature is cast in stone; discussion can lead to it being split or merged with other features.

V aluable: Every feature should have business value.

E stimatable: A feature should be clear and specific so that implementation effort can be estimated.

S mall: A feature should be small enough to be implemented in one iteration.

T estable: A feature should have clear acceptance criteria so that it can be tested against and validated during review.



Quiz: What's Wrong With This Story? 1 / 2

Upload User ProfileThe logged-in user, on the Profile page, clicks on the link “Upload Picture” to upload a profile picture. The link redirects to an-other page, the main Profile Picture page. On the main Profile Picture Page, the user selects the option either to upload the pic-ture from a local hard disk (by clicking on the “Browse” button) or to make a picture using the web-cam (by clicking on the “Make Picture” button).

For the option, when the user uploads a picture selecting a file from his or her hard disk, the user clicks on the button “Browse” and then selects an image file from a file navigator window. The file extensions for uploading are JPG, JPEG, GIF or PNG. According to these extensions, the user sees the files s/he is able to choose from.

For the “Make a picture” option, when the user clicks on the button, a pop-up window

is displayed. On the new window, the user clicks on the button-image “Camera” and takes the picture. After that s/he confirms whether the image should be saved or the action should be canceled. The user clicks on “Save Image” to confirm to save the im-age. The user clicks on “Cancel” to dismiss the picture.

Uploaded pictures or made pictures are saved on a Profile Picture Gallery, where any picture that was set as a profile picture is saved.

After the user uploaded the picture, s/he chooses whether he/she wants to publish it or not. The user publishes a picture by se-lecting the check-box “Publish Picture”. Af-ter publishing a picture, the event is listed as one or more items on the “What’s on your mind” section.

[...]



Quiz: What's Wrong With This Story? 2 / 2

Spam-free Reg. EmailRight after user registration, an email is sent to the unverified email address of the user with a unique link that verifies the user's account when he/she clicks on it (see Verify User by E-Mail). The email goes directly into the inbox of the user passing the spam filter.

Acceptance Criteria● All tags closed, no bad HTML code

● No IP address in URL (plain text)

● No user name in subject/email

● No numbers in subject

● No catchy words in subject

● No capital letters in subject

● Avoid utilizing phrases like “click here”

● No BCC distribution

● No dirty words

● No images in email

● Max. 2 colors in mail (no signal colors)

● No big headings (max. size 14)

● Check email against a Spam checker



Prioritizing Features by Value and Risk

value

23x realize

never 1realize

last

realizefirst

realizesecond

risk

high

risk

low

high

value

low



Quiz: How to Prioritize These Features?

1. LoginAs a guest, I can login using my user account to get access to user functionality

2. LogoutAs a logged-in user, I can logout to free up the computer for some other person

3. Lock-out UserAs a user, my account is blocked, if I fail three times in a row when trying to log in

4. Tell a FriendAs a guest, I can tell my friends by email about a flower photo to share my passion



Prioritizing Features by Kano Model

high

cust

omer

sa

tisfa

ctio

n

low

fully

degree of featureimplementation

not at all

exciters anddelighters

must-have

linear



Flowers Product Backlog Scrolled



Product Backlog Item (Definition)

DefinitionA product backlog item is an entry in the product backlog

PropertiesIt provide these fields

● Identifier● Estimated effort● Category● Short name● Item description● Acceptance criteria

Types of Items● Features● Bug reports● Refactorings

Some people keep bug reports and refactorings outside the prod-uct backlog, we don't



Other Types of Product Backlog Items

Bug ReportsA bug report describes a problem with the system, possibly pointing to the source of the issue

Properties● Describes business value● Used to fix non-working feature● Links to bug tracker

RefactoringsA refactoring improves structure without changing behavior (“im-proving the design of existing code”

Properties● Describes technical value● Applied to reduce tech. debt



Measuring Effort of Feature Implementations

Person HoursPerson hours are a unit of mea-sure of time needed to implement a given feature.

Properties● Is an estimate of “duration”● Typically, this is “ideal time”● Real time has inefficiencies

Story PointsStory points are an (arbitrary but socially agreed-upon) unit of mea-sure of size of a given feature.

Properties● Is an estimate of “size”

● Is not an estimate of “duration”

● Has a linear scale● Does not have linear choice

● Is socially agreed upon● Thus, is team-dependent

● Maps to time with “velocity”



Measuring Effort with Story Points

Properties (Continued)● Force qualitative choice● Force split if too large

● Are additive on linear scale● Used to compute total effort

● Convert to time with velocity

Points Meaning

0 No effort

1 Minimal effort

2 Small effort

3 Medium effort

5 Large effort

8 Very large effort

13 Too large effort



Relative Weighting (Practice)

RelativeBenefit

RelativePenalty+ )( as %

Cost inStory Points as %P =

P = prioritization key figure (rational number)



Feature Relative

Benefit

Relative

Penalty

Total Value

Value %

Relative

Cost

Cost %

Relative

Risk

Risk %

Priority

1. Query status of a vendor order

5 3 13 8.4 2 4.8 1 3.0 1.345

2. Generate a Chemical Stockroom inventory report

9 7 25 16.2 5 11.9 3 9.1 .987

3. See history of a specific chemical container

5 5 15 9.7 3 7.1 2 6.1 .957

4. Print a chemical safety datasheet

2 1 5 3.2 1 2.4 1 3.0 .833

5. Maintain a list of hazardous chemicals

4 9 17 11.0 4 9.5 4 12.1 .708

6. Modify a pending chemical request

4 3 11 7.1 3 7.1 2 6.1 .702

7. Generate an individual laboratory inventory report

6 2 14 9.1 4 9.5 3 9.1 .646

8. Search vendor catalogs for a specific chemical

9 8 26 16.9 7 16.7 8 24.2 .586

9. Check training database for hazardous chemical training record

3 4 10 6.5 4 9.5 2 6.1 .517

10. Import chemical structures from structure drawing tools

7 4 18 11.7 9 21.4 7 21.2 .365

Totals 54 46 154 100 42 100 33 100 --



Product Backlog Maintenance (Practice)

FeatureEstimation

Feature

PO TM

ProductBacklog

Senior team member estimates feature size; this is a rough cut. More precise estimation using planning poker discussed later.



Development Velocity (Speed)

V = S / T[ story points / sprint ]

V = VelocityS = Size (of effort)T = Time (in sprints)



Charting Development Velocity

??212321

time [sprints]

????????

size

[s t

ory

poin

ts]

average speed after three sprints = 21,7 story points / sprint



Product Planning Process and Practices

Product Planning● Envision product

● Driver: Product owner

● Collaborators: Market / client

● Artifact: Product vision

● Define release schedule● Driver: Product owner


● Artifact: Release plan

Release Planning● Plan release

● Driver: Product owner


● Artifact: Release plan



Scrum Process (Overview)

time

...P E 3R P E 3RP E 3R

Sprint n-1 Sprint n+1Sprint n

...

1-4 weeks 1-4 weeks1-4 weeks

time6-12 months 6-12 months6-12 months

Rel. m-1 Rel. m Rel. m+1 ...

P: PlanningE: Execution3R: Review, release, and retrospective



Release Schedule (Artifact and Practice)

DefinitionThe release schedule defines a sequence of product releases; it is based on meeting client needs.

A release is typically considered an important product milestone.

Properties● Works toward product vision● Creates real value each release● Typically 3, 6, or 12 months● Or, aligned with deadlines

Scheduling Options● Defined Rhythm

● Releases every 6 months

– Ex: Eclipse, Ubuntu

● Preferred by platforms

– Aligns multiple components

– Cf. “release train”

● External Deadlines● Fit release to deadlines

– Ex: CeBIT, client requirement

● Preferred by projects



Release Plan (Artifact)



Release Plan (Artifact and Practice)

DefinitionThe release plan provides the re-lease schedule and maps the se-quence of releases and the sprints within these releases into a time.

The release plan is subject to change as new information invali-dates effort estimations.

User stories are mapped into sprints using development velocity.

Properties● Fields for release entry

● Start date

● End date

● No sprints

● Sprint summaries

● Fields for sprint entry● Sprint identifier

● Theme of sprint

● User stories (by id)

● Estimated effort

● Estimated burn-down



Release Burndown Chart (Artifact)

275582200224249270 105130155179

rem

aini

ng s

tory

po

ints

0

1098765432 111 12



Sprint (Practice)

DefinitionA sprint is a fixed-length develop-ment episode that provides a full uninterrupted planning, execution, and review cycle.

Properties● Should have a theme● Is prepared beforehand● Will be planned at beginning

Types of Sprints● Regular sprint● Exploratory sprint● Cleanup sprint ● Release sprint



Start and Duration of Regular Sprints

Monthly Sprints● Is original recommendation● Is too long for some domains● Should start 1st Monday

One Week Sprints● Requires well-working team ● Are needed in some domains● Should start on Wed or Thu

Two Week Sprints● Are realistic even for beginners● Align with half-month rhythm● Should start on Wed or Thu



Irregular Sprints

time

...P E 3R... Expo...

time

...P E 3R... ... P E 3R Release

Agile Methods - Summer 2012 © 2012 Dirk Riehle - All Rights Reserved 58

Thank you! Questions?

[email protected] – http://osr.cs.fau.de

[email protected] – http://dirkriehle.com – @dirkriehle

DR

mailto:[email protected]

http://osr.cs.fau.de/

mailto:[email protected]

http://dirkriehle.com/

http://twitter.com/dirkriehle



Contributions and Credits

None yet.

5. Product Management - Software Research and the...

Documents

Transcript of 5. Product Management - Software Research and the...