product owner breakout

Product Owner Breakout Session

Acquia Engage 2015 Jen Weiss, Sr. Director Delivery

Purpose and Objectives

Ø  Purpose Ø  Reinforce the Product Owner’s role and skills needed, as well

as their impact on the quality and success of a project Ø  Objectives

Ø  Instill Agile as a state of mind as much as a development and delivery methodology

Ø  Create an understanding of roles and responsibilities Ø  Clearly differentiate the role of the Product Owner in Agile

Agenda Ø Agile Primer Ø The Product Owner Challenge Ø Prioritization Ø Story Writing and Grooming Ø Best Practices Ø Wrap-up and Feedback (Retrospective)

Considerations Ø  Is your team co-located or distributed? Ø  Is this a product or a project? Ø How engaged are your stakeholders? Ø What is the organization’s agile maturity?

Ø These are suggestions and recommendations – need to determine what’s right for your team and continuously improve

What is Agile? Ø What does “Agile” mean to you?

Ø  “When looking at the agile process, it is important to understand that agile is an umbrella term used to describe a general approach to software development. Though there are many agile incarnations, all agile methods, including the Scrum agile process, emphasize teamwork, frequent deliveries of working software, close customer collaboration, and the ability to respond quickly to change.” – Mountain Goat Software

Ø Agile is more than a development methodology – it’s a lifestyle

Waterfall vs. Agile Ø Takes a long time to go from

ConceptàDeploy Ø Doesn’t allow for learning or

feedback Ø Can work well for complex

integrations where there are many dependencies

Waterfall vs. Agile Ø Actively incorporate learning

and user feedback Ø Provides ‘fast track’ from

ideationàdeployment Ø Business-driven decisions Ø Can accommodate

integration with waterfall teams

Term Description

Product Owner (PO) Represents the users and stakeholders of the product to ensure the right features make it through to the Product Backlog. They guide the product… product roadmap, priority, and communicates needs of the business.

Scrum Master Ensures the project is progressing smoothly, and that every team member has the tools they need to get the job done. In charge of removing any impediments to progress for the team. Facilitates and coaches.

Scrum Team A group of developers and testers that gets the job done. May include other groups (such as Designers) if they will have stories assigned to them.

End Users These are the people who will use the deliverable from the Scrum Team. Includes public users, internal content editors, site administrators, etc.

Stakeholders Anyone impacted by or interested in the project. Typically includes clients/business owners, IT, portfolio managers and management.

Agile/Scrum Key Terms - Team

Term Description

Product Backlog A wish list of features the business would like to implement for the product. Typically, the backlog is prioritized to align with business value/needs.

Release Backlog Epics and Stories from the Product Backlog that represent the intended scope of the release (to be broken down and delivered via sprints).

Release A planned scope of work (a Release Backlog) that usually involves a formal launch or release notification to Stakeholders and End Users. A Release is comprised of one or more sprints and deployments.

Sprint A short duration milestone that gets elements of a product to a ship ready state, taking prioritized stories from the Product Backlog. Sprints start and end on predefined dates.

Deployment The physical deployment of code to an environment. There can be multiple deployments to Production during a Release.

Burn Down A means of tracking progress for Releases and Sprints. It represents the progress made on completing story points or hours.

MVP

The Minimally (or Minimum) Viable Product is the version of a product that provides sufficient features to satisfy early adopters (this is a LEAN concept). This allows for product feedback to be taken into account for the next release planning cycle. This is a LEAN concept aimed at maximizing value by only putting effort into those features that have been verified as important (rather than assuming).

Agile/Scrum Key Terms - Entities

Term Description

Release/Sprint Planning

Performed at the start of a Release or Sprint, it pulls items from the Product or Release Backlog into the Release or Sprint Backlog. Items are pulled based on their business impact, priority and alignment with the product roadmap.

Daily Scrum

A daily standup meeting with the team that asks What did you get done yesterday? What will you work on today? Are there any obstacles in your way?

Sprint Demo An event that occurs at the end of each sprint where the Scrum Team showcases each Story delivered in the Sprint to the Product Owner. Ideally, approval to deploy is provided.

UAT

Performed by the Product Owner, User Acceptance Testing (UAT) validates each story to confirm it meets the requirements. This can be performed at any point during the sprint, but a final pass is usually done at the end of the Sprint once all Stories have been completed. UAT typically differs from Quality Assurance (QA) in that QA is usually done by a member of the Development or QA group in a lower environment.

