Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

IIT Academy: 204 User stories and acceptance criteria

1,177 views

Published on

IIT Academy: Agile. Learn how to articulate customer expectations and build precisely what was intended, with the minimum of traceability issues. Acceptance Criteria (in conjunction with good agile practices) is a way to create well documented, high-quality codebase tested using the same set of standards by developers, testers, analysts, designers as well as the Product Owner. Learn good Acceptance Criteria - the keys to customer success in agile delivery!

Published in: Leadership & Management

IIT Academy: 204 User stories and acceptance criteria

  1. 1. User Stories 205 IIT ACADEMY User Stories and Acceptance Criteria Industrie IT
  2. 2. contents • user stories - what/why/how • exercise • acceptance criteria - what/why/how • exercise SCALING 204 IIT ACADEMY
  3. 3. user stories what?
  4. 4. define Stories are a: • User’s need • Product description • Planning item • Token for a conversation • Mechanism for deferring conversation SCALING 204 IIT ACADEMY *"Kent Beck coined the term user stories in Extreme Programming Explained 1st Edition, 1999
  5. 5. a format 
 As a [user], I want [functionality] so that I can [benefit] SCALING 204 IIT ACADEMY
  6. 6. user stories why?
  7. 7. advantages • Easy-to-write • Easy-to-understand • User-centric • Easily understood by customer and technical • End-to-end functionality • Facilitates conversations • Can be sized • Is goal-centric (abstracts out detail) SCALING 204 IIT ACADEMY
  8. 8. WORKSHOPS usage • basic unit of functionality • gain detail over time • adds value to the product • vertical slice through the product • summarised as: • “As a <type of user> I want <some goal>
 so that <some reason>” • has acceptance criteria • can be used to capture non-functional requirements • can be a spike • may include wireframes, solution details etc. SCALING 204 IIT ACADEMY ACCEPTANCE CRITERIA FLOWS – SCREEN, DATA, LOGIC, ET AL. ARCHITECTURE – DATA, INFRA, ET AL. WIREFRAMES USER STORY UX ARCH DEV OPS RELEASE are “boundary objects”
  9. 9. boundary objects SCALING 204 IIT ACADEMY “A boundary object is a concept in sociology to describe information used in different ways by different communities. They are plastic, interpreted differently across communities but with enough immutable content to maintain integrity” --Wikipedia “They are weakly structured in common use, and become strongly structured in individual-site use. They may be abstract or concrete. They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable means of translation. The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds.” -- Leigh & Griesemer
  10. 10. user stories how?
  11. 11. Eight keys to good user stories SCALING 204 IIT ACADEMY 1. Focus on the user 2. Facilitate a conversation 3. Story writing is teamwork 4. Simple and concise 5. Decompose stories 6. Use acceptance criteria 7. User stories aren’t everything 8. Design vertical slices
  12. 12. 1 Focus on the user Use an actual role, not the word “user”. e.g. Marketing Admin, Broker, End customer, Head Office User. SCALING 204 IIT ACADEMY
  13. 13. 2 Facilitate a Conversation A story is not a specification. It is not a contract. It does not replace dialogue. It captures the essence of the conversation into the essential elements. SCALING 204 IIT ACADEMY
  14. 14. 3 Story Writing is Teamwork! Change is the only constant. Rely on the wisdom and expertise of the group to contribute perspectives, up-to-date information, expertise. Three pillars • Visibility/Transparency • Inspection • Adaptation SCALING 204 IIT ACADEMY
  15. 15. 4 Simple and Concise As  a  user,  I  want  to  sign  in  and  connect  the  database   to  the  mail  API  and  view  the  email  screen,  so  that  I   can  view  all  the  emails  that  belong  to  me.   Exercise  –  1  minute.  Come  up  with  a  better  one. SCALING 204 IIT ACADEMY
  16. 16. SCALING 204 IIT ACADEMY Example  of  a  concise  and  simple  user  story:   • JIRA  Name  =  “Email:  View”   • User  Story:  “As  an  authenticated  user,  I  want  to  view  my  emails.”   • Followed  by  detailed  acceptance  criteria 4 Simple and Concise
  17. 17. Recap - first four keys SCALING 204 IIT ACADEMY 1. Focus on the user 2. Facilitate a conversation 3. Story writing is teamwork 4. Simple and concise
  18. 18. 5 Decompose Stories Start with goals – can be as big as “do marketing”. Break down into large stories 13-100 points. Contains user- centric benefits. Break large stories into small stories 1-8 points. Contains incremental benefits. SCALING 204 IIT ACADEMY
  19. 19. 6 Use Acceptance Criteria Acceptance Criteria ensure testability. More on this later. E.g. Scenario 1: Account balance is negative Given the account’s balance is below 0 And there is not a scheduled direct deposit that day When the account owner attempts to withdraw money Then the bank will deny it And send the account owner a nasty letter. SCALING 204 IIT ACADEMY
  20. 20. 7 User Stories aren’t everything Some things aren’t user stories, but should be included. e.g. mockups, screenshots, seed data, relevant code snippets Some things definitely are user stories: Non-functional requirements should always be able to be expressed as user stories and/or acceptance criteria. E.g. As a broker, I want all buttons to respond to clicks in less than two seconds. Acceptance Criteria: Measure time between clicks and responses 200 users active on website, no other functions performed at the same time. SCALING 204 IIT ACADEMY
  21. 21. 8 Design Vertical Slices A story contains everything that it needs to in order to deliver the benefit. It delivers the minimum viable product as soon as possible. SCALING 204 IIT ACADEMY
  22. 22. Recap - last four keys SCALING 204 IIT ACADEMY 5. Decompose stories 6. Use acceptance criteria 7. User stories aren’t everything 8. Design vertical slices
  23. 23. user stories exercise
  24. 24. SCALING 204 IIT ACADEMY Exercise: Restaurant App Exercise: Write user stories for “A mobile app that helps hungry diners find an appropriate place to eat” Directions: Break into teams of 3-4 and discuss some of the stories. Aim to create a vertical slice. Directions: Arrange the subsequent stories into a user experience order; and present them to the group.
  25. 25. acceptance criteria what
  26. 26. Acceptance Criteria Recap A pass/fail set of criteria that the user story must meet in order to be considered done. 
 “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” - Microsoft 
 “Pre-established standards or requirements a product or project must meet.” - Google SCALING 204 IIT ACADEMY
  27. 27. acceptance criteria why?
  28. 28. Why Acceptance Criteria? Good Acceptance Criteria will help get your Agile project from “It Works as Coded” to “It Works as Intended.” • Once work is complete, clients have no problem defining what’s wrong. • Acceptance Criteria is about clear communication about intentions. • Inaccurate or missing acceptance criteria can lead to low customer satisfaction levels, missed delivery dates, and development cost overruns. This is why it’s so critical to accurately define them before any work begins. SCALING 204 IIT ACADEMY
  29. 29. What was
 intended What was
 coded What was tested Because the usual documentation processes produce this:
  30. 30. documentation debt,
 source of defects, wasted development effort Because the usual documentation processes produce this: What was
 intended What was
 coded What was tested
  31. 31. over-documentation,
 missed requirements, source of scope creep Because the usual documentation processes produce this: What was
 intended What was
 coded What was tested
  32. 32. wasted
 testing
 effort Because the usual documentation processes produce this: What was
 intended What was
 coded What was tested
  33. 33. Because the usual documentation processes produce this: What was
 intended What was
 coded What was tested documented, tested, purposeful code
  34. 34. documentation documentation code Development Sprint Planning Smoke Testing Test Validation Acceptance Testing Acceptance Criteria/
 Test Approach Product Management Portfolio
 Management Usage Executive Stakeholders + End Users Product Owners + Product Stakeholders Developers Functional Testing Product Owners Scrum Team Business Cases (Backlog Epics) Backlog + Wiki Structure Sprint Backlog +
 Wiki User Stories User Story:
 Testing Sections User Story:
 Technical Sections User Story:
 Delivery Decision Log User Story > JIRA link:
 Known Bugs/Issues Update Sprint User Stories >
 System Documentation System Documentation: User Guides Requests for changes, new scope, etc. code documentation supports code
  35. 35. intention = code = test federate intentions with what is both coded and tested
  36. 36. Development Sprint Planning (detailed US + some AC) Smoke Testing
 (against AC) Test Validation
 (validate AC) Acceptance Testing (against AC) Acceptance Criteria Product Management (high level US) Portfolio
 Management Usage Executive Stakeholders + End Users Product Owners + Product Stakeholders Developers Functional Testing (against AC) Product Owners Scrum Team Business Cases (Backlog Epics) Backlog + Wiki Structure Sprint Backlog +
 Wiki User Stories User Story:
 Testing Sections User Story:
 Technical Sections User Story:
 Delivery Decision Log User Story > JIRA link:
 Known Bugs/Issues Update Sprint User Stories >
 System Documentation System Documentation: User Guides Requests for changes, new scope, etc. USER WIPWIP WIP USER ACEPT W/FUX ARCH code code + user stories + acceptance criteria support working, tested software
  37. 37. acceptance criteria how?
  38. 38. Five Characteristics of good acceptance criteria 1. Each statement is pass/fail. 2. Bounds the story from customer perspective 3. Actionable 4. High level: does not re-hash requirements 5. State intent, but not dictate the solution SCALING 204 IIT ACADEMY
  39. 39. 1. Pass/Fail Each statement is pass/fail result. No “partial acceptance” SCALING 204 IIT ACADEMY
  40. 40. 2. Bounds from Customer perspective Defines expectations
 Clearly bounds the story in customer language SCALING 204 IIT ACADEMY
  41. 41. 3. Actionable SCALING 204 IIT ACADEMY Can be translated into one or more actionable test cases
  42. 42. 4. High Level Does not re-hash requirements of story • Contains functional requirements
 (e.g. minimum viable product) • Contains non-functional requirements
 (e.g. minimal quality) SCALING 204 IIT ACADEMY
  43. 43. 5. State intent, not solution The criteria is independent of implementation. “A manager can approve or disapprove an audit form”
 vs.
 “A manager can click an ‘Approve/ Disapprove’ radio button to approve an audit form” SCALING 204 IIT ACADEMY
  44. 44. example of usage The user story is presented, and the conversation starts. For example: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork Questions for the Product Owner might include: • What information needs to be collected to allow a user to register? • Where does this information need to be collected/delivered? • Can the user pay online as part of the registration process? • Does the user need to be sent an acknowledgment? The issues and ideas raised in this Q and A session are captured in the story’s acceptance criteria. SCALING 204 IIT ACADEMY
  45. 45. Acceptance Criteria 1. A user cannot submit a form without completing all the mandatory fields 
 2. Information from the form is stored in the registrations database 
 3. Protection against spam is working 
 4. Payment can be made via credit card 
 5. An acknowledgment email is sent to the user after submitting the form. 
 When the development team has finished working on the user story they demonstrate the functionality to the Product Owner, showing how each criterion is satisfied. SCALING 204 IIT ACADEMY
  46. 46. acceptance criteria exercise
  47. 47. "As a web master, I can configure widget B to display in one of the three primary colors of blue, red, and yellow" SCALING 204 IIT ACADEMY
  48. 48. example answer A set of acceptance tests would be: • The web master has access to the configuration options for widget B • The web master has a selection list available of the three primary colors of blue, red and yellow • When the web master sets widget B to blue, it displays in blue • When the web master sets widget B to red, it displays in red • When the web master sets widget B to yellow, it displays in yellow • The web master has no other options other than blue, red or yellow SCALING 204 IIT ACADEMY
  49. 49. Additional User Stories If, in writing the AC, we discover that we need to ensure no-one else can access the same options, we can add a new story to say: "As a web user, I do not have access to widget B's configuration options" And then write appropriate acceptance criteria for that. SCALING 204 IIT ACADEMY

×