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.

Agile requirements management

13,166 views

Published on

Agile requirements management End-to-End: from project goals to automated acceptance tests

Agile requirements management

  1. 1. CHRISTIAN HASSA CH@TECHTALK.AT @CHR99HA ALM Summit Vienna, 30th of November 2012 Agile requirements management End-to-End: from project goals to automated acceptance tests
  2. 2. TechTalk at a glance • Agile software development • Consulting and Delivery (Nearshoring) • Locations: Zürich, Vienna, Budapest • ~50 TechTalkers • Founded: 1993 TechTalk office, Vienna/Austria
  3. 3. 3 How do we specify requirements?
  4. 4. 4 • Describe user needs • Describe system features • Unit of planning • Reminder for a discussion • Mechanism to defer a discussion The purpose of user stories …
  5. 5. 5 Impact Mapping Story Mapping Specification-By-Example Building software that matters Why? How? Code Acceptance Criterion Epic Deliverable, Outcome Goals, Impacts Easier to define upfront Harder to define upfront Feature User Story Example
  6. 6. 6 Impact Mapping From: Gojko Adzic: www.impactmapping.org Based on: Ingrid Domingues, Mijo Balic Effect Managing IT “Impact Mapping helps us plan better! It is collaborative, visual and fast.”
  7. 7. 7 Impact Map structure Goal Actors Impacts Deliverables WHY? WHO? HOW? WHAT? Sell 10.000 books within the first 6 months after launching the business. Shopper for mainstream books, Shopper for rarely available books, Agent preparing shipments, … Shopper for mainstream books: get books faster/more convenient find popular books easily Shopper for mainstream books: get books faster/more convenient: order books online semi-automated distribution center
  8. 8. 8 Example: Impact Map
  9. 9. 9 delivering software that generates Impact
  10. 10. 10 Specification-By-Example Impact Mapping Story Mapping Optimizing and refining scope Why? How? Code Acceptance Criterion Epic Deliverable, Outcome Goals, Impacts Easier to define upfront Harder to define upfront Feature User Story Example
  11. 11. 11 Story Maps • Original concept by Jeff Patton • Supports iterative product design • Optimized for desired outcome or deliverable the system should support
  12. 12. 14 Building story maps Get mainstream book fast and conveniently delivered Find book I want Collect books Complete order Wait for book Receive book time browse best sellers put into basket enter address receive delivery slip receive delivery notificat. pay with credit card search book by title create wish list inquiry order status desired outcome or deliverable user activities system features necessity
  13. 13. 15 Walking skeleton Enabling build – measure - learn Find book I want Collect books Complete order Wait for book Receive book time browse best sellers enter address receive delivery slip pay with credit card search book by title create wish list inquiry order status put into basket receive delivery notificat. necessity manual workaround omitted steps Get mainstream book fast and conveniently delivered
  14. 14. 16 Story Map Workshop Deliverables: • Accept and confirm candidates • Electronically publish candidate profiles • Determine funding committee through electronic voting • Provide the system as a service to other corporations
  15. 15. 17 Slicing Features
  16. 16. 18 Story Maps in ALM with TFS TFS work items in story maps http://speclog.net
  17. 17. 19 Story Map in SpecLog
  18. 18. 20 Sprint 1
  19. 19. 21 Sprint 2
  20. 20. 22 Sprint 3
  21. 21. 23 Sprint 4
  22. 22. 24 Dropped Scope
  23. 23. 25 Added Scope
  24. 24. 26 Impact Mapping Story Mapping Specification-By-Example Establishing a shared understanding Why? How? Code Acceptance Criterion Epic Capability Impact, Goal Easier to define upfront Harder to define upfront Reminder for a discussion Bug report Isolated, formalized example Feature User Story Example
  25. 25. 27 Collecting Acceptance Criteria “I would try to put a book into the shopping cart …” “I would try to remove a book from the shopping cart…” “I’d check whether the shopping cart is empty, when I enter the shop …” “I would try to add the same book again to the shopping cart …” Books can be placed into shopping cart. Books can be removed from shopping cart. Shopping cart should be empty when entering the shop. Adding same book again to shopping cart should increase quantity. As a potential customer I want to collect books in a shopping cart So that I can order several books at once. “Imagine this story is already implemented: how would you verify it?”
  26. 26. 28 Why do we need examples?
  27. 27. 29 UI wire frames, existing UI rules, key examples existing artifacts, samples Examples for user stories
  28. 28. 30 Specification-by-Example Examples … • make abstract descriptions better understandable However … • examples are usually not formally exchanged or documented Brian Marick Examples Tests Requirements consist of describe verify fulfillment of
  29. 29. 31 Discussion of acceptance criteria public void TestInitialOrderDiscount() { Customer newCustomer = new Customer(); Order newOrder = new Order(newCustomer); newOrder.AddBook( Catalog.Find(“ISBN-0955683610”) ); Assert.Equals(33.75, newOrder.Subtotal); } Register as “bart_bookworm” Go to “/catalog/search” Enter “ISBN-0955683610” Click “Search” Click “Add to Cart” Click “View Cart” Verify “Subtotal” is “$33.75” We would like to encourage new users to buy in our shop. Therefore we offer 10% discount for their first order. Original idea for the illustration: George Dinwiddie http://blog.gdinwiddie.com
  30. 30. 32 … illustrated with formalized examples Given the user has not ordered yet When the user adds a book with the price of EUR 37.5 into the shopping cart Then the shopping cart sub-total is EUR 33.75. Original idea for the illustration: George Dinwiddie http://blog.gdinwiddie.com
  31. 31. 33 Discover hidden assumptions Actually, this not quite right: Books on sale should be excluded. Original idea for the illustration: George Dinwiddie http://blog.gdinwiddie.com
  32. 32. 34 Collaboration: 3 amigos “Happy Path” Technical feasability Exceptions, border cases Original idea for the illustration: George Dinwiddie http://blog.gdinwiddie.com
  33. 33. 35 Abstract acceptance criteria As a shop visitor I want to collect books in my shopping basket so that I can purchase multiple books at once. Books can be added to the shopping basket Books can be removed from the shopping basket Shopping basket is initially empty The same book can be added multiple times to the shopping basket
  34. 34. 36 Examples for acceptance criteria As a shop visitor I want to collect books in my shopping basket so that I can purchase multiple books at once. Books can be added to the shopping basket Given my shopping basket is empty When I add the book “Harry Potter” to my shopping basket Then my shopping basket should contain 1 copy of “Harry Potter”
  35. 35. 37 As a shop visitor I want to collect books in my shopping basket so that I can purchase multiple books at once. Books can be added to the shopping basket Examples for acceptance criteria When I add the book “Harry Potter” to my shopping basket Then my shopping basket should contain 2 copies of “Harry Potter” The same book can be added multiple times to the shopping basket Given my shopping basket contains 1 copy of “Harry Potter”
  36. 36. 38 The same book can be added multiple times to the shopping basket Structure of examples Given my shopping basket contains 1 copy of “Harry Potter” When I add the book “Harry Potter” to my shopping basket Then my shopping basket should contain 2 copies of “Harry Potter” Title: Describes intention/abstract acceptance criterion Arrange: Context, initial state of the system Act: Execution of the feature Assert: Assertion of observable behaviour And I should see the warning: “Book already existed in basket” Triple-A constraint “Checks” Chaining up steps
  37. 37. 39 Purpose of examples • Shared understanding: acceptance criteria • Documentation: Look-up detail aspects of the system • Regression-tests: Understand what assumptions have been violated
  38. 38. 40 Continuous validation with automation Given my shopping basket contains 1 copy of “Harry Potter” When I add the book “Harry Potter” to my shopping basket Then my shopping basket should contain 2 copies of “Harry Potter” System „Step Definitions“ are binding individual steps to an automatable interface of the application. Automatable interface UI Automation Automation does not necessarily have to bind to the UI. Automatability of system is supported/evolving with development.
  39. 39. 41 Executable specification for .NET http://www.specflow.org Gherkin automation for .NET • Visual Studio plugin (VS-Gallery) • NuGet Package
  40. 40. 42 SpecFlow in Visual Studio
  41. 41. 43 Living documentation • Link business readable automation from source code to story maps • Feed execution results into story maps
  42. 42. 44 Books Gojko Adzic Impact Mapping Gojko Adzic Specification by Example
  43. 43. 45 Summary Impact Maps • Discover the unknown • Experiments for impacts towards goal Story Maps • Optimize and refine scope • Prioritize for rapid learning through delivery Specification-By-Example • Shared understanding • Living documentation and continuous validation
  44. 44. Questions CHRISTIAN HASSA (CH@TECHTALK.AT) @CHR99HA

×