The Codex of Business Writing Software for Real-World Solutions 2.pptx
Agenda for Creating and Splitting User Stories
1.
2. 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
4. 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
5. Why stories? Verbal communication
As an Administrator
I can use a watchdog service
so that I know when the system stopped working
7. 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
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
9. 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
17. What stories are? A reminder to talk
A phrase or two that act as a reminder to hold
the conversation
18. What stories are? A reminder to talk
Notes about issues resolved during the
conversation
19. 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
20. 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
21. 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
22. 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
24. 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?
26. 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
27. 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
28. 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
29. 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
31. 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
32. What stories are not? Interaction design scenarios
Example: Creating a new library & content type
33. What stories are not? Review
Interaction design
scenario
Use Case
Complete description of
Story & Acceptance
Criteria
Story :
As a participant…
Acceptance :
• . . .
• . . .
• . . .
34. 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
35. How to create a story? The perfect story
Negotiable
Valuable to Purchasers and Users
Estimable
Small
Testable
36. 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
37. How to create a story? Team effort
• Conduct a story writing workshop
– Time boxed
– Defer details
39. 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
40. How to create a story? Roles and persona
• Let’s try it!
41. How to create a story? Create prototypes
• low fidelity
• throw them away once the session is
completed
43. 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
44. 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
45. How to split a story? Compound story
Low Complexity
A lot of work
47. 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
48. How to split a story? Complex story
Research/design story
– short
– time boxed
Implementation story
- plan for another
iteration
49. How to split a story? Split on priority
High priority parts go
up in the backlog
Low priority parts get in
separate stories
50. When to split a story?
Release planning some
Iteration planning most
End of iteration some
51. How to create a story? Defer detail
• 508 Compliance
• Issues?
52. 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
53. 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
54. 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
55. 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
57. Story Smells Stories are too small
Symptom: A frequent need to revise estimates
Small stories may be implementation order
dependent
58. Story Smells Goldplating
Symptom: Developers adding
features/enhancements that are not planned
for the iteration
• Seeking the Wow factor
• Pet features
59. 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
60. 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
61. 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
62. 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
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