Slide deck from my talk/workshop at Agile 2012 in Dallas Texas, Tuesday August 14 2012. The title is "Working Effectively with User Stories" The workshop and talk covered four main topics: 1. Silent Grouping: A technique for sizing large sets of user stories 2. Definition of Ready 3. Backlog Grooming 4. Tracking Progress as part of Daily Standups

1. WORKING
EFFECTIVELY WITH
USER STORIES
Ken Power

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

3. 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/

4. What are we estimating?
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?

5. RELATIVE SIZING

6. How big is the pile of work?

7. SIZING USER STORIES

9. 1 2 3 5 8 13 21 34

10. 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.

11. 1 2 3 5 8 13 21 34
Do something cool Do something cool Do something cool
Do something cool Do something cool
Do something cool
As a As a As a
User
Do something cool User User As a As a
Do something cool As a I want to I want to I want to User User
User do something cool with the do something cool with the I want to I want to
do something cool with the
As a I want to product product product do something cool with the do something cool with the
User As a do something cool with the So that I can product product
So that I can So that I can
I want to User product benefit in some way benefit in some way So that I can So that I can
I want to benefit in some way
do something cool with the benefit in some way benefit in some way
So that I can
product do something cool with the benefit in some way
product
So that I can
benefit in some way So that I can
benefit in some way
Do something cool Do something cool Do something cool
Do something cool
Do something cool
As a As a As a
User
Do something cool User User As a
Do something cool As a I want to I want to I want to User
User do something cool with the do something cool with the I want to
do something cool with the
As a I want to product product product do something cool with the
User As a do something cool with the So that I can product
So that I can So that I can
I want to User product benefit in some way benefit in some way So that I can
I want to benefit in some way
do something cool with the benefit in some way
So that I can
product do something cool with the benefit in some way
product
So that I can
benefit in some way So that I can
benefit in some way
Do something cool
Do something cool Do something cool Do something cool
As a Do something cool
User Do something cool
I want to As a As a As a
User User As a
do something cool with the I want to
User
product I want to I want to User
As a
User do something cool with the do something cool with the I want to
So that I can do something cool with the
benefit in some way I want to product product product do something cool with the
do something cool with the So that I can product
So that I can So that I can
product benefit in some way benefit in some way benefit in some way So that I can
benefit in some way
So that I can
benefit in some way
Do something cool
Do something cool Do something cool Do something cool
As a
User Do something cool
I want to As a As a As a
User User
do something cool with the I want to
User
product As a I want to I want to
User do something cool with the do something cool with the do something cool with the
So that I can product
benefit in some way I want to product product
do something cool with the So that I can So that I can So that I can
product benefit in some way benefit in some way benefit in some way
So that I can
benefit in some way
Do something cool Do something cool Do something cool
As a As a As a
User User User
I want to I want to I want to
do something cool with the do something cool with the do something cool with the
product product product
So that I can So that I can So that I can
benefit in some way benefit in some way benefit in some way
Do something cool Do something cool Do something cool
As a As a As a
User User User
I want to I want to I want to
do something cool with the do something cool with the do something cool with the
product product product
So that I can So that I can So that I can
benefit in some way benefit in some way benefit in some way
Do something cool Do something cool
As a As a
User User
I want to I want to
do something cool with the do something cool with the
product product
So that I can So that I can
benefit in some way 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

12. The 6 myths of Product Development
High utilization of resources
[and people] will improve
performance Processing work in large batches
improves the economics of the
Our plan is great; we process
just need to stick to it
The sooner the project is started,
the sooner it will be finished
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
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#

13. Waste in Product Development
“Eliminating waste is the 1. Extra Features
most fundamental lean 2. Delays
principle, the one from 3. Handoffs
which all the other
4. Extra Processes
principles follow. Thus,
the first step to 5. Partially Done Work
implementing lean 6. Task Switching
development is learning 7. Defects
to see waste.” 8. Unused Employee
- Poppendieck and Poppendieck 2003 Creativity

14. 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”

15. STARTING RIGHT

16. Reminder: Definition of Done

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

18. Do something cool
As a
User
I want to
do something cool with the product
So that I can
benefit in some way
Concept Happy User

19. Level of Focus on the User Story
Product
Owners
Team
Concept Time
TStart Done Accept TEnd Ship It

