agile product owner in wonderland!

{

Agile Product Owner in Wonderland!

Tathagat Varma VP, Strategic Process Innovations [24]7 Innovation Labs

v Agile Philosophy v Scrum Methodology v Product Owner Role v Agile in Hardware / Systems

Topics…

Identify yourself…J

hNp://headrush.typepad.com/creating_passionate_users/2005/06/featuritis_vs_t.html

How Apple does it?

Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favorite line of the day was when people kept raising their hand saying, "ʺDoes it do [x]?"ʺ, "ʺDo you plan to add [y]?"ʺ. Finally Jobs said, "ʺWait wait — put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don'ʹt want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It'ʹs about saying NO to all but the most crucial features.”

hNp://www.oreillynet.com/onlamp/blog/2004/08/say_no_by_default.html

hNp://blog.comsysto.com/2012/08/13/continuous-‐‑delivery-‐‑of-‐‑waste/

hNp://www.emilianosoldipmp.info/wp-‐‑content/uploads/2012/08/Stacey.png

That’s the problem we need to solve!

And these are the methods we are using!!!

12 Agile Principles

Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software.

Welcome changing requirements, even late in

development. Agile processes harness change for

the customer'ʹs competitive advantage.

Deliver working software frequently, from a

couple of weeks to a couple of months, with a

preference to the shorter timescale.

Business people and developers must work

together daily throughout the project.

Build projects around motivated individuals.

Give them the environment and support they need,

and trust them to get the job done.

The most efficient and effective method of

conveying information to and within a development team is face-‐‑to-‐‑face

conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able

to maintain a constant pace indefinitely.

Continuous aNention to technical excellence

and good design enhances agility.

Simplicity-‐‑-‐‑the art of maximizing the amount of work not done-‐‑-‐‑is

essential.

The best architectures, requirements, and designs emerge from self-‐‑organizing

teams.

At regular intervals, the team reflects on how

to become more effective, then tunes and adjusts its behavior accordingly.

Feedback Loops in Traditional Techniques vs. Agile Techniques

Waterfall vs. Agile: Risk vs. Value Delivered

hNp://www.testingthefuture.net/wp-‐‑content/uploads/2011/12/waterfall_versus_agile_development.png

Agile ROI

hNp://www.agileload.com/agileload//blog/2012/10/22/agile-‐‑performance-‐‑testing-‐‑process-‐‑-‐‑-‐‑whitepaper

5 Levels of Agile Planning

Product Runways

Strategic Vision

Set by the CEO / Board and consists of Strategic Direction, Solution Strategy, Technology Initiatives and Themes Reviewed annually as part of annual strategic planning and revised as needed Serves as a strategic input for product vision

Product Vision

High-‐‑level overview of product requirements owned by respective POs Acts as true north for the product in long term (3-‐‑5 years) Serves as the input for overall product roadmap in medium term (1-‐‑3 years)

Product Roadmap

Calls out the high-‐‑level themes and release timeline in next 1-‐‑3 years Consists of swimlanes (strategic priorities vs. lights on, client requests,vs. competitive intel, technical debt vs innovation ideas,, etc.) Reviewed each quarter by Product Council

Product Backlog

Prioritized list of features identified for the next 1-‐‑3 releases Owned and maintained by respective POs based on relative prioritization of each feature request Revised constantly based on evolving inputs and refined weekly in grooming sessions with scrum team

Sprint Backlog

Consists of highest-‐‑priority / highest-‐‑value features agreed upon for development in the current sprint (1-‐‑4 weeks) Product Owner responsible to prioritize the features, while scrum team responsible for planning, estimation, planning, execution and completion of those features in a sprint Once the sprint has started, any new requirements or change request must wait until the next sprint planning

Adaptive Planning

Product Backlog

Product Roadmap

Sprint Backlog

Product Vision Futuristic

picture of the product Based on technology evolution, market development, industry trends, etc. Reviewed annually, and revised as needed

High-‐‑level wish list of themes and epics for a long-‐‑term Reviewed by Product Council on a quarterly basis Typically revised annually

Prioritized list of Themes, Epics and User Stories Gets constantly revised and groomed on a weekly basis

Well-‐‑groomed User Stories Can’t be changed once the sprint is underway

Current Sprint 3-‐‑6 months 12-‐‑24 months 1-‐‑3 years

Small Stories,

Firm Requirements,

Large Stories / Epics / Themes,

Fuzzy / Evolving Requirements

Predictable delivery of Features

Flexibility to accommodate Changes

Product Management Artifacts

Initiatives

Epics

Them

es

Sprint Backlog

Prod

uct B

acklog

Prod

uct R

oadm

ap

Prod

uct V

ision

Tasks…

Stories

Scenarios

Product Vision

Shared by All

Desirable and Inspirational

Clear and Tangible

Broad and Engaging

Short and Sweet

Product Vision – Elevator Pitch

For (target customer)

Who (statement of the need or opportunity)

The (product name) is a (product category)

That (key benefit, compelling reason to buy)

Unlike (primary competitive alternative)

Our product (statement of primary differentiation)

hNp://www.joelonsoftware.com/articles/JimHighsmithonProductVisi.html

Product Vision Box

v As the name suggests…

v Describes the top 2-‐‑3 features of product

Press Release

v Amazon’s “working backwards”

v Write the launch press release!

Kano Model

MoSCoW

• Describes a requirement that must be satisfied in the final solution for the solution to be considered a success. MUST

• Represents a high-‐‑priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

SHOULD

• Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit. COULD

• Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future. WON'ʹT

Minimal Marketable Feature

A Minimal Marketable Feature (MMF) is a feature that is minimal, because if it was any smaller, it would not be marketable. A MMF is marketable, because when it is released as part of a product, people would use (or buy) the feature.

An MMF is different than a typical User Story in Scrum or Extreme Programming. Where multiple User Stories might be coalesced to form a single marketable feature, MMFs are a liNle bit bigger. Often, there is a release after each MMF is complete.

An MMF doesn’t decompose down into smaller sub-‐‑feature, but it is big enough to launch on its own.

A MMF can be represented as a User Story — a short, one-‐‑sentence description.

MVP, MMF, Stories

MVP

MMFs

Stories

Product Roadmap

hNp://www.romanpichler.com/blog/agile-‐‑product-‐‑management-‐‑tools/agile-‐‑product-‐‑roadmap/

hNp://dynamicsgpblogster.files.wordpress.com/2009/04/dynamicsgproadmap4.png

• High-‐‑level plan that describes how the product will evolve

•  Refers to •  Product version •  Functionality •  Release date

Benefits of Product Roadmap

Helps communicate how you see the product develop.

Helps align the product and the company strategy.

Helps manage the stakeholders and coordinate the development, marketing, and sales activities.

Facilitates effective portfolio management, as it helps synchronise the development efforts of different products. Supports and complements the product backlog. This allows the backlog to focus on the tactical product development aspects.


Product Backlog Iceberg

Product Backlog

A combined list of all desired work, including user focused stories, technical work, features & ideas

Everything is expressed in User Stories

List is prioritized by the Product Owner

Product Owner keeps it organized with the team’s help

Anyone can add items to the backlog

Evolves over time

Always in progress

Product Backlog v  The agile product backlog is a

prioritized features list, containing short descriptions of all functionality desired in the product.

v  When using Scrum, it is not necessary to start a project with a lengthy, upfront effort to document all requirements.

v  Typically, a Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers.

v  hNp://www.mountaingoatsoftware.com/scrum/product-‐‑backlog

….should be “DEEP”

• Detailed Appropriately D: • Estimated E: • Emergent E: • Prioritized P:

Estimated Product Backlog

Prioritized Backlog

Multiple Backlogs?

hNp://inevitablyagile.wordpress.com/2010/05/06/backlog-‐‑grooming/

Many Projects, One Team

hNp://blog.assembla.com/AssemblaBlog/tabid/12618/Default.aspx?Tag=workflow

One Project, Many Teams


Many Projects, Many Teams


From Product Roadmap to Product Backlog


Who owns Product Backlog?


Sprint Backlog

v User Stories selected by the Team

v Will be built in current Sprint

v Fully Estimated v Divided into Tasks

Potentially Shippable Increment

v  Most agile processes require development teams to built an increment of product functionality every iteration, or Sprint. Scrum and Extreme Programming require that this increment be potentially shippable, if the customer desires to implement the functionality. This usually requires that the increment consist of thoroughly tested code that has been built into an executable, and the user operation of the functionality is documented, either in Help files or user documentation. If the product increment that is created during the iteration has more exacting use, the development organization usually defines the additional product requirements as standards or conventions.

v  For example, the Federal Drug Administration (FDA) must approve a product that will be used in life critical circumstances by in numerous health care seNings if the product is to be used in the United States. As part of the approval process, the FDA checks that specific information regarding the product is provided, such as requirements traceability and specific functionality operation. For each increment to be potentially shippable, these additional facets of the product must also be developed ñ so that each increment of the product is potentially ready for FDA approval.

v  Similarly, some products require that performance requirements be modeled and the performance demonstrated mathematically, not just through statistical measurement of the actual system. The model with all required rigor is thus an additional part of each iteration ís potentially shippable increment.

hNp://cf.agilealliance.org/articles/system/article/file/970/file.pdf

Backlog Grooming

v Upto 10% of sprint time

v Creating or refining new PBIs

v Estimating PBIs

v Prioritizing PBIs

Release Planning

Release Burn-‐‑down Chart

Feature planning in Fixed #Sprints

User Story

I as a <Role>

want <Feature>

so that <Value>

The Three C’s of a User Story

• The story itself • A promise to have a conversation at the appropriate time

Card

• The requirements themselves communicated from the PO to the Delivery Team via a conversation

• Write down what is agreed upon Conversation

• The Acceptance Criteria for the story • How the Delivery Team will know they have completed the story

Confirmation

What makes a good User Story?

Independent of all others

Negotiable not a specific contract for features

Valuable or vertical

Estimable to a good approximation

Small so as to fit within an iteration

Testable in principle, even if there isn’t a test for it yet

hNp://guide.agilealliance.org/guide/invest.html

Acceptance Criteria

52

Given <System State> when <an event occurs> then <an outcome happens>

Performance Constraint -‐‑> Acceptance Criteria

“Done”

•  Defines the good working development practices that will be delivered with each item as it is ready for acceptance

•  Common entries in Definition of Done: •  Code includes unit tests, reviewed, checked in •  Tests described and executed •  Build, release notes •  Compliance documentation updated to include current functionality •  Satisfies agreed-‐‑upon acceptance criteria

• Done focuses on internal quality •  Applies to all items in Product Backlog “Building the thing right”

• Acceptance criteria focuses on external quality

•  Functionality “Building the right thing”

Epics

v  A Scrum epic is a large user story. There'ʹs no magic threshold at which we call a particular story an epic. It just means “big user story.” I like to think of this in relation to movies. If I tell you a particular movie was an “action-‐‑adventure movie” that tells you something about the movie. There'ʹs probably some car chases, probably some shooting, and so on. It tells you this even though there is no universal definition that we'ʹve agreed to follow, and that an action-‐‑adventure movie must contain at least three car chases, at least 45 bullets must be shot, and ….

v  So, “epic” is just a label we apply to a large story. Calling a story an epic can sometimes convey additional meaning. Suppose you ask me if I had time yesterday to write the user stories about the monthly reporting part of the system. “Yes,” I reply, “but they are mostly epics.” That tells you that while I did write them, I didn'ʹt get the chance to break most of them down into stories that are probably small enough to implement directly.

hNp://www.mountaingoatsoftware.com/blog/stories-‐‑epics-‐‑and-‐‑themes

Epics -‐‑> Stories

Themes, Epics, Stories, Tasks

Themes

We could put a rubber band around that group of stories I wrote about monthly reporting and we'ʹd call that a “theme.” Sometimes it'ʹs helpful to think about a group of stories so we have a term for that. Sticking with the movie analogy above, in my DVD rack I have filed the James Bond movies together. They are a theme or grouping.

hNp://www.mountaingoatsoftware.com/blog/stories-‐‑epics-‐‑and-‐‑themes

Themes change/evolve…

Scrum Product Ownership – Bob Galen

hNp://www.agileforall.com/wp-‐‑content/uploads/2012/01/Story-‐‑SpliNing-‐‑Flowchart.pdf

SpliNing User Stories

Scenarios

v A usage scenario, or scenario for short, describes a real-‐‑world example of how one or more people or organizations interact with a system.

v They describe the steps, events, and/or actions which occur during the interaction.

v Usage scenarios can be very detailed, indicating exactly how someone works with the user interface, or reasonably high-‐‑level describing the critical business actions but not the indicating how they’re performed.

Scenarios, User Case, User Story

Use Case: Customer walks to the restaurant Customer enters the restaurant Customer finds a seat at the bar Customer scans the menu Customer selects a beer Customer orders selected beer Bartender takes order Bartender pours beer Bartender delivers beer User drinks beer User pays for beer

User Story: A user wants to find a bar, to drink a beer. hNp://www.cloudforestdesign.com/2011/04/25/introduction-‐‑user-‐‑stories-‐‑user-‐‑personas-‐‑use-‐‑cases-‐‑whats-‐‑the-‐‑difference/

Scenario: Josh is a 30 something mid-‐‑level manager for an ad agency, metro-‐‑sexual and beer aficionado. He likes to try new and exotic beers in trendy locations. He also enjoys using a variety of social apps on his smart phone. He reads a review on Yelp of a new burger & beer joint downtown with over 100 beers on tap, and decides to go walk over after work and check it out.

User Story Mapping

© Jeff Pa(on, all rights reserved, www.AgileProductDesign.com

The user story map contains two important anatomical features

v  The backbone of the application is the list of essential activities the application supports

v  The walking skeleton is the software we build that supports the least number of necessary tasks across the full span of user experience

time

necessity

The backbone

The walking skeleton

Scrum Framework

Roles, Ceremonies and Artifacts

•  Scrum Team is small (5-‐‑9), cross-‐‑functional team members from Dev, UX, QA (excluding Product Owner) to ship complete feature(s) end to end

•  Scrum Master is the servant leader responsible for supporting team

•  Product Owner owns Product Backlog and sets appropriate priority for team to act upon

Roles

Product Owner

Scrum Master

Scrum Team

Ceremonies

Sprint Planning Meeting

Daily Stand-‐‑ups

Backlog Grooming

Product Demo

Sprint Retrospective

Artifacts

Product Backlog

Sprint Backlog

Increment

Release Burn-‐‑down Chart

Sprint Burn-‐‑down Chart

Scrum Roles

Product Owner

hNp://williamgill.de/2012/10/01/the-‐‑product-‐‑owner-‐‑the-‐‑poster/

Product Management Spectrum

hNp://enlogica.com/uncategorized/what-‐‑is-‐‑a-‐‑product-‐‑manager/

Too many roles?

hNp://www.romanpichler.com/blog/roles/the-‐‑single-‐‑product-‐‑owner/

“There can only be one”

hNp://www.romanpichler.com/blog/roles/the-‐‑single-‐‑product-‐‑owner/

Product Owner Role

Why?

v Reduce hand-‐‑offs v Ensure continuity v Ownership v Enables long-‐‑term thinking

Product Owner The product owner has responsibility for deciding what work will be done. This is the single individual who is responsible for bringing forward the most valuable product possible by the desired date. The product owner does this by managing the flow of work to the team, selecting and refining items from the product backlog. The product owner maintains the product backlog and ensures that everyone knows what is on it and what the priorities are. The product owner may be supported by other individuals but must be a single person.

Certainly the product owner is not solely responsible for everything. The entire Scrum team is responsible for being as productive as possible, for improving its practices, for asking the right questions, for helping the product owner.

Nonetheless, the product owner, in Scrum, is in a unique position. The product owner is typically the individual closest to the "ʺbusiness side"ʺ of the project. The product owner is charged by the organization to "ʺget this product out"ʺ and is the person who is expected to do the best possible job of satisfying all the stakeholders. The product owner does this by managing the product backlog and by ensuring that the backlog, and progress against it, is kept visible.

The product owner, by choosing what the development team should do next and what to defer, makes the scope-‐‑versus-‐‑schedule decisions that should lead to the best possible product.

hNp://www.scrumalliance.org/why-‐‑scrum/core-‐‑scrum-‐‑values-‐‑roles

Old School Vs. New School

Old School New School Several roles bring product to life

One role is responsible

Detached from development teams

Member of scrum teams

Extensive work up-‐‑front Minimum work up-‐‑front Up-‐‑front product discovery

Continuous product discovery

Late customer feedback Early and frequent customer feedback

Agile Product Management with Scrum – Roman Pichler

Responsibilities Affected

You Used to do This

Now do This

Write an exhaustive PRD

Write user stories and maintain a backlog

Strive to get it right the first time

Use experimentation as a competitive advantage

Innovate and differentiate within the confines of Product Management

Leverage the creativity of your entire cross-‐‑functional team to innovate and differentiate

Have large amounts of time between input and delivery, watching market changes without the ability to change course

Be involved on a daily basis to maximize the value delivered

Responsibilities -‐‑ continued

Always do This

Because…

Understand and communicate Market Requirements

Helps ensure alignment

Have a clear customer value proposition and metrics

Enables experimentation as a competitive advantage

Seek and find Early Release Opportunities

Provides rich learning environment, early feedback, less guesswork

Top 5 ways POs can support your team Share the product backlog for feedback from the team a few days before sprint planning

Collaborate with the team to produce a great product through product backlog management and delivery

ANend the daily stand-‐‑up

Come to planning meetings prepared

Provide a longer-‐‑term view of product vision, roadmap, and goals that is negotiable in how it is delivered

Top 5 PM/PO behaviors to reconsider The whole list is “must have”, by the target release date

Product backlog isn’t ready for the team to plan with

Not able to describe context and assumptions for product backlog items

Not involving the team in backlog management

Not knowing your market

Product Owner Anti-‐‑PaNerns

Trying to reprioritize the work that team has commiNed to in a sprint Trying to unilaterally add or remove content of a Sprint backlog after the team has commiNed to its delivery Dictating, or trying to overrule, the estimates that a team provides Interfering with the Development Team’s ability to deliver on their Sprint commitments

Deferring business decisions to the development teams

Expecting the development team to plan beyond one iteration

hNp://agile.dzone.com/articles/product-‐‑ownership-‐‑practice

Common Product Owner Traps

The Underpowered Product Owner

The Overpowered Product Owner

The Partial Product Owner

The Distant Product Owner

The Proxy Product Owner

The Product Owner CommiNee

hNp://www.scrumalliance.org/community/articles/2010/april/common-‐‑product-‐‑owner-‐‑traps

Potential Product Owner Pitfalls

Product Backlog doesn’t exist

Product Backlog not visible to The Team

Never-‐‑ending stories

Stories too big

Product Owner without power or domain knowledge

More than 1 Product Owner

Product Backlog not maintained

Product Owner surprised at Sprint Demo

Product Owner not prioritizing

Product Owner being a boNleneck

Agile Product Ownership in a Nutshell

hNp://youtu.be/502ILHjX9EE

agile product owner in wonderland!

Software