Powerful User Story Practices - Pega · PDF filePowerful User Story Practices ... creating...

© 2016 Pegasystems 1

Powerful User Story Practices

Steven Martin, PMI-ACP, CSPO, CSM

Senior Program Manager – Methodology & Governance

Pegasystems Project Office

October 5th, 2016


Workshop Objectives

• Gain insights into practices for more impactful User Stories

– Share practical User Story tips to try at your organization

• Understand importance of good User Stories for:

– Better solution delivery

– Lower project risk

– Greater transparency

• Clear up common User Story misunderstandings


Agenda

• What’s the problem?

– Recap some Agile values to help frame our User Story discussion

• Core Concepts for Product Backlogs and User Stories

– How Roadmaps influence User Stories

– Formatting considerations for better User Stories

– Role of Direct Capture of Objectives (DCO) in Refining User Stories

– How Definition of Ready and Definition of Done influence User Stories

• Selection of a few User Story tips and practices


What’s going on in the world today?


We live in a complex world

Moving quickly.

No longer stable.

Adjust & Learn.

Image Source: https://commons.wikimedia.org/wiki/File:Cynefin_framework_Feb_2011.jpeg

Traditionally, we have lived here.

“Stability” lead to concrete plans.

It’s not working.

https://commons.wikimedia.org/wiki/File:Cynefin_framework_Feb_2011.jpeg


Traditional Project Management vs Agile

The traditional view is the

assumption that projects are

linear; there is a stair step

pathway to a solution.

But from experience, we know

creating customer value is

more of a discovery process

than a building process.


Source: http://agilemanifesto.org

http://agilemanifesto.org/


Scrum is an Empirical Process

• Scrum is based upon applying an empirical process control mindset

• An empirical process embraces change versus discouraging it

– Knowledge comes from experience

– Make decisions based on what is known

• The 3 components of any empirical process are:

– Inspection

– Adaptation

– Transparency

Source: Sutherland, Schwaber, “The Scrum Guide”, 2016

http://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf


Implications for User Stories

• User Stories will evolve over time to solve your real problem,

not just what you perceive to be your problem

– Your backlog will reflect what you learn over time

• Relentless focus on maximizing value

– Consciously selecting not to do certain items

• User Stories progressively become more detailed over time

– Higher priority stories have more detail

– Lower priority stories have less detail

• Effective collaboration essential

– It’s Business, IT and Quality together


Core Concepts for Product Backlogs & User Stories


Product Backlogs

• A prioritized list of functional and non-functional “requirements” necessary to

develop, launch and/or sustain a successful product

– “Requirements” take the form of User Stories

– Based on outcomes desired, not technical details

– Is customer-centric

• Considered the single repository of desired work for the product

– Typically includes features, functions, bug fixes, issues, etc.

• Owned and prioritized by Product Owner


Are User Stories just “Agile” Requirements?

“Lightweight”

Requirements

User

Stories


What’s different with User Stories over Requirements?

User Stories Requirements

Who creates? “3 Champions” to Full Teams Typically only Business

Level of detail Just enough, open for negotiation High level of detail, specific; tends to cover

all possible combinations

Length of time to

create

Quick, placeholder for further

conversations and elaboration

Can be laborious, taking significant time to

complete

When created?

Timeliness?

Create when/as needed; reflect

current needs

Created far in advance; reflect needs at a

particular point in time, typically in the past

Primary Information

Transmission

Collaboration emphasized, write

down only what’s needed after

discussion

Written documentation

Hand-offs Low amount of hand-off;

expectation for collaboration

Tendency for high amount of hand-offs,

from Business to IT to Quality to …

Change Control Experiment, learn, expectation for

change

Lock down then implement significant

effort process for changes


So what is a user story, then?

From Mike Cohn:

“User stories are a part of an agile approach that

helps shift the focus from writing about

requirements to talking about them.

All agile user stories include a written sentence or two,

and, more importantly, a series of conversations about

the desired functionality.”

Source: https://www.mountaingoatsoftware.com/agile/user-stories

https://www.mountaingoatsoftware.com/agile/user-stories


CONVERSATION

CARD

CONFIRMATION

The 3 C’s of User Stories


Communication Effectiveness


So, where do you start?


Take a step to the side so we can jump forward…


Release Roadmaps

• Release Roadmaps help set “scope” over a series of deployments

• Some reasons for Release Roadmaps:

– Becomes a filter for user story creation and

backlog prioritization

– Gains consensus around the direction

– Avoids the “last/loudest” priority problem

– Prevents “too large” releases early in program

(everything plus the kitchen sink…)

• Tip: Start with a “happy path” for a limited target group,