20. Level of Focus on the User Story
Done
Product
Owners
Team
Concept Time
TStart Done Accept TEnd Ship It

21. Level of Focus on the User Story
Done
Ready
Product
Owners
Team
Concept Time
TStart Done Accept TEnd Ship It

22. Level of Focus on the User Story
Done
Ready
Product
Owners
Team
Concept Time
TStart Done Accept TEnd Ship It

23. Level of Focus on the User Story
Done
Ready
Product
Owners
Team
Concept Time
TStart Done Accept TEnd Ship It

24. Level of Focus on the User Story
Done
Ready
Product
Owners
Team
Concept Time
TStart Done Accept TEnd Ship It

25. Level of Focus on the User Story
Done
Ready
Product
Owners
Team
Concept Time
TStart Done Accept TEnd Ship It

26. Level of Focus on the User Story
Done
Ready
Product
Owners
Team
Concept Time
TStart Done Accept TEnd Ship It

27. Level of Focus on the User Story
Done
Ready
Product
Owners
Team
Concept Time
TStart Done Accept TEnd Ship It

28. 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

29. 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?

30. 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

31. 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

32. “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!

33. 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/

34. BACKLOG GROOMING

35. Continuously Groom the Backlog and Re-
evaluate where you are
Scope Current Active Next Iteration Iteration Distant
Iteration (Iteration N N+2 to N+3 Future
(Iteration N) +1) (Iteration N+4
and Beyond)
% 75% 50% 25% N/A
Certainty
Backlog Epics, User Epics, Epics, Ideas,
Item Stories, Use Themes, Themes, Features,
granularity Cases Features, Use Features, Themes, Wish
Cases Ideas lists

36. TRACKING PROGRESS

37. 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?

38. But …

39. Can start to break away from
Dreyfus model for individual, team and fixed rules, but have difficulty
troubleshooting;
Can start using advice in correct
organization progression Little or no
experience;
context;
Can start formulating some
principles but no “big picture”;
Not aware that the
a
Need a recipe nce No holistic understanding, and 5 – 10+ x
problem exists, or
can’t conceive that Perform don’t want it yet
there is a different 3-5 x
way of doing things
1-2 x Expert
Breakeven Proficient
Competent Primary sources of
knowledge and
Advanced information in any field
Beginner Continually look for better
Novice methods and better ways
of doing things
Vast body of experience
bili ty they can tap into and
Need e
c / Capa apply in the right context
peten the big picture
Com Frustrated by oversimplified information
Work from intuition, not
reason
Can reflect on previous poor task performance;
Can distinguish between
can reflect and revise to perform better next time
irrelevant details and
Can learn from experience of others; can
important details
understand and apply maxims (as distinct from
recipes)

41. Pay attention to body language

42. Planned Ready for
In Progress Done Accepted
(Ready) Test
Focus on the Work Items

43. 27 days since last Customer Release
48 days to next Customer Release
6 days to end of Iteration
4 open defects
Add some project context

44. 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
Add some event context

45. 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
Story Title ||| Story Title
|| Customer Visit
As a .. As a .. Thursday 15th
<user who requires this <user who requires this
feature> feature>
I want .. I want ..
<goal> <goal>
So that... So that...
<business justification> <business justification>
Understand how the work is aging

46. 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
Story Title ||| Story Title
|||| Tue 13th
|| Customer Visit
As a .. As a ..
<user who requires this <user who requires this
Thursday 15th
feature> feature>
I want .. I want ..
<goal> <goal>
So that... So that...
<business justification> <business justification>
Personalize the Work Items using Avatars

47. Identified In Progress Resolved
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
Becomes a
Keep an Obstacle Board record of
improvements

48. Time: Monday Tuesday
First thing in the
09:00 morning
Uninterrupted Uninterrupted
Focus Time Focus Time
12:30
Just before
Lunch
Lunch Time Lunch Time
1:30 Uninterrupted
Just after Lunch
Focus Time Uninterrupted
Focus Time
5:00
Late in the
afternoon
Just examples:
your times may
vary
The best time to have Daily Standups is
at natural break points in the day

49. Summary
Size User Stories using Silent Grouping
Don’t start working on anything that is not Ready
Continuous groom your backlog to get things Ready
Understand the life cycle of the work through User Stories

50. Thank You!