Acceptance criteria are a straight-forward way of describing, what needs to be in place before a task can be marked as done.
You might have experienced the following situation: you are in a refinement meeting and you just finished discussing a certain task. Now the team is about to estimate the effort of the task using planning poker: The poker cards for estimation show values between 3 and 13 story points!
So some people in the team think the task is more than four times as much effort to implement than other team members.
Discussing the estimation difference the team realizes, that team members had a completely different scope of the task in their head. That’s why there were such big differences in the estimation.
Unclear scope of task
I have been in many discussions, where people talk about what is the scope of a certain task. Although the description of the task is long and detailed, it is not clear what exactly needs to be delivered as part of the task.
This is especially uncomfortable, when the discussion is started during the sprint by the person, who is working on the task. Is this also part of the task?
When somebody creates a new task in the backlog, then this person has his own view on the topic. Sometimes the description is just 1 sentence and sometimes it is a whole page. Coming up with the right amount of description is not easy.
Problem of task description too short
When creating a task some people try to keep the description of the task as short as possible. They think that only the members of the team have to understand the scope of the task. And as the team will discuss the scope of the task in a refinement meeting, the details will be talked through anyway. So there is no need to have a detailed description, right?
Wrong!
Not all people are always present in those meetings, team members might be on holiday or are just not paying attention. Or it is also completely normal that people might forget about some details of scope discussions.
Therefore writing down the most important things in the task description is clearly a must for a proper backlog item.
Problem of task description too long
Then there are some people, including myself, who tend to write too long descriptions of tasks. The idea is to make the scope of the task understandable to everybody, even for non-technical people. This results in a long text, explaining the purpose, dependencies to other teams, things, which are out-of-scope, etc.
The problem is, that it is not clear what is part of the task and what is just there for clarification. Different people might interpret the description differently, because they have different backgrounds. And some people might not even read the description, because it is too long.
Finding the right balance of clear-enough description versus too-detailed description is not simple.
Adding acceptance criteria to a task
On top of having a title and a description, you can also add acceptance criteria to a task.
Acceptance criteria is a list of conditions, that a software must satisfy to be accepted by the stakeholders.
They define what a software should do, without specifying implementation details. So they don’t state how the software should do it, but only what the software should do.
Acceptance criteria should be relatively high-level while still providing enough detail to be useful.
They should include functional criteria, non-functional criteria and performance criteria.
Functional criteria
Functional criteria define how the software should work. It define the business processes in a software. For instance “the user can search servers by brand and type“.
One format for defining functional criteria is the Given/When/Then format:
Given some precondition When I do some action Then I expect some result.
Non-Functional criteria
Non-functional criteria define conditions for non-functional requirements. For instance, “the search button complies with the design of the search button on the front page“.
Performance criteria
In case performance is critical, then adding criteria defining performance thresholds make sense. For instance, you can add requirements for the maximum response time of a certain API call.
Benefits of acceptance criteria
Acceptance criteria make it clear in just a simple and usually short list of conditions, what should be done as part of the task. Therefore they are very helpful for the team to understand the scope of a task.
You can see the benefits of acceptance criteria during refinement meetings. Everybody is on the same page, when it comes to the estimation of the task.
Next to that, acceptance criteria are also very helpful for the tester. They make the job of the tester a bit easier, because he/she has a starting point on what needs to be tested.
Disadvantage of acceptance criteria
The downside of acceptance criteria is that everyone might rely on that list made by the creator of the task, without rethinking if the list is correct or complete.
If you don’t have acceptance criteria yet, then just give it a try for a few sprints and see how it goes.
In my experience it helped the team to make tasks much more clear, with just a little bit of more effort during the creation of the task.
Ok, that’s it for today.
I’m curious if you define acceptance criteria for each task and whether you find them helpful or just overhead. Let me know in a comment!
Stay tuned and until next week. HabbediEhre!