then add exceptions

• Caution: A roadmap is not a contract…it will likely change over time


Name of Release /

Version (to where)

Release date

Key Features:

1. Feature A

2. Feature B

3. Feature C

Theme: Prove “?”

For <stakeholder X>,

this release provides

<what value>

Roadmap: Example Template

• Release date, driven by:

– An event or specific dates/schedule

– Level of functionality needed

• Name of Release / Version

– Make name meaningful

– Indicate where release will happen:

• Internal delivery to a platform, other team,

or release train

• Distribution to Production

• Theme

– Compelling reason to use by whom?

– Significant business value to the organization

• Planned feature set

– High-level descriptions of system services

that delivers value to the user/customer


Full CC exp’n/Mobile POC

R4 (to PROD)

1. Monitor performance

2. Run mobile POC

with client subset

(TBD)

3. Revise forms with

critical/moderate

improvements as

needed

• For remaining client

subgroups, submit

claim request for autos

via call center

• Pilot POC for mobile

with subgroup #1

June August October

1. Update/expand 2

forms with feedback

2. Auto validate

processing

confirmation

3. Auto send email

confirmation

4. Validate/revise

training materials

• For client subgroups 2-

4, submit claim request

for autos via call center

1. Revise forms with

critical/moderate

improvements and

bug fixes

2. Validate

performance

3. Establish POC for

mobile (customer

driven) claim

submission

• For client subgroups

5-10, submit claim

request for autos via

call center

• Create POC for mobile

app

First CC expansion

R2 (to PROD)Second CC expansion

R3 (to PROD)

April

1. Simple 2 forms (data

entry, data validation)

2. Send data to sub

system to initiate

processing

3. Validate manually in

sub system

4. Manually send email

confirmation

• For client subgroup #1,

submit claim request for

autos via call center

Pilot CC

R1 (to PROD)

Roadmap: Example Template


For your first release, brainstorm titles of all User Stories you think you need.

• Have a good title.

– Sounds obvious, right? Can be hard to do

• When you have hundreds of stories in backlog, need to quickly scan them to

find what you’re looking for

• Recommendations:

– No more than 5 words in title

– Action (Verb) + Noun format

• Don’t worry about detail now. It will come.

– If you have notes, write down, then move on.

• Who: Minimum “3 Champions” (more on this later…)

• Prioritize stories just on title alone


Example “Could Be Better” User Story Titles for Intake Process…


Example “This is Better” User Story Titles for Intake Process…


3 Champions Concept

• Concept of creating initial user stories (v0.1)

from 3 perspectives:

– Business

– Technical

– Quality

• Should be experienced in your domain

• Pro:

– Can quickly generate ideas / content

• Con:

– Will need to involve full team later

– Risk in missing something / considering

different approach


Next Step: Start to create User Story Content

• You have a prioritized list of User Story titles

• Now start to add the “Description”

• Who: 3 Champions (at a minimum…)


AS A WHO,

I NEED TO/WANT TO

DO WHAT,

SO THAT WHY

User Story Format


Specifying Who…

• Grounds the team in a

user-centered mindset

• Provides empathy and

understanding of target

customers

• Provides context for

what is being built or

designed

• Confirms focus for

implementation

Specifying What…

• Solves a problem or

takes advantage of an

opportunity

• Communicates the

feature, functionality, or

user goal

• Provides the

implementation as seen

by the user

Specifying Why…

• Indicates importance to

the “who”

– What’s in it for

them?

• Lets us understand how

we are providing value

• Moves us towards our

vision


Independent

Negotiable

Valuable

Estimable

Sized appropriately

Testable

“INVEST” helps ensure good User Stories


Independent

Negotiable

Valuable

Dependencies lead to problems estimating and prioritizing

Can select single story to work on

Stories are not contracts

Leave or imply some flexibility

To users and customers, not developers

Re-write developer stories to reflect value to users or customers



Estimable

Sized appropriately

Testable

Must be able to estimate them

Plans are based on user stories

Small enough to complete in one sprint

Bigger if further off on the horizon

Binary test result, either you coded the story or not

“Done” or “Not done”, no “partially finished” or “done except”



GUI

Business Logic / Rules

Database

Story 1 Story 2

Stories as Vertical Slices


Example Stories for Hypothetical Promotion Enrollment

As a Premium Member

I want to be automatically

enrolled in all eligible promotional

offers

So that I can take advantage of

benefits without having to (or

forgetting to) manually enroll.

As a Non-Premium member

I want to enroll in promotional

offers


special incentives on my

purchases.


What do you think?

As a Supervisor,

I want to run a report

So that I can see how many

registrations for promotions

have been made for Premium

