Getting Your Story Straight

1
Getting Your Story Straight Andy Pols Rachel
Davies
2
Timetable

• Presentation 20 mins
• Questions 10 mins
• Story Writing Exercise 30 mins
• Write stories in groups
• Swap stories for marking
• Review 30 mins

3
Why use stories?

• We cannot complete analysis without feedback
• Documents can be ambiguous
• Updating documents to reflect changes takes time
• Face-to-face communication is richer
• Features that add value rather than requirements

4
3Cs - The components of a story

• Card story text on an index card
• Conversation with customer and developers
• Confirmation acceptance tests
• Ron Jeffries
• Remember index cards represent requirements in
  the plan rather than documenting them

5
The Card

• A story needs a name
• do not use a reference number!
• A story may have a short prose or graphical
  description
• You may find this format useful but it is
  optional
• As ltrolegt I want ltfunctiongt so that ltbusiness
  valuegt

6
Sample Story Card

• Find Lowest Fare
• Present the ten lowest fares for a particular
  route.

7
Sample Story Card

• Sort Available Flights by Convenience
• Sort the flights by
• Duration
• Number of changes.
• Closeness to desired dept/arrival time
• Price

8
The Conversation

• The Customer ..
• is on-site available to talk to developers in
  place of documents
• prioritizes stories for incremental development
• evolves vision based on feedback from incremental
  deliveries of stories

9
The Confirmation

• Each story needs clear Acceptance Tests to
  prevent expanding scope during iteration
• Simple format
• When I do this action, I expect this result
• Acceptance tests should be built into an
  automated suite
• More detailed tests may need to be defined during
  iteration by specialised QA
• Remember the Customer may reject a story that
  does not pass the Acceptance Tests
• The Customer has the right to refine story
  details during development

10
Stories are by definition time-boxed

• Stories need to be of a size that you can build
  a few of them in an iteration
• Stories don't have to represent business value
  to the customer team, but they do have to
  represent progress. Only the customer team knows
  what it will consider progress, so they have to
  do the slicing
• Kent Beck

11
Ways to slice the cake

• Customers should talk with Developers to
  understand what parts can be implemented
  separately
• Thin slice thru all layers
• Fake out backend
• Screen by screen
• Field by field
• You may need some way of linking all the stories
  to a high level requirement or use case

12
Story Attributes

• The acronym "INVEST" can remind you that good
  stories are
• I - Independent
• N - Negotiable
• V - Valuable
• E - Estimable
• S - Small
• T Testable
• from XP Explored by Bill Wake

13
Questions?

• Any questions?

14
Exercise

• Split into triples
• Choose roles Customer, Developer, Tester
• Take worksheet a stack of index cards
• Split the worksheet example into stories
• Write Story on the front of an index card
• Write Acceptance tests on the back
• Teams swap stories for judging
• Using INVEST attributes for scoring
• Prize for the team with the most Stories!

15
References

• Extreme Programming Explained Beck
• Extreme Programming Explored - Wake
• Writing Effective Use Cases Cockburn
• User Stories Applied Cohn
• Requirements By Collaboration Gottesdiener
• Use Case Zone pages http//www.pols.co.uk/use-case
  -zone/index.html
• C2 wiki pages
• www.xp123.com