This post is the continuation of the series on why & how we started the travel towards Continuous Integration and Continuous Delivery, about test automation, build and deployment, time management and security …

This is third part of the series, you can find previuse episode here.

Hocine Ziani, 1953
Hocine Ziani, 1953

Table of contents:

  1. Acceptance Criteria and Prince from the East
  2. Wait! What about the following questions?
  3. Free the developer’s machines!

Acceptance Criteria and Prince from the East

Acceptance criteria are one of the important stories needed in development. I have worked in many places and of course, they looked completely different in many places. One thing is for sure, it’s not good when they are gone, it’s bad if the business doesn’t understand what they are for. So let’s start from the beginning. In the project, I worked on some time ago, it was not entirely clear what a given contractor should meet and what assumptions. The most important thing was that during the two-week sprint, at the end of the second week, the assumptions could change diametrically, which resulted in:

  • stress
  • confusion and chaos
  • great WTF in the eyes of the programmer and, as you probably understand, also in mine, saying eyes like 5 zlotys best reflects the picture of the situation

The business did not fully understand the seriousness of the situation and the problem it had created. If we have such a thing as planning, assumptions are made in the planning. The plan is to prove them at the end of the spiral, usually at the end of the second week. The situation may not be catastrophic, but it is also not the best.

Rules

The introduction of certain rules, i.e. well-written AC (acceptance criteria), finally allowed to systematize the process:

  • estimate how much time the functionality will take
  • which depends on what (in large systems it matters)
  • avoiding chaos and thus avoiding AHA moment at the end of the sprint

Good AC allows you to dispel doubts, but you must not allow a situation in which:

  • are out of date
  • very laconic
  • the information contained therein refers to several places

What happens above is that several places need to be proven to be updated. And if the information is incomplete or mutually exclusive, there is a problem with its implementation, there is a communication problem, and time is wasted.

At the end of the sprint, of course, everyone wants to know how many story points are blown, and how many functionalities have been provided for the client. This is where the Acceptance Criteria are helpful. From a business point of view, they allow you to solve many problems related to communication and save the time needed for development.

However, AC should not be confused with DoD. There is a slight difference between the two.

Definition of done and Acceptance criteria what’s the difference?

Definition of done applice tha whole product increment and does not apply to a product backlog, epic, feauter, story … This is myth that DoD is applies of multilevels, just the increment. There is no information in Scrum Guide about Acceptance Criteria, what ofter confuse people in statement: Product Backlog items often include test descriptions that will prove its completeness when "Done".

Acceptance Criteria, which is optional and a complementary with Scrum practise taken from XP, may apply to the Procuct Backlog items, and is the context to the desired functionality of the Procut Backlog items.

Short example - Definition of Done

  • Definition of Donde(DoD): No Critical and High defect will be accepted; code coverage percentage to be at least 70%; all web pages to load in under 2 seconds

  • Acceptance Criteria: The password must be no less than 8 and no greater than 12 characters, contain at least one Uppercase letter, one lower case letter, and at least one number.

Think Definition of Done at the macro level, and Acceptance Criteria at the micro. Not all organizations specify what done means for their product, therefor the Scrum Team (or just the team if you don’t have any scrum master) must define the Definition of Done for the product they are working on. Good way is also define Definition of Done they may also create these in Sprint Planning of their first Sprint.

Acceptance Criteria is applicable to specific User Story. Acceptance Criteria of each User Story will be different based on the requirements of that User Story.

In other words, Both DoD and Acceptance Criteria must be met in order to complete the User Story. The Product Increment is not considered to be complete, unless both these two lists are done.

Short example – Acceptance Criteria

  • A user cannot submit a form without completing all the mandatory fields
  • Information from the form is stored in the registrations database
  • Payment can be made via credit card
  • An acknowledgment email is sent to the user after submitting the form

To make this story short: after AC was introduced in our project, it was much easier as a team to determine what was done, what we could not do, what depends on what. Even if we did not manage to deliver some functionalities on time, it is also ok. We know best how we can improve the task estimation.

So exotic.

Reference:

  1. Automation Journey - episode I
  2. Automation Journey - episode II
  3. Automation Journey - episode III
  4. Automation Journey - episode IV
  5. Automation Journey - episode V
  6. Automation Journey - episode VI
  7. Automation Journey - episode VII
  8. Automation Journey - episode VIII

My site is free of ads and trackers. Was this post helpful to you? Why not BuyMeACoffee