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.

Acceptance criteria 101

3 views

Published on

Writing acceptance criteria is not hard, unfortunately, writing bad acceptance criteria is even easier. Without knowing the really basic details, the outcome is often mainly due to a chance and individual talent. Since we shouldn't really rely on chance, and since we not all super-talented, the alternative to "just wing it" is to understand what acceptance criteria really are and that they are extremely simple things when all the layers of fancy terms and philosophy are removed.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Acceptance criteria 101

  1. 1. ZAGREB Acceptance criteria 101 (or “describing a new and better world”)
  2. 2. Content A couple of definitions (with examples) Finding the right level of detail The natural place of the AC in the dev process (two) Examples The conclusion
  3. 3. A couple of definitions (lightly sprinkled with examples)
  4. 4. An acceptance criteria is a present tense statement, that can be unambiguously demonstrated to be either true or false. A couple of definitions (with examples)
  5. 5. “When a visitor types more than 2 characters of their query in the search box, then an auto suggest tool with a list of results best matching their partial query is displayed” A couple of definitions (with examples)
  6. 6. Acceptance criteria are a set of statements which describe the world once the related work item is completed. (or put in another way "that were all false before the work item was completed and are all true afterwards") It’s a diff of those two worlds really. A couple of definitions (with examples)
  7. 7. The world BEFORE: “When a visitor enters their search term in the search box, nothing happens until they press enter or click on the search tool, and then the search results page is displayed.” The world AFTER: “When a visitor types more than 2 characters of their query in the search box, then an auto suggest tool with a list of results best matching their partial query is displayed” A couple of definitions (with examples)
  8. 8. Acceptance criteria answers the question “what does the software that I’m currently working on need to be able to accomplish in order for me and everyone else consider it completed?” (it also extends beyond “just” software development) A couple of definitions (with examples)
  9. 9. Finding the right level of detail (or “how deep should my rabbit hole be?”)
  10. 10. Is each of my acceptance criteria statement easily and quickly demostrable to be true or false? if a junior dev would get to develop this one - how likely is that he’d get it seriously wrong? Are there any active verbs in my acceptance criteria statements? Some helpful questions
  11. 11. “Develop an auto suggest feature which conforms to UI wireframe X.Y, business rules A.B and implements use cases Q,W,E and all of their extensions” Some helpful questions
  12. 12. “Develop an auto suggest feature which conforms to UI wireframe X.Y, business rules A.B and implements use cases Q,W,E and all of their extensions” ...active verb, demoable but not easily and quickly... Some helpful questions
  13. 13. 1. When a visitor enters two or more characters in the search box, and an auto-suggest list is not already displayed, then a list of up to ten suggestions is displayed. 2. When a visitor enters two or more characters in the search box, and an auto-suggest list is already displayed, then a list of suggestions is updated to match the entered term. 3. When a autosuggest list is displayed, it’s done so in accordance with UI wireframe X.Y 4. When a list of suggestion is displayed within the autosuggest list, items of that list are compiled in accordance with business rules defined in the table A.B 5. ... Some helpful questions
  14. 14. The diagram (or “the big picture”)
  15. 15. Acceptance criteria and different req. types Functional requirements - implicit “Every use case with every extension from this document is demonstrated to be implemented completely and accurately to the client representative.”
  16. 16. Acceptance criteria and different req. types Nonfunctional requirements - explicit “Component X is developed so that it conforms to performance requirements stated in points Q,W and Y”
  17. 17. Acceptance criteria and different req. types class WorkItem implements Developable; interface Developable { public function getAcceptanceCriteria(): Traversable; } class Production { public function develop(Developable $workItem): Software; }
  18. 18. Acceptance criteria and different req. types Work items - explicit “(development ready) Work item” is any artefact that can be sent “as-is” to production and whose development outcome is guaranteed to be complete and accurate based only upon the data and references provided by that work item.
  19. 19. Acceptance criteria and different req. types Acceptance criteria are A MANDATORY part of requirements (specification) for any “development ready” work item, regardless of its size. Acceptance criteria are also by far THE MOST IMPORTANT PART of the requirements for any “development ready” work item. Everything else could be omitted and the work item could still be completed (developed) only based on acceptance criteria (if done properly).
  20. 20. The examples (all the two of them)
  21. 21. An example The task: “Replace custom authentication system with symfony security”
  22. 22. An example 1. Symfony security component is installed and is part of composer json file 2. A document is added to project documentation clearly describing how authentication should be performed including examples on how to get currently logged user in different contexts 3. All existing authentication/logged user provider services (oldAndWeirdAuthenticationProvider, loggedUserProvider, really_old_user_provider) are refactored so that they facade symfony security authentication/user provider system and contain no internal logic on their own 4. …
  23. 23. Another example The task: “Enable easier creating of fixtures for categories”
  24. 24. Another example 1. A research is performed resulting in a document (the format is not important) containing at least following information: a. a list of issues / problems with the current system b. a draft of the desired way (solution) the category fixtures should created and used - including illustrative examples 2. A document is reviewed and draft of the solution approved by the architecture team 3. …
  25. 25. The conclusion (or “why in the name of sweet coding Jesus should I care about all this?”)
  26. 26. Conclusion (why should you care) If you cannot precisely describe how the world in which your piece of work is completed looks like, then you don’t know what you need to deliver into it.
  27. 27. Conclusion Acceptance criteria are a set of statements that are all false before work item is finished, but become all true once it does (they describe the new world). Acceptance criteria should ALWAYS BE THE LAST thing to get finished when writing a work item definition Acceptance criteria should always be specific - and explicitly list/mention every item/component/service they relate to
  28. 28. Conclusion Very technical acceptance criteria are perfectly fine - as long as the work item is very technical in its nature (refactoring etc.) or if you want to make 100% sure that the developed solution will conform to particular tech. requirements “r&d” acceptance criteria are perfectly fine - as long as they have a clear specification of acceptable outcome (the research results containing at least X and Y are documented and… etc.)
  29. 29. Conclusion Acceptance criteria are A MANDATORY part of requirements (specification) for any “development ready” work item, regardless of its size. Acceptance criteria are also by far THE MOST IMPORTANT PART of the requirements for any “development ready” work item. Everything else could be omitted and the work item could still be completed (developed) only based on acceptance criteria (if done properly).
  30. 30. Conclusion Don’t obsess about the form (“to gherkin or not to gherkin” etc.) make sure the content is right instead.
  31. 31. Related blog posts on Trikoder blog https://blog.trikoder.net/acceptance-criteria-demystified-4 8a817c2f9ca?source=friends_link&sk=f037a228f26340c4f0 bf2df068627a4e https://blog.trikoder.net/software-requirements-specificati ons-made-somewhat-simple-part-1-7b1949369364?source =friends_link&sk=492e64149967f74dee3cddd017d9e39f https://blog.trikoder.net/software-requirements-specificati ons-made-somewhat-simple-part-2-a2c99c31e4f9?source= friends_link&sk=eff0ef70ad58ad84ba334bed5003b507
  32. 32. Q&A
  33. 33. Trikoder d.o.o. https://blog.trikoder.net/ Vedran Križek thebrkonja@gmail.com https://www.linkedin.com/in/vedrankrizek/

×