Retrospectives Retros are integral to the feedback cycle. They are the last step in a Sprint and occur after the Sprint Demo (to capture all feedback) and before Sprint Planning (to ensure feedback is incorporated). There are several approaches, just try to be consistent.

Agile/Scrum Key Terms - Ceremonies

Term Description

Feature A roadmap item that can span multiple releases. This can correlate to an entire project (portfolio item) or a major feature within a project.

Epic A high level Story on the roadmap and HLP that equates to scope.

Story (Cards) High level Stories and/or dependencies created by each team in support of Epics. These are given Story Points and assigned to Releases during Release Planning.

(Groomed) Story A Story with sufficient details, acceptance criteria, UX considerations, workflow, etc. to be handed off to a Scrum team for tasking and estimation. As a rule of thumb, a Story should be fully groomed at least 2 days prior to the start of the sprint to qualify for inclusion in a sprint.

Tasks Each member of the Scrum Team is responsible for breaking down their stories into individual tasks (activities and steps of doneness) that can be estimated in hours. The Scrum Master ensures that the hours fit into the time allotted for the Sprint and raises issues accordingly.

Technical Debt Technical Debt that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. Stories documenting Technical Debt are created so that system limitations are documented in the backlog for prioritization in a later sprint.

Agile/Scrum Key Terms - Stories

Term Description

Story Points Story Points are assigned at a high level as part of Release Planning and are used to ensure consistency and gauge Velocity.

Estimation When you plan tasks at the start of the Sprint, you know the detailed acceptance criteria, the detailed task list, and who is doing the work. Estimating tasks in hours reflects the precision of the estimate.

Defects Defects are generated once a developer asserts they are ‘done’ with the story. Defects may be completed as part of the sprint or placed in the backlog for future consideration. Well groomed Stories, solid Acceptance Criteria and adherence to best development practices all aim to keep the defect rates low.

Bugs Bugs are issues that have made it thru testing or are introduced based on newer functionality. There is no such thing as bug free software!

Definition of Done This clearly defines when a Story can be considered complete from a development perspective and handed off for UAT. This may include development, peer review, QA and documentation.

Spike A Spike is a story with a very specific goal and time-boxed effort. This is often used to capture effort associated with researching/sizing out of scope items.

Agile/Scrum Key Terms - Stories

Continuous Delivery Lifecycle Anatomy of a Release�

Ø  Release planning builds off of the Release Backlog Ø  Agile process sprints completed on a 2 week cadence Ø  Story grooming done throughout the Release Ø  Code deployments scheduled during or at the end of the Release Ø  Story delivery time-boxed to fit within sprints Ø  Features and Release Backlog tracked via burn down

Ø  Plan: Ø  Size/estimate fully groomed user stories Ø  Define test coverage plans

Ø Develop: Ø  Build/fix functionality against definition Ø  Create test functions & scripts

Ø  Test: Ø  Test stories to executable specifications Ø  Report planned results against documented bugs/stories

Ø Demo: Ø  Communicate and document feature/bug fix

Anatomy of a Sprint

Teams and Planning Ø Capacity vs. Velocity

Ø Capacity is the amount of available work hours (hands to keys) that a Scrum Team can provide

Ø Velocity is the number of story points the team can complete –what the team can deliver with the given capacity

Ø Self-organizing teams are engaged, informed and accountable Ø Responsible for sizing/estimating, ‘grabbing’ and delivering

Ø Story sizing is performed by the Scrum Team, usually during planning

The Challenge… The key to achieving and maintaining team velocity

Why wasn’t my Agile project successful???

“That isn’t how I thought

the functionality would work”

“Too many issues arose at the end of the

delivery” “There were features that didn’t work or weren’t

stable”

“This project didn’t meet my stakeholder’s expectations”

“There was too much back and forth

on issues”

“I didn’t feel like we knew

what was included in releases”

Qualities of a Good Product Owner

Strong, empowered and engaged is paramount to success

Ø  Accessible, available and engaged Ø  Thorough understanding of needs (Marketing, Product, End Users, etc.)

Ø  Enhances ability to prioritize and facilitate grooming Ø  Good stakeholder manager

Ø  Coordinate with internal organizations Ø  Managing expectations leads to fewer sprint disruptions

