Agenda
 Why stories?
 What stories are?
 What stories are not?
 How to create a story?
 How to split a story?
 When ...
Why stories? Verbal communication
Why stories? Verbal communication
As an Administrator
I want the system to
constantly make sure it is healthy
so that I do...
Why stories? Verbal communication
As an Administrator
I can use a watchdog service
so that I know when the system stopped ...
Why stories? Comprehensible
Why stories? Comprehensible
As a Developer
I want a standard exception class and conventions
for use throughout all the se...
Why stories? Comprehensible
As a participant
I want to know what to do in the event of
an application malfunction
So that ...
Why stories? Comprehensible
As a participant I want to
know what to do in the
event of an application
malfunction so that ...
Why stories? Right size for planning
Why stories? Great for Iterative development
Why stories? Defer detail
Why stories? Defer detail
Release planning – no details
Iteration planning – increasing detail
Iteration – maximum detail
Why stories? Tacit knowledge
Why stories? Review
1. Do talk stories, don’t write novels
2. Write for dummies
3. Change stories as you need
4. Enough de...
What stories are?
What stories are? A reminder to talk
A phrase or two that act as a reminder to hold
the conversation
What stories are? A reminder to talk
Notes about issues resolved during the
conversation
What stories are? Common format
As a …. Kid
I want …. to carry my bucket in the neighborhood
So that …. I can get lots of ...
What stories are? Front side
Halloween fun
As a Kid
I want to carry my bucket in the neighborhood
So that I can get lots o...
What stories are? Flip side/Acceptance
• Put all crooks in jail
• Have at least 10 patrol cars on the streets
• Write a sa...
What stories are? Review
1. Reminder of a conversation
2. Try, make a mistake, and try again
3. If it’s bigger than a (lar...
What stories are not? requirements
What stories are not? requirements
1. The product shall have gasoline engine
2. The product shall have four wheels
a) The ...
What stories are not? requirements
SPEED GRASS MOWER
What stories are not? requirements
As a busy dad
I can mow the lawn easy and quickly
so that I have more time for my family
What stories are not? too specialized
As a Builder
I want each solution to contain an archetype
for folders in that soluti...
What stories are not? too specialized
As a doc-check
I want to be able to process New York three
times faster
so that I ca...
What stories are not? use cases
Use Cases Stories
Number of players Multiple single
Alternate routes yes no
Scope Large La...
What stories are not? use cases
Example: Builder use cases
What stories are not? Interaction design scenarios
Heroflows Stories
Number of actors One or more single
Level of details ...
What stories are not? Interaction design scenarios
Example: Creating a new library & content type
What stories are not? Review
Interaction design
scenario
Use Case
Complete description of
Story & Acceptance
Criteria
Stor...
What stories are not? Review
1. A story is a tool to capture requirements on
the move, not the requirement itself
2. Use c...
How to create a story? The perfect story
Negotiable
Valuable to Purchasers and Users
Estimable
Small
Testable
How to create a story? Team effort
• Create a Product Owner (or Customer) Team
– Real user (rarely)
– Product manager
– In...
How to create a story? Team effort
• Conduct a story writing workshop
– Time boxed
– Defer details
How to create a story? Roles and persona
How to create a story? Roles and persona
• For each action that the role can do draw a
line to a new box, label the box an...
How to create a story? Roles and persona
• Let’s try it!
How to create a story? Create prototypes
• low fidelity
• throw them away once the session is
completed
How to create a story? Design
How to create a story? Review
1. Start with defined roles and persona
2. Conduct a story writing workshop
3. Stories are a...
How to split a story? Start large, end with right size
• Start with broader
strokes and epics
• Split in smaller stories
c...
How to split a story? Compound story
Low Complexity
A lot of work
How to split a story? Cut the cake
How to split a story? Split on data boundaries
• First Name
• Last Name
• Address 1
• Address 2
• City
• State
• ZIP
Story...
How to split a story? Complex story
Research/design story
– short
– time boxed
Implementation story
- plan for another
ite...
How to split a story? Split on priority
High priority parts go
up in the backlog
Low priority parts get in
separate stories
When to split a story?
Release planning some
Iteration planning most
End of iteration some
How to create a story? Defer detail
• 508 Compliance
• Issues?
How to create a story? Defer detail
• As a participant with disabilities I can use the
document management system, so that...
How to create a story? Defer detail
• As a participant I can use a text equivalent for
every non-text element on the scree...
How to create a story? Defer detail
• As a participant I can use a text equivalent for
every toolbar icons on the screen s...
How and When to split a story? Review
1. Split and conquer!
2. Cut in slices
3. Split before an iteration to get the size ...
Story Smells
Story Smells Stories are too small
Symptom: A frequent need to revise estimates
Small stories may be implementation order
...
Story Smells Goldplating
Symptom: Developers adding
features/enhancements that are not planned
for the iteration
• Seeking...
Story Smells Too much detail
Symptom: Writing stories takes more time
than talking stories
• Too much detail to early
• If...
Story Smells Thinking too far ahead
Symptoms:
• Stories are hard to fit on a card
• Need for using a software system rathe...
Story Smells Customer has trouble prioritizing
• Prioritizing is difficult
• Consider reviewing the size
• Lack of biz val...
Story Smells Review
1. Sharpen your senses
2. If it is too hard too often it ain’t right
3. Address issues early
4. Good j...
Reading
Agile Tips - All about stories
Upcoming SlideShare
Loading in...5
×

