agile 2012 working effectively with user stories

WORKING EFFECTIVELY WITH USER STORIES Ken Power

Agenda • Sizing (large) sets of User Stories quickly • Definition of Ready • Backlog Grooming • Daily tracking of progress of User Stories

About me

• My day job § Co-Founder, Agile Office at Cisco §  Internal Agile & Lean Coach/Consultant

• Extra-curricular activities § Fellow of the Lean Systems Society (http://LeanSystemsSociety.org/) § Award-winning publications in Agile and Lean product development § Frequent speaker at major international Agile and Lean conferences §  Involved in organizing international Agile and Lean conferences §  Industry/academic collaborative research on Agile and Lean software development § Blog: http://SystemAgility.com/

Size: How big is the work?

Duration: How long will it take?

Date: When will the work be done?

Staffing: Who will do the work?

What are we estimating?

RELATIVE SIZING

How big is the pile of work?

SIZING USER STORIES

1 2 3 5 8 13 21 34

The Basic Steps

http://systemagility.com/using-silent-grouping-to-size-user-stories/

Power, Ken. "Using Silent Grouping to Size User Stories." In Agile Processes in Software Engineering and Extreme Programming 12th International Conference (XP 2011). Madrid, Spain: Springer Lecture Notes in Business Information Processing (LNBIP), 2011.

1 2 3 5 8 13 21 34 Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

The 6 myths of Product Development

D.#G.#Reinertsen,#“The$principles$of$product$development$flow$:$second$genera8on$lean$product$development”.#Redondo#Beach,#Calif.:#Celeritas,#2009.###S.#Thomke#and#D.#Reinertsen,#"Six$Myths$of$Product$Development,"#Harvard#Business#Review,#vol.#90,#pp.#84G94,#May#2012#

High utilization of resources [and people] will improve performance Processing work in large batches

improves the economics of the process Our plan is great; we

just need to stick to it

The more features we put into a product, the more customers will like it

We will be more successful if we get it right the first time

The sooner the project is started, the sooner it will be finished

Waste in Product Development “Eliminating waste is the most fundamental lean principle, the one from which all the other principles follow. Thus, the first step to implementing lean development is learning to see waste.”

- Poppendieck and Poppendieck 2003

1.  Extra Features 2.  Delays 3.  Handoffs 4.  Extra Processes 5.  Partially Done Work 6.  Task Switching 7.  Defects 8.  Unused Employee

Creativity

Premature Precision “Both business and programmers are tempted to fall into the trap of premature precision. Business people want to know exactly what they are going to get before they authorize a project. Developers want to know exactly what they are supposed to deliver before they estimate the project. Both sides want a precision that simple cannot be achieved, and are often willing to waste a fortune trying to attain it.”

-  Robert C. Martin (Uncle Bob) “The Clean Coder: A Code of Conduct for Professional Programmers”

STARTING RIGHT

Reminder: Definition of Done

Sycnhronization Point Definitions of Ready & Done act as focusing anchors for teams, management, and everyone involved in creating and delivering the product

Concept Happy User

Do something cool

As a User I want to do something cool with the product So that I can benefit in some way

Product Owners

Team

Leve

l of F

ocus

on

the

Use

r Sto

ry

Concept TStart TEnd Ship It Done Accept Time

Product Owners

Team

Leve

l of F

ocus

on

the

Use

r Sto

ry

Concept TStart TEnd Ship It Done Accept

Done

Time

Product Owners

Team

Leve

l of F

ocus

on

the

Use

r Sto

ry

Concept TStart TEnd Ship It Done Accept

Ready

Done

Time

Product Owners

Team

Leve

l of F

ocus

on

the

Use

r Sto

ry

Concept TStart TEnd Ship It Done Accept

Ready

Done

Time

Product Owners

Team

Leve

l of F

ocus

on

the

Use

r Sto

ry

Concept TStart TEnd Ship It Done Accept

Ready

Done

Time

Product Owners

Team

Leve

l of F

ocus

on

the

Use

r Sto

ry

Concept TStart TEnd Ship It Done Accept

Ready

Done

Time

Product Owners

Team

Leve

l of F

ocus

on

the

Use

r Sto

ry

Concept TStart TEnd Ship It Done Accept

Ready

Done

Time

Product Owners

Team

Leve

l of F

ocus

on

the

Use

r Sto

ry

Concept TStart TEnd Ship It Done Accept

Ready

Done

Time

Product Owners

Team

Leve

l of F

ocus

on

the

Use

r Sto

ry

Time Concept TStart TEnd Ship It Done Accept

Ready

Done

Why have a Definition of Ready?

• So everyone knows when a User Story is really ready to be pulled in by the team §  It does not need to be “100% defined” with all acceptance criteria, etc. §  It does need to be “ready enough” so that the team is confident they can successfully deliver

Exercise/Discussion:

So, what do we need to do to make sure a User Story is really Ready to be pulled

in by the team?

Definition of Ready for a User Story

• User Story defined • User Story Acceptance Criteria defined • User Story dependencies identified • User Story sized by Delivery Team • Scrum Team accepts Ux artefacts • Performance criteria identified, where appropriate • Person who will accept the User Story is identified • Delivery Team has reviewed and accepted the User

Story •  Team has a good idea what it will mean to Demo the

User Story

Definition of Ready for an Iteration

•  The Iteration Backlog is prioritized •  The Iteration Backlog contains all defects, User

Stories and other work that the team is committing to § No hidden work § Examples of ‘other work’ might include lab setup, build environment maintenance, creating a test app, working on your manager’s pet project, supporting another product

• All team members have noted their capacity for the Iteration

• All User Stories meet Definition of Ready

“Never pull anything into a Sprint that is not Ready. Never let

anything out of a Sprint that is not Done.”

- ? Sorry: can’t recall the Source!

Consequences of not being Ready •  The Team is estimating and forecasting that they can

finish vague and incomplete stories. •  They waste time and energy trying to get clarity from the

Product Owner on exactly what the story means. • People get frustrated and annoyed and run around in

circles rather than getting down to work. •  That one vague story actually turns out to be five real

stories once the work is actually begun. •  They work on the wrong thing, or the right thing in the

wrong way, forcing the work to be re-done. Jeff Sutherland (2012). "The Dangers of Not Being Done, Or Ready For That Matter”. Available from http://scrum.jeffsutherland.com/

BACKLOG GROOMING

Continuously Groom the Backlog and Re-evaluate where you are

Scope Current Active Iteration

(Iteration N)

Next Iteration (Iteration N

+1)

Iteration N+2 to N+3

Distant Future

(Iteration N+4 and Beyond)

% Certainty

75% 50% 25% N/A

Backlog Item

granularity

Epics, User Stories, Use

Cases

Epics, Themes,

Features, Use Cases

Epics, Themes, Features,

Ideas

Ideas, Features,

Themes, Wish lists

TRACKING PROGRESS

Typical Daily Standup questions •  What did you do since we last met? •  What will you do before we meet again? •  What obstacles are in your way?

But …

Dreyfus model for individual, team and organization progression

Novice

Advanced Beginner

Competent

Proficient

Expert

3-5 x

5 – 10+ x

1-2 x

Breakeven

Performance

Competence / Capability

Not aware that the problem exists, or can’t conceive that there is a different

way of doing things

Little or no experience;

Need a recipe

Can start to break away from fixed rules, but have difficulty

troubleshooting; Can start using advice in correct

context; Can start formulating some

principles but no “big picture”; No holistic understanding, and

don’t want it yet

Need the big picture Frustrated by oversimplified information Can reflect on previous poor task performance; can reflect and revise to perform better next time Can learn from experience of others; can understand and apply maxims (as distinct from recipes)

Primary sources of knowledge and information in any field Continually look for better methods and better ways of doing things Vast body of experience they can tap into and apply in the right context Work from intuition, not reason Can distinguish between irrelevant details and important details

Pay attention to body language

Planned (Ready) In Progress Ready for

Test Done Accepted

Focus on the Work Items

Add some project context

27 days since last Customer Release 48 days to next Customer Release 6 days to end of Iteration 4 open defects

Add some event context

27 days since last Customer Release 48 days to next Customer Release 6 days to end of Iteration 4 open defects

Time Off: Mary (Holidays – 3d) Joe (Holidays – 1 wk) John (Training – 2d) Exec Demo Tue 13th Customer Visit Thursday 15th

Time Off: Mary (Holidays – 3d) Joe (Holidays – 1 wk) John (Training – 2d) Exec Demo Tue 13th Customer Visit Thursday 15th

Understand how the work is aging

27 days since last Customer Release 48 days to next Customer Release 6 days to end of Iteration 4 open defects

Story Title

As a .. <user who requires this

feature> I want ..

<goal> So that...

<business justification>

||| Story Title

As a .. <user who requires this

feature> I want ..

<goal> So that...

<business justification>

|||| || \

Time Off: Mary (Holidays – 3d) Joe (Holidays – 1 wk) John (Training – 2d) Exec Demo Tue 13th Customer Visit Thursday 15th

Personalize the Work Items using Avatars

27 days since last Customer Release 48 days to next Customer Release 6 days to end of Iteration 4 open defects

Story Title

As a .. <user who requires this

feature> I want ..

<goal> So that...

<business justification>

||| Story Title

As a .. <user who requires this

feature> I want ..

<goal> So that...

<business justification>

|||| || \

Identified In Progress Resolved

Keep an Obstacle Board Becomes a record of

improvements

Obstacle Title

Scrum Master: Name Date Opened: 8-Jan-2012 Date Closed: 14-Feb-2012 Description: alsdals,d askdkas asdkma Asdasd lasdlkalskd alksdl asd asdaskl Resolution: askdmkasd asd asdj nasd Asdasdj asjdj nasd

The best time to have Daily Standups is at natural break points in the day

Time: Monday Tuesday

09:00

12:30

Lunch Time

1:30

5:00

First thing in the morning

Just before Lunch

Late in the afternoon

Just after Lunch

Just examples: your times may

vary

Lunch Time

Uninterrupted Focus Time Uninterrupted

Focus Time

Uninterrupted Focus Time Uninterrupted

Focus Time

Size User Stories using Silent Grouping

Don’t start working on anything that is not Ready

Understand the life cycle of the work through User Stories

Continuous groom your backlog to get things Ready

Summary

Thank You!