PRODUCT OWNER

September 2016

WII-FMThink about …

The most important thing I want to know is … I want to know how to do … How do we deal with … What if we could …

WHAT IS AGILE?

EMPIRICAL PROCESS CONTROLAgile is based on empirical control, through transparency, inspection and adaptation. The best processes are emerging while doing, and only retrospectively it is possible to recognize successful adaptations from non successful ones.

PULL PRINCIPLE

Agile approaches are based on pull principle which allows self-organizing teams to pull in work and knowledge as needed in order to deliver value to the customer.

AGILE TEAM MODEL

THE AGILE MANIFESTO

AGILE PRINCIPLES

ROLES IN SCRUM

SCRUM MASTER RESPONSIBILITIES The PROCESS OWNER Helps the team do its best work Team level coach Facilitates communication Acts as a change agent

THE DELIVERY TEAM Build the thing RIGHT Made up of whomever is needed to complete the work Decides HOW to build it Commit to the Sprint Own the estimates and tasks Plan their own work (tasks, dependencies)

THE SCRUM FRAMEWORK

SCRUM PROJECT LIFECYCLE

5 LEVELS OF PLANNING

VISIONVision Feeds Scope and Priorities Visioning exercise should be held with all people who

need to buy in to a common vision of the product and/or strategic direction Elevator Statement Design the Product Box Press Release

LEAN CANVAS

PERSONAS

ROADMAP Emphasizing the setting of high-level objectives, aligned

to goals around value-delivery Can be used to define critical dates Set high-level themes and direction Should indicate planned evolution over time

RELEASE PLANNING Description

Team to make a “soft” commitment to the completion of a set of the highest ranked product backlog items for the upcoming release

Synchronize the team on the objectives of the Release and the opportunity to see the bigger picture

Should be done face-to-face Likely that the stories will be further refined and may be split

into smaller (value-focused) stories, AC may be modified, and additional stories may be created

This event may last up to 2 days

RELEASE PLANNING AGENDA Opening Product Vision / Roadmap

Review Architecture Review Release Name & Theme Review Velocity Review Release Schedule &

Iterations Issues and Concerns Definition of Done Review /

Modifications

Review Stories in Consideration Review Story Provide High-level Estimates Split Story (if necessary) Validate Acceptance Criteria Identify Issues & Concerns Identify Dependencies &

Assumptions Sequences Stories Across

Iterations Team Commitment Communication / Logistics

Plan Close / Mini-retro

RELEASE PLANNING OUTCOMES A release plan with team-based understanding of priorities

A best-guess sequence for story mappings to iterations

High-level story estimates Issues, risks, dependencies, concerns to be monitored throughout the Release

WALKING SKELETON

PRODUCT BACKLOGWhat is it?• Is the ranked list of all the features and functions to be built

into the system and all the defects to be fixed. At its most basic it is all the work to be done by the delivery team on the system.

What’s in it?• Contains features, requirements, user stories, as well as

defects. These items describe the system to be developed and they comprise work to be planned and delivered.• Product Backlog Items (PBIs) that cannot be delivered in

one iteration are called epics.

PRODUCT BACKLOGWho owns it?• The Product Owner owns the backlog. The PO owns all

decisions about content and ranking.

Who Contributes to it?• Stakeholders contribute their ideas and needs about what

the system should do.• The Delivery Team contributes technical stories as well as

estimates.

RANK FOR VALUEGoal of an Agile project is to deliver value incrementally. Product Backlog must be ranked for value.Consider value in terms of:

Stakeholder and User Value• Include the System itself as a stakeholder, whose primary interest is its

own health

Strategy Value• Does a PBI further the product vision or corporate strategy.

Competition Value• Can a PBI alter the competitive landscape?

Feedback and Learning• Early feedback from stakeholders. Technical learning, validating

solutions.

PRODUCT BACKLOG DYNAMICS

USER STORIESUser stories are written in everyday language that describe the interaction between the user and the system, focusing on the value gained. It is not a highly documented requirement, but rather a conversation to collaborate on the topic.

A user story should fit onto a 3” x 5” card and will contain 3 parts: the title, the description and the acceptance criteria (AC). If the title and description don’t fit, then you should revisit the user story.

As a [user role/who] I want [goal/what], so I can [reason/why]

WHOThe who is the “who” who wants the functionality and who benefits from it. Typically this is a role or persona.

Avoid “As a user…” this is too vague or too general. Use roles to help the team imagine who they are building the software for. Helps create a relationship between the team and the “who”.

WHATThis specifies the need, feature or functionality that is desired by the who. This is what will be built into the software or service.

Should be clear, so that the team knows what to design and build.