Ø  Able to function as a Business Analyst (or have ready access to one or more SMEs) Ø  Basic knowledge of how software is developed and deployed

Ø  Understanding/appreciation for how a team works and the importance of quality measures Ø  Willingness to say “No”

What does a Product Owner do?

Focus on describing and prioritizing requirements

Ø  Actively manages the product backlog in the ticket system Ø  Writes epics/user stories and validates output through UAT

Ø  “Go to” person for product/domain Ø  Captures business requirements through user stories and grooming sessions

Ø  Available to answer questions when they arise Ø  Provides feedback to the team Ø  Signs off on deliveries (stories, sprints and deployments) Ø  Commits to Agile ceremonies

Ø  Bi-weekly: sprint planning, demo and retro Ø  Weekly: story grooming, status Ø  Daily/As needed: testing, questions

What does a Product Owner not do?

Does not need to be a Drupalist

Ø  Does not size or estimate stories Ø  This is done by the development/scrum team

Ø  Does not need to attend daily scrums Ø  Should not change the contents of a sprint once planning is complete

Ø  There should be a defined communication process in place if this is necessary Ø  Does not change the scope or definition of story once it’s in a sprint

Ø  Additional stories can be created for subsequent sprints to address changes or the story can be pulled and re-groomed

Ø  Should not need to dictate technical solution or implementation (unless it’s actually a stated requirement)

Product Owner Impact on Quality

Involved in all aspects of quality – from definition to delivery

Ø  Prioritization Ø  Ensuring stakeholders are getting what they need

Ø  Story Quality (Grooming) Ø  Properly groomed stories are the starting point for all quality initiatives

Ø  Sprint Testing Ø  PO, BA(s) and/or SME(s) perform functional testing during the sprint (typically in a QA)

Ø  User Acceptance Testing (UAT) Ø  Following Sprint Demo, may perform a level of functional or regression testing prior to deployment Ø  Usually involved in post-deployment smoke testing

Ø  Retrospective feedback

Product Owner Communications

Proper communication instills confidence

Ø  What you might receive Ø  Burn down charts (sprint, release) Ø  Sprint status Ø  Project status Ø  Quality reports

Ø  What you might provide Ø  Roadmaps to the team (provides direction) and to stakeholders (transparency and alignment) Ø  Stakeholder progress reports (manage expectations) Ø  Performance to KPIs (shows team’s ability to deliver) Ø  Executive briefing/status reports

Accept the Challenge! Ø  Be the driver for organization change Ø  Be patient – progress comes with each successful sprint and

project Ø  Never stop learning and educating through communication

Why are we here? What are we doing?

Breaking

rocks?

Making

walls?

Building

cathedrals?

?

What do we mean by “Purpose”? Ø Your PURPOSE should be the boldest, broadest aspiration

defined by your organization, and the reason why everyone wakes up in the morning and comes to work. It should infuse passion into whomever reads it.

To organize the world's information and make it universally accessible and useful

What do we mean by “Vision”? Ø Your VISION describes the future state of the world after you have

made significant progress in achieving your fundamental purpose.

To provide access to the world’s information in one click.

Ø Unlike the Purpose statement, it is a more tangible, measurable goal with a time frame attached that stretches you to achieve your goal. Your vision should create some tension in the organization as you strive to achieve it. Once you get close to realizing your vision, it is important for you to reset it to re-establish the creative tension.

* From Jim Collins, Good to Great (2011)

KPIs and Measurements Ø KPIs are a vector in making progress toward your Vision Ø Consist of 2-4 high level measurements such as: Ø Reduced cost Ø  Increased traffic or usage Ø  Improved (ACE) user satisfaction Ø  Increased sales through targeted content (click thru)

* From Jim Collins, Good to Great (2011)

Prioritization!

Product Backlog(s)

Product Integrations

Issue / Bug

Enhancement

Release Backlog


Issue / Bug

Enhancement

Release Backlog


Issue / Bug

Enhancement

Release Backlog


Issue / Bug

Enhancement

Sprint Backlog

Sprint Backlog

Sprint Backlog

Sprint Backlog

Product

Integrations

Sprint Backlog

Sprint Backlog

Sprint Backlog

Sprint Backlog

Sprint Backlog

Release Roadmap Ø Objective Ø Start building the consistent communication tool of what

the project/program will do for multiple stakeholders Ø Surface “release themes” based on priorities and

