Agile requirements management

9,673 views
9,067 views

Published on

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

1 Comment
41 Likes
Statistics
Notes
No Downloads
Views
Total views
9,673
On SlideShare
0
From Embeds
0
Number of Embeds
52
Actions
Shares
0
Downloads
384
Comments
1
Likes
41
Embeds 0
No embeds

No notes for slide

Agile requirements management

  1. 1. Agile requirements managementEnd-to-End: from project goals toautomated acceptance testsCHRISTIAN HASSACH@TECHTALK.AT@CHR99HAALM Summit Vienna, 30th of November 2012
  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. How do we specify requirements?3
  4. 4. The purpose of user stories …• Describe user needs• Describe system features• Unit of planning• Reminder for a discussion• Mechanism to defer a discussion4
  5. 5. Building software that matters Why? Impact Mapping Goals, Impacts Deliverable, Outcome Story Mapping Feature Epic User Story Acceptance Criterion Example Specification-By-Example Code How? Easier to define upfront Harder to define upfront5
  6. 6. Impact Mapping “Impact Mapping helps us plan better! It is collaborative, visual and fast.” Based on: Ingrid Domingues, Mijo Balic From: Gojko Adzic: www.impactmapping.org Effect Managing IT6
  7. 7. Impact Map structure Sell 10.000 books within the first 6 months WHY? Goal after launching the business. Shopper for mainstream books, WHO? Actors Shopper for rarely available books, Agent preparing shipments, … Shopper for mainstream books: HOW? Impacts get books faster/more convenient find popular books easily Shopper for mainstream books: get books faster/more convenient: WHAT? Deliverables order books online semi-automated distribution center7
  8. 8. Example: Impact Map8
  9. 9. delivering software that generates Impact9
  10. 10. Optimizing and refining scope Why? Impact Mapping Goals, Impacts Deliverable, Outcome Story Mapping Feature Epic User Story Acceptance Criterion Example Specification-By-Example Code How? Easier to define upfront Harder to define upfront10
  11. 11. Story Maps• Original concept by Jeff Patton• Supports iterative product design• Optimized for desired outcome or deliverable the system should support11
  12. 12. Building story maps Get mainstream book fast and conveniently desired outcome delivered or deliverable Find book Collect Complete Wait for Receive user I want books order book book activities time browse receive receive put into enter system best delivery delivery basket address featuresnecessity sellers notificat. slip search pay with inquiry create book by credit order wish list title card status 14
  13. 13. Enabling build – measure - learn Get mainstream book fast and conveniently delivered Find book Collect Complete Wait for Receive I want books order book book time browse omitted receive manual enter Walking best workaround steps delivery address skeletonnecessity sellers slip search pay with inquiry create receive book by put into credit order wish list delivery title basket card status notificat. 15
  14. 14. 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 corporations16
  15. 15. Slicing Features17
  16. 16. Story Maps in ALM with TFS http://speclog.net TFS work items in story maps18
  17. 17. Story Map in SpecLog19
  18. 18. Sprint 120
  19. 19. Sprint 221
  20. 20. Sprint 322
  21. 21. Sprint 423
  22. 22. Dropped Scope24
  23. 23. Added Scope25
  24. 24. Establishing a shared understanding Why? Impact Mapping Impact, Goal Isolated, Capability Story Mapping formalized example Feature Epic User Story Reminder Acceptance for a Bug Criterion discussion report Example Specification-By-Example Code How? Easier to define upfront Harder to define upfront26
  25. 25. Collecting Acceptance Criteria As a potential customer “Imagine this story is I want to collect books in a shopping cart already implemented: So that I can order several books at once. how would you verify it?” “I would try to put a book into the shopping cart …” Books can be placed into shopping cart. “I would try to remove a book from the shopping cart…” Books can be removed from shopping cart. “I’d check whether the shopping cart is empty, when I enter the shop …” Shopping cart should be empty when entering the shop. Adding same book again to “I would try to add the same book shopping cart should increase again to the shopping cart …” quantity.27
  26. 26. Why do we need examples?28
  27. 27. Examples for user stories UI wire frames, existing UI rules, key examples existing artifacts, samples29
  28. 28. Specification-by-Example Examples … • make abstract descriptions better understandable However … • examples are usually not formally Brian Marick exchanged or documented consist of Examples Tests describe verify fulfillment of Requirements30
  29. 29. Discussion of acceptance criteria We would like to encourage new users to buy in our shop. Therefore we offer 10% discount for their first order. public void TestInitialOrderDiscount() Register as “bart_bookworm” { Go to “/catalog/search” Customer newCustomer = new Customer(); Enter “ISBN-0955683610” Order newOrder = new Order(newCustomer); Click “Search” newOrder.AddBook( Catalog.Find(“ISBN-0955683610”) Click “Add to Cart” ); Click “View Cart” Assert.Equals(33.75, Verify “Subtotal” is “$33.75” newOrder.Subtotal); } Original idea for the illustration: George Dinwiddie http://blog.gdinwiddie.com31
  30. 30. … 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.com32
  31. 31. Discover hidden assumptions Actually, this not quite right: Books on sale should be excluded. Original idea for the illustration: George Dinwiddie http://blog.gdinwiddie.com33
  32. 32. Collaboration: 3 amigos Exceptions, “Happy Technical border cases Path” feasability Original idea for the illustration: George Dinwiddie http://blog.gdinwiddie.com34
  33. 33. 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 basket35
  34. 34. 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”36
  35. 35. 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 The same book can be added multiple times to the shopping basket 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”37
  36. 36. Structure of examples Title: Describes intention/abstract acceptance criterion Arrange: Context, initial state of the system Triple-A Act: Execution of the feature constraint “Checks” Assert: Assertion of observable behaviour The same book can be added multiple times to the shopping basket 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” And I should see the warning: “Book already existed in basket” Chaining up steps38
  37. 37. Purpose of examples• Shared understanding: acceptance criteria• Documentation: Look-up detail aspects of the system• Regression-tests: Understand what assumptions have been violated39
  38. 38. Continuous validation with automation „Step Definitions“ are binding individual steps to an automatable interface of the application. Automation does not necessarily have to bind to the UI. Automatability of system is supported/evolving with development. 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” UI System Automation Automatable interface40
  39. 39. Executable specification for .NEThttp://www.specflow.orgGherkin automation for .NET• Visual Studio plugin (VS-Gallery)• NuGet Package41
  40. 40. SpecFlow in Visual Studio42
  41. 41. Living documentation• Link business readable automation from source code to story maps• Feed execution results into story maps43
  42. 42. Books Gojko Adzic Gojko Adzic Impact Mapping Specification by Example44
  43. 43. SummaryImpact Maps • Discover the unknown • Experiments for impacts towards goalStory Maps • Optimize and refine scope • Prioritize for rapid learning through deliverySpecification-By-Example • Shared understanding • Living documentation and continuous validation45
  44. 44. QuestionsCHRISTIAN HASSA (CH@TECHTALK.AT)@CHR99HA

×