and Non-Premium members.

As a Call Center Supervisor,

I want to see in real-time how

many customers have registered

for a promotion

So that I can make adjustments as

needed to promotion enrollment

scripts and awareness.


User Story Description is not enough...

• You also need Acceptance Criteria to tell a more full picture

• Acceptance criteria characteristics:

– A list of outcomes for a Product Owner

to accept a user story

– Clarification of the story

– Guide for testing

– Helpful for more detailed documentation

– A good tool for splitting and negotiation


Example Acceptance Criteria

As a Premium Member

I want to be automatically enrolled

in all eligible promotional offers


benefits without having to (or

forgetting to) manually enroll.

This story is done when:

• Premium member is enrolled

automatically 1 week before the

promotion start date.

• Premium member receives email

they’ve been enrolled

• Account rep for top 10% of

Premium member is notified


Common Question:How much detail do you put in a User Story?

• Enough so that Teams can Size and Task user stories.


Priority drives detail

• Stories higher in priority have more detail, since they will likely be worked on in

the next 2 sprints

• Stories lower in priority have lower amount of detail

– Might be larger in size (not yet broken down)

– May be conceptual vs tactical


Next Immediate Sprint(s)

Current Release

Future Releases

As priority increases, Teams get closer to building solutions.

Stories have more detail and are in smaller, sprint-sized chunks.


Definition of Ready (DoR)

• Teams need to know when they can pull a story into a sprint

– Understand the “Why” and “What” is required

– Be able to size and task the story

• If user story is not ready, the Team should not pull it into a Sprint

– Reject it, get it refined well enough

• It will save everyone heart-ache and issues during the sprint itself…

• Teams should partner with PO to agree upon together what should be in the

Definition of Ready


The detail in the User Stories will vary based upon DoR

• Examples of DoR may include:

– User Stories (description, acceptance criteria) in proper format

– Flow Mockups

– UI Mockups/Wireframes

– Dependencies resolved

• This will vary depending on the maturity and experience of the teams

• May need to split or combine user stories (that’s ok!) so they fit within a sprint


Product Backlog Refinement

• Purpose:

– Keep the Product Backlog up to date: description, details, estimates, prioritization

• Guidelines:

– Requires PO, Team. Good to have Scrum Master (SM) as facilitator

– Occurs during the Sprint

– PO (and likely BAs) will typically spend 70%+ time on backlog refinement for future

sprints

– Team should budget ~10% of the capacity for refinement

• Translates to about ~8 hours per 2 week Sprint per person

– Recommend syncing up with entire team on the “off week(s)” from Sprint Planning

session

• Allows time to follow up on any action items before the next Sprint Planning

session


Example Calendar for a 2 Week IterationMonday Tuesday Wednesday Thursday Friday

Sprint Planning

Backlog

Sync-up

Sprint Planning

(Next Sprint)

Sprint Retro

Sprint Review

Daily Scrum Daily ScrumDaily Scrum

Daily Scrum Daily ScrumDaily ScrumDaily Scrum Daily Scrum

Daily Scrum

Refine

(Next Sprints)

Refine

(Next Sprints)

Refine

(Next Sprints)

Refine

(Next Sprints)

Refine

(Next Sprints)

Refine

(Next Sprints)

Refine

(Next Sprints)

Refine

(Next Sprints)


What is DCO’s role in User Story Refinement?

• Direct Capture of Objectives (DCO)

– Enabler and Accelerator of User Story Refinement

– Stages and Steps can be captured directly into the system

– Mock up the application quickly

• Quickly Draft the business process

• Quickly Draft the UI

• Immediate Execution to experience the process

– Frequent “Play Backs” with the business

• Direct feedback from the business

• Fast turnaround regarding business feedback

• “What you see is what you get”, no miss-set expectations

– User Stories come to life in draft


No

Yes

Conduct

Playback

DCO Session

Follow-Up

DCO Session

Execution

DCO Meeting

Prep

YesPrepare

Mockups

No

DCO

Ready?

DCO Session

Prep

Clarify Artifacts

DCO Session

Schedule

Start

Accept

?

End

Typical DCO Flow

Feedback

Refinement

Feedback

Feedback


Start Sprinting!


Definition of Done (DoD)

• User Stories satisfying acceptance criteria is not enough to say a story is

releasable

• Definition of Done:

– Set of activities required for stories to be considered complete so that the

increment of product functionality can be “potentially shipped”

• Some examples of DoD could be:

– Acceptance criteria accepted by PO

– Code/Rules reviewed

– Unit testing added to automation testing suite and all unit tests pass (not just

for code added this sprint)

– Regression test suite updated

– User documentation (as required) completed/updated