measurements Ø Activities Ø “Force Rank” plotted epics/stories to ensure they are

sequenced in the right order Ø Transfer everything onto the roadmap board, within the

appropriate measure focus area * From Jim Collins, Good to Great (2011)

Sample Prioritization Grid

INVEST in Great Stories Independent Can it be delivered without delivery of another story blocking it? Negotiable The story should be mutable, subject to change or destruction at

any time until it is committed to a sprint plan Valuable Will the end user gain from it’s implementation?

Estimable Is the story clear enough and is there enough information where it can be sized? Without a size, it will never go from the backlog to a release plan or sprint plan

Small Can the team commit to delivering the story within a single sprint?

Testable Is there an executable specification available? Will the team know when they are done?

Anatomy of a Story • As a [ ], I want the ability to [ ] so that I can [ ]. • Easily accessible and understood at a high level by business and Scrum team

• If it’s not captured here then it will not get done • Can be done during grooming or as part of the original story creation • The team will use to guide their estimate, design and implementation of the story • Written in a standard Given-When-Then format • These are the exact tests the QA team (and UAT) will perform • May also be referred to as the executable specification

• Discussion/clarification points captured in notes • Anything pertinent to the story should be included either in the Story portion or as Acceptance Criteria

Establish Responsibilities Story Components

Product Owner

BA QA Scrum Master

TA Lead Dev

User Story A R - C S -

Acceptance Criteria/Test Steps A R I C S I

Implementation Guide I I I I A/R S

Testing Criteria C S S I A/R S

Estimates I S S I A/R S

Responsible (R) Those responsible for the task, who ensure that it gets done. Accountable/Approver (A) The one ultimately answerable for the correct and thorough completion of the task Support (S) Those who help complete the task. Consulted (C) Those whose opinions are sought; and with whom there is two-way communication. Informed (I) Those who are kept up-to-date on progress; and with whom there is one-way communication.

Find the right mix for your team

Story Hierarchy�

Tasks

Stories

Epic

Feature Product

Ratings

Moderate User Info

Technical Design

Develop / Unit Test Peer Review

Data Capture

Associate Topics Segmentation

-  Product Roadmap Item -  Created by Portfolio Manager or Product Owner -  Will likely have multiple Epics -  Track progress over multiple releases

-  Functionality for a feature -  Created by Product Owner -  Will have one or more stories -  Track progress over multiple sprints

-  Specific requirement for an Epic -  Created by Product Owner (or Team) -  Fits within a single sprint -  Represents new feature, issue or defect

-  Created by Scrum Team -  Used to track granular activity -  These are not for UAT

Product

Ratings

Moderate User Info

Technical Design


Data Capture


Story Hierarchy - Feature� As a Product Marketer, I want to provide a page (or series of pages)

where potential customers can go to learn about my product so that I can capture leads.

Product

Ratings

Moderate User Info

Technical Design


Data Capture


Story Hierarchy - Epic� As a Product Marketer, I want to give users the ability to

rate my products and have them moderated and shared on the page(s). As a Product Marketer, I want the ability to capture specific information about my page visitors to create context sensitive links on the page(s).

Product

Ratings

Moderate User Info

Technical Design


Data Capture


Story Hierarchy - Story�

As a Product Marketer, I need the ability to associate topics to market segments. As a content editor, I need the ability to tag content so that it renders for the appropriate audience/segment.

Product

Ratings

Moderate User Info

Technical Design


Data Capture


Story Hierarchy - Story

As a user, I want the ability to rate and comment on a product I have purchased. As a Product Marketer, I want to moderate user comments and ratings. As a Product Marketer, I want to store user information on those that have provided ratings for follow up.

Description: As a Product Marketer, I want to moderate user comments and ratings before they are available to others on the site. This should be consistent across all browsers and platforms, including the mobile app.

Acceptance Criteria:

Given that a user has created a rating with comments, a Product Marketer with moderator rights can choose to accept or reject the user entry.

Testing Steps (How To Demo): 1.  Log in as Product Marketer and navigate to the Product page. 2.  Locate a Review with a status of “Needs Moderation”. 3.  Change the status to “Approved”. 4.  Log out, go to the Product page and confirm the new review is visible. 5.  Repeat steps 1à3, but change the status to “Rejected”. 6.  Log out, go to the Product page and confirm the new review is not visible.

Story Example

Description: Acceptance Criteria: Testing Steps (How To Demo):

