• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
UW Agile CP202 - Class 1 User Stories
 

UW Agile CP202 - Class 1 User Stories

on

  • 3,498 views

The 1st class of Spring Quarter Agile CP202 slides including:

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

Statistics

Views

Total Views
3,498
Views on SlideShare
3,478
Embed Views
20

Actions

Likes
7
Downloads
137
Comments
2

5 Embeds 20

http://www.slideshare.net 13
http://www.gettingagile.com 4
http://www.lmodules.com 1
http://www.linkedin.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

UW Agile CP202 - Class 1 User Stories UW Agile CP202 - Class 1 User Stories Presentation Transcript

  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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)
  • 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
  • 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
  • Interconnections of a User User Story • Card • Conversation • Confirmation
  • Interconnections of a User User Story Value • Card • Conversation • Confirmation
  • Interconnections of a User User Story Value • Card • Conversation • Confirmation Incremental Delivery
  • Interconnections of a User User Story Value • Card • Conversation User Perspective • Confirmation And Focus Incremental Delivery
  • Interconnections of a User User Story Value • Card • Conversation User Perspective • Confirmation And Focus Incremental Delivery The Right Conversation
  • 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
  • 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
  • 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
  • Exercise: User Story Writing Write User Stories for the Jitter web application. ID 8.5
  • 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
  • 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
  • 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
  • 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
  • *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
  • *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
  • *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
  • *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
  • *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
  • More Guidelines for Splitting Stories • Data boundaries • Operational boundaries • Exceptions • Error handling • Removing cross-cutting concerns • Priority
  • 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
  • * Abuse User Stories Implement Security for User Information * From “User Stories Applied” presented by Mike Cohn Agile 2006 21
  • * 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
  • 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