Definition of Done (DoD)

• The Team and PO need to come to agreement on DoD before planning first sprint

– DoD may vary from team to team – that’s OK as long as it’s transparent

– If multiple teams/POs are involved, there needs to be common agreement

– DoD often evolves over time as Dev Teams become more proficient


Summary: High Level User Story Maturity Progression

Stories

Identified

Stories

Refined

Stories

Executed

DoR

?

DoD

?Release

Identified Refined DoR Execution DoD

Minimum

Content

Title Title

Description

Acceptance

Criteria

Can Size

Can Task

Ref DoR

Add new

stories

Revise*

Remove*

Ref DoD from

Full Team

Involved 3 Champions

or Full Team

as appropriate

3 Champions

or Full Team

as appropriate

PO + Full

Team

PO + Full

Team

PO + Full

Team

Method Story

Workshop,

Initial DCO

session(s)

DCO DCO, Backlog

Sync-Ups, or

Sprint

Planning*

Usual Sprint

Execution

Usual Sprint

Execution

Vision &

Release

Roadmap

* Exceptions


Selection of User Story Practices & Lessons Learned


In Scrum, Stories must fit within the Sprint

• Want potentially shippable product

at the end of each sprint

• Therefore stories must be

written so that they can fit entirely

within a sprint

• Implies Product Owner must collaborate

with folks doing the work on the stories

to ensure user stories can be broken

down enough to fit in a sprint


Complex Problems:

We just don’t know enough…

Technical or Research

Spike(do first)

FunctionalStory(ies)

(do after Spike)

Compound Problems:

It’s just too big.

Multiple Functional Stories (prioritized)

Splitting Stories


Special Story Type: Spikes

• There are times when you may not know enough for a user story that

provides incremental value directly to a customer

• You may want to gain clarity on:

– Do we have a problem – solution fit?

– Is it even (technically) possible to do a solution?

• Use a spike!

– Be sure that the “So that” clause clearly identifies

what you are going to do with the information

once you have it

– Still have acceptance criteria

• What is it you need to know?

• This is a special case – use it sparingly

– The presence of multiple spikes indicates you may not have enough clarity in

understanding the problem and/or solution


Do you have an Epic?

• What is an Epic?

– Typically represents a large chunk of work

– May consist of 2 or more user stories

• What are characteristics of Epics?

– Still follows the same format of a story (title, description, acceptance criteria)

– Lives in the Product Backlog

– Unlike Stories, Epics do not have to fit within a Sprint

– Often start with Epics that eventually get decomposed down into user stories

• But, can also take a group of user stories and create an Epic as well


Relationships between Epics & User Stories

Tasks

1..n

2..n

1..n


Strive for approx. 2 sprints worth of refined User Stories

• Goal is to have enough stories with sufficient detail to allow for smooth Sprint

Planning session at beginning of the first Sprint

– Yet, not too many stories

• Have not received feedback yet on working software.

• If you have too many stories, could be wasted effort/time on stories that

may not be desired

– In our experience, a Product Backlog with approximately 2 sprints worth of

refined User Stories is healthy for teams


Q&A


Closeout


Key Nuggets to Take Away…

• User stories are not “lightweight” requirements

– Emphasis in collaboration and communication over documentation

• While User Stories are responsibility of PO, takes perspectives from Business,

IT and Quality

• User stories evolve over time

– Start with Release Roadmap

– Generate Titles of User Stories

– Add Description and Acceptance Criteria

– Use DCO sessions to add needed details

• “INVEST” in your User Stories

• Keep ~2 sprints worth of User Stories in Product Backlog to Definition of Ready


References

http://www.amazon.com/Essential-Scrum-Practical-Addison-Wesley-Signature/dp/0137043295/

http://www.amazon.com/Essential-Scrum-Practical-Addison-Wesley-Signature/dp/0137043295/

http://www.amazon.com/gp/product/1932735984/

http://www.amazon.com/gp/product/1932735984/


The 2015 Scrum Series – Available for Replay!

www.pega.com/agile


Coming Soon – Agile Webinar Series

Lalig Musserian

Senior Program Manager,

Methodology and Governance

Pegasystems Project Office

Topic: Defining an Agile Change Control Process

Date: Wednesday, October 26, 2016

Time: 10:00 AM Eastern Daylight Time


twitter.com/pega

linkedin.com/company/pegasystems

http://www.twitter.com/pega

http://www.linkedin.com/company/pegasystems

Powerful User Story Practices - Pega · PDF filePowerful User Story Practices ... creating...

Documents

Transcript of Powerful User Story Practices - Pega · PDF filePowerful User Story Practices ... creating...