1. The document discusses user stories and how they can be used to summarize customer requirements for software development in a more effective way than traditional documentation methods. 2. User stories follow a simple template that focuses on the user and their goal, and are intended to spark conversations between customers and developers. Acceptance criteria are added later to determine completeness. 3. The document provides best practices for writing effective user stories, such as using a specific user type, focusing on value, and making stories independent, negotiable, valuable, estimatable, small, and testable. It also discusses techniques for splitting or combining stories.

1. 1

2. Picture: http://www.flickr.com/photos/psd/2423294079/sizes/l/in/photostream/
2

3. Acknowledgments:
Mike Cohn’s User stories applied and Agile Estimation and Planning.
Jeff Patton’s work on User Role Modeling.
3

4. 4

5. Mike Cohn: simple, clear, short description of customer valued functionality
3 parts: written description used for planning, conversation to flesh
out details, tests to determine completeness.
Ron Jefferies: 3Cs - Card, conversation, confirmation.
Rachel Davies: user story represents customer requirements rather than documents
them.
5

6. Template: As a type of user, I can achieve some goal so that I can gain some value.
Add a title, some notes, assumptions, constraints, priority, estimate.
6

7. Examples
7

8. On the back, we add acceptance criteria.
Use this template for acceptance tests: Given [context] And [some context] When
[event] Then [outcome] And [another outcome].
Or simpler version of verify or test.
8

9. Examples
9

10. Too much info. Running out of room?
10

11. Tom Poppendieck advises us to use smaller card.
User story covers the who, what and why? It does not cover how? That is where the
conversation comes in.
11

12. The main purpose of a story is to act as a reminder and encourage conversation to
flush out details the closer we are to implementing a story.
Business, PM, Developer, Tester
Picture :http://www.flickr.com/photos/improveit/1470706210/in/photostream
12

13. 13

14. 14

15. IEEE 830: The system shall…
1000 requirements in Excel, become 30 functional specs, each about 50 pages.
Hand it over to the developers and testers (1500 pages).
Process is tedious, error prone, time consuming, boring, hard to see the big picture,
hard to prioritize, not goal focused (task oriented).
Use cases do a better job at putting things in context, but are still too detailed to
adapt to changing customer need.
They are bigger, larger in scope, there is the main scenario and then the extensions,
pre/post conditions.
They act more as an agreement between customer and developer rather than a
forum for conversation.
15

16. User stories directly support the Agile manifesto:
User stories support focusing on working software over comprehensive
documentation.
Conversation supports individuals and interactions and customer collaboration.
Brevity and high level of user story supports responding to change.
16

17. Emphasize verbal rather than written communication.
Encourage conversation, face to face discussions as opposed to document handoffs.
17

18. Encourage deferring details until you have better understanding about what you
really need.
Avoids unnecessary detailed planning which might change by the time we reach
development time.
18

19. Provide right size for planning.
High level, focus on value and can be prioritized.
19

20. Comprehensible by customers and developers.
Picture: http://www.flickr.com/photos/90001203@N00/172506278/
20

21. Works for iterative development.
Start at high level and flush out details with each iteration and repeat.
21

22. 22

23. 1. Use human user. Write story from user’s perspective and understand his goal and
value for the story.
2. Avoid using generic as a user or as a customer. Think of role as group of users that
share common characteristics and based on those characteristics their
interactions with system will be different. Think penny pinching college student,
busy corporate lawyer, or juggling mother of 3. Try to profile roles and figure out
how often will they use the system, how much domain knowledge do they have,
are they technically savvy, what is their goal? Pain points?
3. Use extreme users. Extreme users are not really target audience, but simply
bringing them up can produce different context and lead to interesting discussion.
For example, think of the Pope. Or think of a hacker.
As a hacker, I can access customer’s payment information to pay for my vacation.
Picture: http://www.flickr.com/photos/12426416@N00/163959411
23

24. More examples
24

25. More examples
25

26. 26

27. Bill Wake - Invest acronym: Independent, negotiable, valuable, estimatable, small,
and testable.
Picture: http://www.flickr.com/photos/42179515@N06/3937449949
27

28. Independent: try to make sure that stories are not interdependent as this might lead
to prioritization and planning problems.
Independent is different from logical order of developing things. By independent, we
mean story features. For example, in earlier credit card example, we wanted to
support amex, mc and visa. If there are 2 stories, one for mc and another for visa,
then estimates will depend on which one gets done 1st because implementing the 2nd
will be relatively straight forward.
Options are to combine the stories, or split in a different way (discussed later).
If for some reason dependency cannot be removed, then provide 2 estimates on each
story, one for each order combination.
28

29. Negotiable:
Brief and not a detailed contract.
Encourage conversation and negotiation between customer and developers.
Picture: http://www.flickr.com/photos/23065375@N05/2235525962
29