Agile Tips - All about stories

2,976

Published on

This is a session I prepared for the R&D team at Global 360.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,976
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
9
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Stories are a reminder of a conversation
    Stories (and requirements) are rarely complete description (only fantastic stories and perfect requirements do that)
    Safe time to document quickly changing facts
    Quick feedback
    Avoid conflicts

    Example “As an Administrator I want the system to constantly make sure it is healthy so that I don't have to worry about it”
  • Stories are a reminder of a conversation
    Stories (and requirements) are rarely complete description (only fantastic stories and perfect requirements do that)
    Safe time to document quickly changing facts
    Quick feedback
    Avoid conflicts

    Example “As an Administrator I want the system to constantly make sure it is healthy so that I don't have to worry about it”
  • Stories are a reminder of a conversation
    Stories (and requirements) are rarely complete description (only fantastic stories and perfect requirements do that)
    Safe time to document quickly changing facts
    Quick feedback
    Avoid conflicts

    Example “As an Administrator I want the system to constantly make sure it is healthy so that I don't have to worry about it”
  • Understandable by both users and developers
    Studies show that stories are easier to remember
    Short
    Concentrate on a specific business value proposition
  • Issues with this story:

    Fake user
    No clear business value
    Use of words that are of no value to the REAL user (think the participant persona)
  • Issues with this story:

    Fake user
    No clear business value
    Use of words that are of no value to the REAL user (think the participant persona)
  • Issues with this story:

    Fake user
    No clear business value
    Use of words that are of no value to the REAL user (think the participant persona)
  • User stories are the right size for planning – not too big, not too small, but just right

    To make that happen we constantly change stories:

    Stories are not static
    -Stories can be split

    Later we’ll talk about how to make that happen

    In agile resources do not change:
    Iteration duration is constant
    Number of team members does not change during the iteration
    Stories CHANGE
  • No need to write all stories to start coding (unlike traditional requirements)
    Takes little time to write them, change them and prioritize them
    Start with an epic and split in each iteration (getting there….)
  • Writing quickly dozen stories gives a time saving overview of what the project would or may include.
    Only the most valuable stories get dealt with in detail and get implemented.

    Keep in mind when communicating with the design team

  • Be aware when discussing the stories at different stages of the development process

    Release planning – no details (only enough for a rough estimate)
    Iteration planning – increasing detail (enough to create tasks, acceptance criteria and estimates)
    Iteration – maximum detail (deep dive)


    Feel free to raise the flag! Use timer to timebox discussions.
  • Bringing out tacit knowledge –
    With tacit knowledge, people are not often aware of the knowledge they possess or how it can be valuable to others.
    Effective transfer of tacit knowledge generally requires extensive personal contact and trust.
    Tacit knowledge is not easily shared.
    Tacit knowledge consists often of habits and culture that we do not recognize in ourselves.
    Tacit knowledge refers to a knowledge which is only known by an individual and that is difficult to communicate to the rest of an organization.
    Knowledge that is easy to communicate is called explicit knowledge.
    Tacit knowledge has been described as “know-how” -- as opposed to “know-what” (facts), “know-why” (science), or “know-who” (networking).
    It involves learning and skill but not in a way that can be written down.

  • Be aware when discussing the stories at different stages of the development process

    Release planning – no details (only enough for a rough estimate)
    Iteration planning – increasing detail (enough to create tasks, acceptance criteria and estimates)
    Iteration – maximum detail (deep dive)


    Feel free to raise the flag! Use timer to timebox discussions.
  • Stick to a common format, helps capture value and makes reading even easier

    Ask audience how would they split this is taks

    Look at this story from different point of views
    Police department
    Bucket manufacturer
    Candy manufacturer
    Costume manufacturer
    Parent
  • Stick to a common format, helps capture value and makes reading even easier

    Ask audience how would they split this is tasks

    Look at this story from different point of views
    Police department
    Bucket manufacturer
    Candy manufacturer
    Costume manufacturer
    Parent
  • Stick to a common format, helps capture value and makes reading even easier

    Ask audience how would they split this is taks

    Look at this story from different point of views
    Police department
    Bucket manufacturer
    Candy manufacturer
    Costume manufacturer
    Parent
  • If it is too long to fit a piece of paper it is probably too long. (Ask for suggestions on how do we address this in Rally?)
  • Not final and not a contract
    Most of it is not documented
    There is no “most recent version”
    Avoid numbering – issue with our stories
    http://hotspot/Development/Product%20Teams/Empower/Documents/Version%201.0/Product%20Requirements/Product%20Requirements.EmpowerDocumentManagement%20Release%201.0.xlsx



  • No value, no priority, cannot change once it is written, no persona or role!

    Example: http://www.access-board.gov/sec508/guide/1194.22.htm
  • Twist to “as a retired man in his 60s…..”
  • All stake holders should understand it:
    User
    Product owner
    Developer
    Tester
  • All stake holders should understand it:
    User
    Product owner
    Developer
    Tester
  • All stake holders should understand it:
    User
    Product owner
    Developer
    Tester
  • Show Tommy’s Builder use case and scenarios document



    The content of the story card + acceptance tests = use case

    They differ by the level of completeness.
  • Show Tommy’s Builder use case and scenarios document



  • also known as interaction design scenarios

    It is even bigger that a use case very complete description of the interactions. Includes several use cases.


    Example the builder design documents
    http://hotspot/Development/Product%20Teams/Empower/Documents/Version%201.0/Product%20Design/DM_userscenario2.pdfhttp://hotspot/Development/Product%20Teams/Empower/Documents/Version%201.0/Product%20Design/DM_userscenario.pdf

  • Includes :

    a setting
    Multiple actors
    Goals and objectives
    Actions and events – plot
    Contains many possible stories



  • All stake holders should understand it:
    User
    Product owner
    Developer
    Tester
  • All stake holders should understand it:
    User
    Product owner
    Developer
    Tester
  • Customer Team
    Ideally there would be one person to write stories, prioritize work and answer questions, but...
    Can be made of testers, technical writers, product manager, real users, interaction designers
    This team prioritizes work for developers and answers questions
  • Point out that this is “As is…”
  • Add a chart with some stories based on the previous
  • Add a chart with some stories based on the previous
  • Show real docs
  • Show real docs
  • Avoid splitting on actions. The story should be feature complete no dependency on other stories
  • Avoid splitting on actions. The story should be feature complete no dependency on other stories
  • Complex story
    Split in investigation(spike) and implementation story
    Spikes need a timebox
    New features can be split in Design/Research and implementation story
    Research may be difficult to estimate
    Consider putting the spike or the research in a different iteration. Make estimate only for the spike/research stories and leave the implementation story estimate for later
  • Avoid splitting on actions. The story should be feature complete no dependency on other stories
  • Split incomplete stories at the end of the iteration
    If story is unfinished at the end of approaching the end of the iteration, either split or move to the next iteration
  • Who? Builder/Admin/Participant?
    What parts of the standard?
    (a) Text Tags (b) Multimedia Presentations (c) Color (d) Readability (e) Server-Side Image Maps (f) Client-Side Image Maps (g)&(h) Data Table (i) Frames (j) Flicker Rate (k) Text-Only Alternative (l) Scripts (m) Applets and Plug-Ins (n) Electronic Forms (o) Navigation Links (p) Time Delays  
  • Who? Builder/Admin/Participant?
    What parts of the standard?
    (a) Text Tags (b) Multimedia Presentations (c) Color (d) Readability (e) Server-Side Image Maps (f) Client-Side Image Maps (g)&(h) Data Table (i) Frames (j) Flicker Rate (k) Text-Only Alternative (l) Scripts (m) Applets and Plug-Ins (n) Electronic Forms (o) Navigation Links (p) Time Delays  
  • Who? Builder/Admin/Participant?
    What parts of the standard?
    (a) Text Tags (b) Multimedia Presentations (c) Color (d) Readability (e) Server-Side Image Maps (f) Client-Side Image Maps (g)&(h) Data Table (i) Frames (j) Flicker Rate (k) Text-Only Alternative (l) Scripts (m) Applets and Plug-Ins (n) Electronic Forms (o) Navigation Links (p) Time Delays  
    http://www.access-board.gov/sec508/guide/1194.22.htm
  • Who? Builder/Admin/Participant?
    What parts of the standard?
    (a) Text Tags (b) Multimedia Presentations (c) Color (d) Readability (e) Server-Side Image Maps (f) Client-Side Image Maps (g)&(h) Data Table (i) Frames (j) Flicker Rate (k) Text-Only Alternative (l) Scripts (m) Applets and Plug-Ins (n) Electronic Forms (o) Navigation Links (p) Time Delays  
    http://www.access-board.gov/sec508/guide/1194.22.htm
  • Split incomplete stories at the end of the iteration
    If story is unfinished at the end of approaching the end of the iteration, either split or move to the next iteration
  • Agile Tips - All about stories

    1. 1. Agenda  Why stories?  What stories are?  What stories are not?  How to create a story?  How to split a story?  When to split a story?  Story smells
    2. 2. Why stories? Verbal communication
    3. 3. Why stories? Verbal communication As an Administrator I want the system to constantly make sure it is healthy so that I don't have to worry about it
    4. 4. Why stories? Verbal communication As an Administrator I can use a watchdog service so that I know when the system stopped working
    5. 5. Why stories? Comprehensible
    6. 6. Why stories? Comprehensible As a Developer I want a standard exception class and conventions for use throughout all the server source code so that I don't have to reinvent the wheel
    7. 7. Why stories? Comprehensible As a participant I want to know what to do in the event of an application malfunction So that I can continue working
    8. 8. Why stories? Comprehensible As a participant I want to know what to do in the event of an application malfunction so that I can continue working As a Developer I want a standard exception class and conventions for use throughout all the server source code so that I don't have to reinvent the wheel
    9. 9. Why stories? Right size for planning
    10. 10. Why stories? Great for Iterative development
    11. 11. Why stories? Defer detail
    12. 12. Why stories? Defer detail Release planning – no details Iteration planning – increasing detail Iteration – maximum detail
    13. 13. Why stories? Tacit knowledge
    14. 14. Why stories? Review 1. Do talk stories, don’t write novels 2. Write for dummies 3. Change stories as you need 4. Enough detail to move along
    15. 15. What stories are?
    16. 16. What stories are? A reminder to talk A phrase or two that act as a reminder to hold the conversation
    17. 17. What stories are? A reminder to talk Notes about issues resolved during the conversation
    18. 18. What stories are? Common format As a …. Kid I want …. to carry my bucket in the neighborhood So that …. I can get lots of candies
    19. 19. What stories are? Front side Halloween fun As a Kid I want to carry my bucket in the neighborhood So that I can get lots of candies Customer: Lafayette Police Department
    20. 20. What stories are? Flip side/Acceptance • Put all crooks in jail • Have at least 10 patrol cars on the streets • Write a safety brochure • Distribute the safety brochure • Make sure officers’ kids have enough candy
    21. 21. What stories are? Review 1. Reminder of a conversation 2. Try, make a mistake, and try again 3. If it’s bigger than a (large) PostIt its too big 4. Where’s the real Value, Value, Value
    22. 22. What stories are not? requirements
    23. 23. What stories are not? requirements 1. The product shall have gasoline engine 2. The product shall have four wheels a) The product shall have rubber tire for each wheel 3. The product shall have steering wheel 4. The product shall have steel body WHAT IS THE PRODUCT?
    24. 24. What stories are not? requirements SPEED GRASS MOWER
    25. 25. What stories are not? requirements As a busy dad I can mow the lawn easy and quickly so that I have more time for my family
    26. 26. What stories are not? too specialized As a Builder I want each solution to contain an archetype for folders in that solution so that I can provide users with built-in foldering services
    27. 27. What stories are not? too specialized As a doc-check I want to be able to process New York three times faster so that I can meet TPC
    28. 28. What stories are not? use cases Use Cases Stories Number of players Multiple single Alternate routes yes no Scope Large Large/Epic and Small Longevity Permanent Changing Paper trail Extensively documented Short note discarded after completed
    29. 29. What stories are not? use cases Example: Builder use cases
    30. 30. What stories are not? Interaction design scenarios Heroflows Stories Number of actors One or more single Level of details Deep Enough to estimate Scope Multiple stories Single story Longevity Permanent Changing Paper trail Extensively documented Short note discarded after completed
    31. 31. What stories are not? Interaction design scenarios Example: Creating a new library & content type
    32. 32. What stories are not? Review Interaction design scenario Use Case Complete description of Story & Acceptance Criteria Story : As a participant… Acceptance : • . . . • . . . • . . .
    33. 33. What stories are not? Review 1. A story is a tool to capture requirements on the move, not the requirement itself 2. Use cases and heroflows are not stories, but can be a good source for stories 3. All players should understand the story
    34. 34. How to create a story? The perfect story Negotiable Valuable to Purchasers and Users Estimable Small Testable
    35. 35. How to create a story? Team effort • Create a Product Owner (or Customer) Team – Real user (rarely) – Product manager – Interaction designer – Behavioral designer or non technical specialist – ------------------------------------- – Sales engineer – Support engineer – Developer – Tester
    36. 36. How to create a story? Team effort • Conduct a story writing workshop – Time boxed – Defer details
    37. 37. How to create a story? Roles and persona
    38. 38. How to create a story? Roles and persona • For each action that the role can do draw a line to a new box, label the box and write a story Create Folder Create Content Type Configure Storage
    39. 39. How to create a story? Roles and persona • Let’s try it!
    40. 40. How to create a story? Create prototypes • low fidelity • throw them away once the session is completed
    41. 41. How to create a story? Design
    42. 42. How to create a story? Review 1. Start with defined roles and persona 2. Conduct a story writing workshop 3. Stories are a team effort 4. Early prototypes are communication tool, not a design artifact
    43. 43. How to split a story? Start large, end with right size • Start with broader strokes and epics • Split in smaller stories close to release and iteration
    44. 44. How to split a story? Compound story Low Complexity A lot of work
    45. 45. How to split a story? Cut the cake
    46. 46. How to split a story? Split on data boundaries • First Name • Last Name • Address 1 • Address 2 • City • State • ZIP Story A Story B Story A
    47. 47. How to split a story? Complex story Research/design story – short – time boxed Implementation story - plan for another iteration
    48. 48. How to split a story? Split on priority High priority parts go up in the backlog Low priority parts get in separate stories
    49. 49. When to split a story? Release planning some Iteration planning most End of iteration some
    50. 50. How to create a story? Defer detail • 508 Compliance • Issues?
    51. 51. How to create a story? Defer detail • As a participant with disabilities I can use the document management system, so that my disability does not affect my productivity
    52. 52. How to create a story? Defer detail • As a participant I can use a text equivalent for every non-text element on the screen so that if I am vision impaired, I can work with the system
    53. 53. How to create a story? Defer detail • As a participant I can use a text equivalent for every toolbar icons on the screen so that if I am vision impaired, I can work with the system • As a participant I can use a text equivalent for every dialog box buttons on the screen so that if I am vision impaired, I can work with the system
    54. 54. How and When to split a story? Review 1. Split and conquer! 2. Cut in slices 3. Split before an iteration to get the size right 4. Split at the end of an iteration to declare the iteration complete
    55. 55. Story Smells
    56. 56. Story Smells Stories are too small Symptom: A frequent need to revise estimates Small stories may be implementation order dependent
    57. 57. Story Smells Goldplating Symptom: Developers adding features/enhancements that are not planned for the iteration • Seeking the Wow factor • Pet features
    58. 58. Story Smells Too much detail Symptom: Writing stories takes more time than talking stories • Too much detail to early • If it cannot fit on an index card it is too long • Hard to estimate
    59. 59. Story Smells Thinking too far ahead Symptoms: • Stories are hard to fit on a card • Need for using a software system rather than cards • Common among teams accustomed to large up front "requirements" engineering efforts • Suggesting the use of template user story docs • Reminder what stories are, and recognition that it is impossible to have all requirements and details
    60. 60. Story Smells Customer has trouble prioritizing • Prioritizing is difficult • Consider reviewing the size • Lack of biz value • Too technical, the owner does not get it • Let the customer write the stories, be part of it
    61. 61. Story Smells Review 1. Sharpen your senses 2. If it is too hard too often it ain’t right 3. Address issues early 4. Good judgment comes from experience, and experience comes from bad judgment
    62. 62. Reading
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×