WHY Specifies the value for the who and is the primary

purpose for delivery. It is important to help teams design solutions that meet

the real needs of the users and customers. The “why” is critical as we focus on value driven work .

The “why” keeps the value up front, helping the PO with ranking.

The team needs to understand the “why”, then come up with the delivery ideas.

If there is no “why”, you most likely have a story with no value!

THE 3 C’S3 C’s indicate the 3 elements of a user story: Card, Conversation and ConfirmationCard• Captures the general idea and is a promise for conversationConversation• Through conversation, the PO and delivery team develop shared

understanding of the goals for functionality as well as constraints. This should be the whole team participating.

Confirmation• Well defined user story is testable. AC are the conditions of

satisfaction and acceptance for the story.

REFINEMENT SESSIONSPurpose: To provide input regarding clarity, dependencies, risks, assumptions, acceptance criteria (AC), and high level estimates in order to inform the prioritization and on-going maintenance of the Product Backlog.Attendees: PO, Delivery Team, Subject Matter Experts (SME), Stakeholders (if needed)Outcomes: Stories have been clarified with any relevant information. High-level implementation estimates have been provided by the

Delivery Team that will implement the story. The PO is equipped with information to help with prioritization

decisions.

REFINEMENT DESCRIPTION A backlog refinement session is intended to provided the PO

with information to keep the Product Backlog healthy. This on-going session provides synchronization points with the

delivery team to ensure that the stories are understood and in good standing to be brought into Sprint Planning.

This synchronization ensures that estimates are provided, stories are clarified and that the PO has enough information to prioritize stories on an on-going basis.

The whole team should be involved in a backlog refinement session.

Remember to consider your Backlog Refinement sessions when calculating your team capacity. A general rule of thumb is to reserve approximately 10% - 15% of capacity for each team member.

Any specialists or SME(s) that are needed for a specific story should also attend.

BREAKING DOWN STORIESThe team helps with the work, but the more the PO can own story breakdown, the more she can ensure meaningful feedback and valuable stories. INVEST in good stories

Independent, Negotiable, Valuable, Estimable, Sized Appropriately, Testable

Vertical Slices rather than Horizontal layers

SPLITTING STORIES

RANKING THE BACKLOG Prioritization Attributes

User/stakeholder value Competition value Strategy value Revenue value Risk

Kano Analysis Story Mapping Stack – rank

#1, #2, #3, #n…

SPRINT PLANNING What is it?

PO’s vision for the sprint Describes the highest priority features to the team

Determines the work for the upcoming sprint. Items are taken off of the product backlog according to priority and

broken down into manageable tasks. Who Attends?

Product Owner Scrum Master Delivery Team

Outputs A sprint goal A sprint backlog (includes the list of tasks necessary to

delivering the product backlog items

SPRINT REVIEW / DEMO What is it?

The Scrum team demonstrates what they accomplished during the sprint

Very informal Natural result of the sprint PO accepts or rejects each product backlog item* Stakeholders/business and PO provide feedback

Who Attends? Delivery team Scrum Master Product Owner Customers Stakeholders

Outputs Accepted work for the sprint

RETROSPECTIVE What is it?

A retrospective is an opportunity to learn and improve. It is time set aside – outside of day-to-day routine – to reflect on past events and behaviors.

Who Attends? Product Owner Scrum Master Dev Team

Outputs Top Items to improve for the next sprint Action Items that come out of the meeting

DAILY SCRUM What is it?

Daily meeting held by the team Not a status or a problem solving meeting The team reports to each other on what they accomplish

Who Attends? Product Owner Scrum Master Dev Team Other(s) outside of the Dev team can attend

Outputs None unless there are roadblocks that the Scrum Master

needs to help remove

CHIEF PRODUCT OWNER

This role is the Product Owner (PO) of the whole product. The CPO is focused on the strategy of the product and own a shared

product vision for the entire product. The individual team PO will also have a shared product vision that will

ultimately align with the overall product vision. The CPO owns the single product-level backlog and provides guidance

to the group of PO’s on the Scrum Team(s) that will complete the effort.

The CPO will use the product-level backlog to coordinate the work through sub-backlogs, through the individual team PO.

This role is filled by a single person not a committee. This role requires full time focus and commitment to a single product. The CPO will facilitate collaborative decision making as well as having

the final say if a decision cannot be reached (handled through sessions such as the Scrum of Scrums which the CPO will own).

SCALING THE POFeature and Component Owners - Start-up before Maturity

SCALING THE POUnbundling and Product Variants – Start-up before Maturity

SCALING THE POStrategic and Tactical Product Roles - Mature