30. Valuable:
Provide value to the customer or the user.
Start with goal stories and break it out from there.
Standish Group: 64% of features are never or rarely used in reality.
Ensure value is written. If customer cannot think of value, then they might see work
as unnecessary and eliminate it.
If value is clearly specified, team might find different ways to achieve same goal with
same value but with less effort.
Because story is delivering piece of functionality, customer can figure out how much
functionality costs and then decide if they still need it.
Not all value is monetary, mitigating risk is value.
As a [type of user] I want [some functionality] to avoid [some operational risk,
process weakness, ...]
30

31. Estimatable:
Developers need to estimate story.
Story needs to be written so developers can understand it and have idea of how to
implement it.
Reasons we can’t estimate are lack of domain knowledge, lack of technical
knowledge, or too big.
Picture: http://www.flickr.com/photos/21458229@N00/4553607341
31

32. Small: Not too big, not too small, but just right (1 story half the iteration length).
Provide focus and short horizon for the team. Its easier to get lost in the details with
larger story.
Easier to adapt and give flexibility to reconfigure and adapt to changes.
Large stories increase risk that team will deliver nothing at end of iteration.
Large stories can create blockages and bottlenecks. One person who is tied up in
large story may also be only person who can complete key piece of another story.
Picture: http://www.flickr.com/photos/24257141@N05/4747161154
32

33. Testable:
Need to verify that story is complete.
Make sure there is acceptance criteria.
Non-testable stories usually occur with non-functional requirements: Ease of use,
fast, bug free.
Try to re-write so that some metric can be measured and test can be written (ideally
automated). Example: Test that system responds in 1 second or less at least 95% of
the time.
Picture: http://www.flickr.com/photos/20897132@N00/208837407
33

34. 34

35. 35

36. Dependency
Story dependent on another story makes it hard to give correct estimate.
Split so one story handles dependency and other handle specifics.
Picture: http://www.flickr.com/photos/15923063@N00/4972049904
36

37. Size – Too big
a. Cannot give accurate estimate: Story needs to be more manageable and enable
more accurate estimate.
b. Cannot fit into iteration: If for example iteration is 1 week long and story is longer
than week then it needs to be split to fit into iteration.
c. Cannot fit into what’s remaining of iteration: Team has already committed to 38
story points and there is still room for 2 point story but remaining stories are 3
story points or more.
Picture: http://www.flickr.com/photos/87857621@N00/191311751
37

38. Risk:
If complex and risky, split to create spike story which is experimental in nature with
main goal to gain technical knowledge.
Picture: http://www.flickr.com/photos/95457978@N00/495352477
38

39. Story contains multiple sub stories that are large enough to stand out on their own.
39

40. Combine many small items onto one larger story.
Example: Bug reports can be combined into one “Fix Bugs” story.
40

41. 41

42. Slice Vertically: Stories should represent some level of end to end functionality. This
reduces overall risk and delivers value to customer.
Do simplest thing that could possibly work.
Important to not split stories into tasks like design, code front end, code middle tier,
code back end.
Better to deliver cohesive subset of all layers of feature than delivering all of one layer
as standalone.
Having entire backend ready without corresponding GUI is not very useful.
Having feature that allows user to add entity through GUI and have it persisted is
functionality that can be useful and provides some value.
42

43. Data Boundaries:
Separate local requirements from international requirement.
Handling one type of credit card from another.
Start with USD then add foreign currency.
Picture: http://www.flickr.com/photos/7762644@N04/2533281806
43

44. Operational boundaries:
CRUD boundaries.
Separating into search which returns search result count and then search display
which displays actual results.
Happy path 1st , exceptions next.
Picture: http://www.flickr.com/photos/7729940@N06/3076476665
44

45. Cross Cutting Concern:
Features that effect multiple aspects of the application like security, logging, error
handling can each be separated out of main functionality features.
Screen with different menu options based on the login user’s credentials.
Security specific feature can be split from main functionality of screen.
Picture: http://www.flickr.com/photos/53611153@N00/303892944
45

46. Performance constraints:
Split functional requirement from non functional requirements.
Example: Feature can be enabled without caching and then another story can handle
caching specifics.
Picture: http://www.flickr.com/photos/32165728@N00/183211819
46

47. Priority:
Multiple priorities within a story.
Login story might have different priorities for authentication than for handling error
conditions like locking out user after multiple logins.
Necessity: Minimum needed to get working software.
Flexibility: What are some alternative ways of doing it, what additional data we want
to capture.
Safety: Better validation rule to avoid ugly error messages.
Comfort, luxury, and performance: More usable, sexier to look at (animation), hot
keys.
1.Opening game: Skeleton spans system and contains necessary features
2. Mid game: Add capability, flexibility and safety
3. End game: Finish with usability, performance, sex appeal and reserve time for
unforeseen additions and adaptations
Picture: http://www.flickr.com/photos/15639842@N00/4182148160
47

48. 48

49. Contact me
49

50. 50