UW Agile CP202 - Class 1 User Stories

4,045 views

Published on

The 1st class of Spring Quarter Agile CP202 slides including:
* User Stories
* Acceptance Criteria
* INVEST Model
* Splitting User Stories
* Abuse Stories

Published in: Technology
2 Comments
9 Likes
Statistics
Notes
No Downloads
Views
Total views
4,045
On SlideShare
0
From Embeds
0
Number of Embeds
25
Actions
Shares
0
Downloads
173
Comments
2
Likes
9
Embeds 0
No embeds

No notes for slide

































  • UW Agile CP202 - Class 1 User Stories

    1. 1. University of Washington Agile Developer Certificate Spring Quarter Advanced Topics in Agile Software Development Class #1: User Stories, INVEST Model, Acceptance Criteria, and Abuse Stories
    2. 2. User Stories Story 14 As a customer I want to check my order status online so that I can know when to expect my package
    3. 3. User Stories Story 14 As a customer I want to check my order status online so that I can know when to expect my package A small piece of business value that can be delivered in an iteration
    4. 4. Why User Stories? • Agile Principle: – “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation” • User Stories are insufficient to implement without a conversation between the customer and delivery team • Describe vertical slices of functionality • Words need context to interpret; requirements are interpreted out of context in many cases
    5. 5. What is a User Story?* • CARD – Token representing the requirement. It's used in planning. Notes are written on it, reflecting priority and cost • CONVERSATION – The requirement itself is communicated from customer to programmers through conversation (The conversation is largely verbal, but is often supplemented with documents) • CONFIRMATION – The confirmation provided by the acceptance test is what makes possible the simple approach of card and conversation – When the conversation about a card gets down to the details of the acceptance test, the customer and programmer settle the final details of what needs to be * “Essential XP: Card, Conversation, Confirmation” – Ron Jeffries http://www.xprogramming.com/xpmag/EXPCardConversationConfirmation.htm
    6. 6. A User Story Template (CARD) • Describes the value of functionality from a user’s perspective User Story Template As a <<user role>> I want to <<do something>> so that <<value/benefit>> • User Role – a user of the product • Do Something – feature user needs
    7. 7. The INVEST Model I–N–V–E–S–T • I = Independent - dependencies reduce agility • N = egotiable - negotiation breeds N collaboration • V = Valuable - valuable to the Product Owner, client, customer and user • E = Estimable - stories are planning tools • S = Sized Appropriately - can be predictably completed and delivered • T = Testable - story (acceptance) tests define when we are “done” Source: adapted from Bill Wake, xp123.com (http://xp123.com/xplor/ xp0308/index.shtml)
    8. 8. Types of User Stories • Epic – a user story that has not been decomposed to meet INVEST model because it is lower priority • Theme – a collection of related user stories
    9. 9. Types of User Stories • Epic – a user story that has not been decomposed to meet INVEST model because it is lower priority • Theme – a collection of related user stories
    10. 10. Interconnections of a User User Story • Card • Conversation • Confirmation
    11. 11. Interconnections of a User User Story Value • Card • Conversation • Confirmation
    12. 12. Interconnections of a User User Story Value • Card • Conversation • Confirmation Incremental Delivery
    13. 13. Interconnections of a User User Story Value • Card • Conversation User Perspective • Confirmation And Focus Incremental Delivery
    14. 14. Interconnections of a User User Story Value • Card • Conversation User Perspective • Confirmation And Focus Incremental Delivery The Right Conversation
    15. 15. Interconnections of a User User Story Value • Card • Conversation User Perspective • Confirmation And Focus Domain Model, Incremental System Metaphor, Delivery Glossary of Terms The Right Conversation
    16. 16. Interconnections of a User User Story Value • Card • Conversation User Perspective • Confirmation And Focus Domain Model, Incremental System Metaphor, Delivery Glossary of Terms The Right Define Done Conversation
    17. 17. Interconnections of a User Estimates User Story Value • Card • Conversation User Perspective • Confirmation And Focus Domain Model, Incremental System Metaphor, Delivery Glossary of Terms The Right Define Done Conversation
    18. 18. Exercise: User Story Writing Write User Stories for the Jitter web application. ID 8.5
    19. 19. Acceptance Tests • Tell us whether the system does what the customer expects • Enable Developers to know they’ve satisfied requirements • Helps us build the “right” software • Are also called customer tests or functional tests • Can be automated so these can be verified by anyone at any time * Adapted from “A Metric Leading to Agility” – Ron Jeffries http://www.xprogramming.com/xpmag/jatRtsMetric.htm
    20. 20. Confirmation Through Acceptance Criteria • Product Owner makes first pass at Acceptance Criteria before Sprint Planning Meeting • During Sprint Planning, Acceptance Criteria are discussed • Final Acceptance Criteria for each User Story is a negotiation between Delivery Team and Product Owner • Should be short, easy to understand statements Acceptance Criteria Story 14 •View status as “waiting for As a customer, I want to check my pickup”, “en route” or order status online so that I can know “delivered” when to expect my package •Date of each step in route •Estimated time of delivery
    21. 21. Comparing Acceptance Criteria to Definition of Done Definition of Done: Helps us Acceptance Criteria: Helps us build the thing right build the right thing Acceptance Criteria •View status as “waiting for pickup”, “en route” or “delivered” •Date of each step in route •Estimated time of delivery
    22. 22. User Story “Smells” • Split along process lines – Design, code, test, document • Split across architecture lines – Database, Business Tier, UI • Split along procedural lines – Do this, then this, and finally this
    23. 23. *Requirement to User Story – A Case Study • Our starting requirement: Story 1 Anyone can register by paying immediately with PayPal * Modified from original article by J.R. Rainsberger - http://www.jbrains.info/weblog/browse/9
    24. 24. *Requirement to User Story – A Case Study • Maybe break it along process lines?: Story 1.1 Story 1.2 Design: Anyone can Code: Anyone can register register by paying by paying immediately immediately with PayPal with PayPal Story 1.3 Story 1.4 Unit Test: Anyone can Functional Test: Anyone register by paying can register by paying immediately with PayPal immediately with PayPal * Modified from original article by J.R. Rainsberger - http://www.jbrains.info/weblog/browse/9
    25. 25. *Requirement to User Story – A Case Study • Maybe break it along architecture lines?: 1.1 Story Story 1.2 UI: Anyone can register by Business Logic: Anyone paying immediately with can register by paying PayPal immediately with PayPal Story 1.3 Story 1.4 Database: Anyone can QA: Anyone can register register by paying by paying immediately immediately with PayPal with PayPal * Modified from original article by J.R. Rainsberger - http://www.jbrains.info/weblog/browse/9
    26. 26. *Requirement to User Story – A Case Study • Maybe break it along procedural lines?: Story 1.1 Story 1.2 Collect registration Integrate with PayPal information Story 1.3 Story 1.4 Email registrant after Email organizer after payment payment * Modified from original article by J.R. Rainsberger - http://www.jbrains.info/weblog/browse/9
    27. 27. *Requirement to User Story – A Case Study • Aha, self-contained increments of value… Story 1.1 Story 1.2 As a Registrant I want to As an Organizer I want to register with my email so collect more information that I can be notified from Registrant so that I electronically can contact them later Story 1.3 Story 1.4 As a Registrant I want to As an Organizer I want to be notified of my be notified of a processed registration so registration so that I can that I know it is complete fulfill it * Modified from original article by J.R. Rainsberger - http://www.jbrains.info/weblog/browse/9
    28. 28. More Guidelines for Splitting Stories • Data boundaries • Operational boundaries • Exceptions • Error handling • Removing cross-cutting concerns • Priority
    29. 29. Avoid splitting stories too • Don’t split stories too soon – Results in huge inventory on Product Backlog (waste) – Inertia sets in and clogs system – Many details will likely be thrown out, resulting in “sunk costs” • Progressively elaborate stories based on – Priority – Risk • Effectively splitting stories is a joint effort – Product Owner, Stakeholders
    30. 30. * Abuse User Stories Implement Security for User Information * From “User Stories Applied” presented by Mike Cohn Agile 2006 21
    31. 31. * Abuse User Stories Implement Security As a Malicious Hacker I for User Information want to steal credit card information so that I can make fraudulent charges * From “User Stories Applied” presented by Mike Cohn Agile 2006 21
    32. 32. Abuse Story Workshop • Agenda (30-60 minute workshop typically) – Goal: Generate and Prioritize Abuse Stories • Brainstorm Potential Abusers of Application or Identify Specific Abuser to Use During Session • Work in Pairs to Generate Abuse Stories; Each Pair takes on Single Abuser Persona at a Time • Share Generated Abuse Stories and Prioritize as Group

    ×