Story Exercise #1


Story Exercise #2


Story Exercise #3


Story Exercise #4

Issue Example Description:

As a site visitor, I want to see lists appear alphabetically in my native language. This applies to all browsers/platforms.

Steps to Reproduce: 1.  Go to the homepage, or any page with the language selector. Click the language

selector, and pick a language. 2.  The country list will appear in that language, but the alphabetical order will be wrong;

the countries will be in the same order they were in for English. Current Results:

Lists stay in whatever alphabetical order is in English. Expected Results:

Lists should appear in alphabetical order in whatever language the user has selected.

Practice Good Grooming Ø Come prepared to grooming sessions

Ø Early on, best to set aside some discussion time for stories still in discovery to ensure you can cover the stories actually ready to groom

Ø Capturing what isn’t part of a story (or an exception) is just as important as what is included

Ø Make sure the business requirements are communicated to the team (not the solution)

Ø Listen and Learn!

Practice Good Grooming Ø The Scrum Team ultimately determines if a story is groomed

Ø Be patient - this will take time! Ø Think critically – you are the expert in what you want your system to do, so think thru scenarios, workflows, etc.

Ø Don’t forget the ACE up your sleeve Ø Administrators, Content Editors/Contributors and End Users

Consider training and usability Ø Capture as much info as you can Ø Agile foregoes extensive documentation, but still need to properly

groom stories and capture discussion and clarification points in the stories (and ticketing system)

Ø Consider end user documentation, FAQs, etc. – this cuts down on the ‘noise’ later on

Ø …..remember to create and prioritize stories for this!

Best Practices Ø Make sure to include stories for sprint or deployment-related activities

Ø  Specific deployment tasks Ø  Should include all activities related to a story when sizing

Ø  Technical Design Ø  Development/Unit Testing Ø  QA

Ø  Establish guidelines for points Ø  Effort correlations? Ø  Relative sizing? Ø  Just be consistent

“A good system shortens the road to the goal” – O.W. Marden

Best Practices Ø Epics Ø High-level stories (cards) that contain the business justification/case Ø Usually have 2 or more stories nested beneath Ø Delivery of an epic can span multiple sprints/teams

Ø Stories / Issues Ø Assigned to a specific person Ø Take the form of an executable specification Ø Must fit within a sprint Ø Must be fully groomed to be considered for inclusion in a sprint

Ensure completeness of issues/requirements

within tickets

Best Practice Ø Come prepared to grooming sessions

Ø Early on, best to set aside some discussion time for stories still in discovery to ensure you can cover the stories actually ready to groom

Ø Capturing what isn’t part of a story (or an exception) is just as important as what is included

Ø Listen and Learn! Ø The Scrum Team ultimately determines if a story is groomed

Ø Be patient - this will take time! Ø Think critically

Ø You are the expert in what your system to do, so think thru scenarios, workflows, etc. Ø Don’t forget the ACE up your sleeve

Ø Administrators, Content Editors/Contributors and End Users Practice good grooming

Consider training and usability Ø Capture as much info as you can Ø Agile foregoes extensive documentation, but still need to properly

groom stories and capture discussion and clarification points in the stories (and ticketing system)

Ø Consider end user documentation, FAQs, etc. – this cuts down on the ‘noise’ later on

Ø …..remember to create and prioritize stories for this!

Best Practices Ø Sprints start/end on designed dates Ø Stories not completed by the end of the sprint move to the next sprint Ø This is important to establishing and measuring velocity and burn down

Ø Don’t ignore technical debt Ø The goal is to ensure that short term informed decisions are corrected Ø If too much debt accumulates, maintenance and upkeep becomes

burdensome (and can ultimately far outweigh the early benefits)

Stick to the established sprint cadence

Best Practices Ø Don’t skip the retrospectives! Ø Feedback is imperative to the Agile process – it ensures that the

team can adjust to ensure consistent quality deliverables Ø Helps to refine the communication process and assist in managing

stakeholder expectations

Constant improvement is key to Agile’s success

“It is not the strongest of the species that survive, not the most intelligent, but the one most responsive to change.” - Charles Darwin

Feedback Ø Feedback

Ø What’s your overall opinion of the session? Ø What worked well? Ø What could be improved?

Useful Links Ø Mountain Goat Software Ø YouTube video Ø The Scrum Checklist

Thank You

product owner breakout

Documents