openSAP: Build Better Products with a Human-Centered Product Backlog

Good Product Backlog Definition

Aspects of a product backlog

Product Backlog Structure and User Story Mapping

Story-driven communication
Document-driven communication
Preconditions for User Story Mapping (USM)
Product vision statement

Creating As-Is and To-Be Processes

Creating the Walking Skeleton

User story mapping

Writing, Refining, and Splitting Your User Stories
INVEST criteria
Deriving Non-Functional Requirements from Your User Stories

Product Backlog Validation and Refinement

A Deep Dive into the Persona Technique
Validating Your Backlog with Storyboards
Building Your Storyboard with SAP Scenes on MURAL
Collaborating with Your Customers During Discovery
Project pre-sprint activities
Refining Your User Stories with Customers

Product Backlog Ranking

Estimating Complexity for Your User Stories
Identifying the Business Value
Categorizing User Benefits with the Kano Methodology
Ranking Your Product Backlog
Planning the Delivery of Product Increments

Good Product Backlog Definition

Aspects of a product backlog

A clear collaboration process is in place.
Roles and responsibilities are clearly defined.
The customer is involved in all phases.
The product backlog is created in a mixed team (PO=V,
architect = F, UXD = D).
The product backlog is refined in a mixed team (V,F,D).

------------

A minimum viable product (MVP) is defined together with the customer.
The timeline is aligned and frequently revised with the customer (timeline until delivery).
Risks are well managed (ROAM) = Once a risk has been identified, the team takes care of it in a structured and agile way.

------------

An overall business objective (e.g. product goal) is defined (viability).
The overall technical solution (e.g. architecture vison) is defined (feasibility).
The overall idea how the users benefit from the future solution is defined (desirability).

------------

Effort estimation: The effort for user stories is estimated in story points = effort estimation.
Business value: The business value for each user story is estimated and documented by business experts from the customer.
Desirability: The importance from a user’s perspective of each user story is estimated and documented based on end-user feedback (Kano).

------------

The product backlog is appropriately detailed.
The product backlog is estimated.
The product backlog is emergent.
All product backlog items are prioritized from top to bottom.

Product Backlog Structure and User Story Mapping

Document-driven communication

Story-driven communication

Preconditions for User Story Mapping (USM)

Product vision statement

For <target customer>, who <statement of the need or opportunity>,

the <product name> is <product category>, that <major capabilities,

key benefits, compelling reason to buy or use>.

Unlike <primary competitive alternative, current system or business

process>, our product <statement of primary differentiation and

advantages of the new product>.

Creating As-Is and To-Be Processes

Creating the Walking Skeleton

A “walking skeleton” is the simplest implementation of a functional area of software. “Walking” means that the minimal implementation works and the user is able to reach his/her goal.

“Skeleton” means that the essential parts exist, but most of the functionality – the meat – is still missing.

The goal is to receive early feedback from users and stakeholders.

Essential parts
Minimum viable product (MVP)

User story mapping

Writing, Refining, and Splitting Your User Stories

The evolution of user stories

INVEST criteria

We never have enough information to estimate the time needed to implement a user story, but you can immediately begin to compare the sizes of user stories to each other to determine a relative size.

Deriving Non-Functional Requirements from Your User Stories

Acceptance criteria are a clear and concise description of the expected behavior for a specific backlog item/user story.

Definition of Done (DoD) helps to achieve a common understanding on what is expected from

the team so that the backlog item can be considered finished.

Unlike acceptance criteria, these expectations need to be considered for all backlog items.

Product Backlog Validation and Refinement

Validation of Requirements / User Stories
Validation of Solution Ideas / UI prototype

A Deep Dive into the Persona Technique

Validating Your Backlog with Storyboards

What might happen ….

Creating and considering complex scenarios was key in the military for hundreds of years to play through specific scenarios to “validate” the next move.

When