XP Stories

1
XP - Stories Rachel Davies, Agile Alliance
2
Analysis

• Analysis helps us to identify the full set of
  behaviours required of a system
• When we analyse prior to engagement of IT we risk
  expanding requirements without understanding the
  cost of our decisions
• If we want ROI then we need to identify both
  business value and cost of implementation for our
  requirements before construction

3
Minimum Marketable Features?

• Standish Report 2002

4
Embrace Change

• We model to Understand and Communicate but models
  are not enough
• We cannot expect to do complete analysis without
  feedback
• We cannot expect documents to speak for
  themselves without ambiguity
• Keeping documents updated to reflect changes is
  time-consuming
• Face-to-face communication is richer

5
On-site Customer

• XP uses the Customer as the source of knowledge
  for all system requirements
• An On-site Customer is used instead of
  documentation
• Story cards represent requirements in the plan
  rather than documenting them
• Customer vision evolves based on feedback from
  iterative deliveries

6
Agile Manifesto

• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
  
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• While there is value in the items on the right,
  we value the items on the left more

7
The role

• The On-site Customer needs to
• Gain approval from other stakeholders
• Communicate context, required outcomes and
  acceptance criteria
• Prioritise work based on business value
• Be available to answer questions during
  development
• Accept or reject delivered solutions

8
Stories - Time-boxed by definition

• One thing the customer wants the system to do.
  Stories should be estimable at between one to
  five ideal programming weeks. Stories should be
  testable.
• 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

9
More that words

• Ron Jeffries
• Card story text
• Conversation discuss the details
• Confirmation record acceptance tests

10
Story Format

• Sticking to a story format can help
• Title (not a reference number)
• Concise problem statement
• As I want so that value
• Any other relevant notes, sketches of screen
  layout, etc.

11
Slicing the cake

• There are many ways of slicing a large story
• Do this with developers, they 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 your high level requirement

12
Acceptance Tests

• To prevent developers expanding scope acceptance
  tests need to be clearly stated
• Simple format
• When I do this action, I expect this result
• The project should aim to build acceptance tests
  into a suite that can be automated
• More detailed tests may need to be defined during
  iteration
• You can work with specialised QA to improve your
  tests

13
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

14
Why index cards?

• You cannot fit much text onto an index card!
• Tactile qualities get everyone involved
• Influence..

15
Release Planning

• If the system/business domain are well understood
  then a Release Plan may be built
• High-level stories are written
• Rough estimates are applied
• Stories are prioritized
• By business value
• By risk
• The resulting release plan is updated based on
  delivered iteration change is expected

16
Iteration Planning

• Before the Iteration Planning Game
• Select candidate stories
• Developers cannot estimate stories without
  acceptance tests
• Understand that the team use measured Velocity
  (Yesterdays Weather) predict future delivery
• There may be stories that were not finished last
  iteration to be re-estimated

17
Pitfalls

• System requirements may be too large to be held
  in memory by the Customer
• Customer does not have enough time
• Customer is not in the same building
• Customer blind-spots missing tests
• Losing parts of big stories
• Customer team, many voices
• Customer sitting with Developers may
• lose touch with business

18
Scaling up

• Scaling up is possible but may cause slow down as
  other problems are introduced
• Multiple customer teams where customers own
  different functional areas
• Risk increased communication overhead
• Gaps in ownership
• Story repositories and documents
• Risk duplication

19
Questions?

• Any questions?

20
Exercise

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

21
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