Learn how Acceptance Criteria compares with the Definition of Done.
This video will cover:
If you are interested in learning Scrum or teaching it to your team, you'll want to check out Everyday Scrum. It's a guide for everyday people to learn Scrum and is written intentionally to be accessible to those practicing Scrum outside the software development space.
You may also find my specific posts on Acceptance Criteria and the Definition of Done helpful.
If you want to explore more Scrum related content, I have lot's of Agile and Scrum posts for you and I've highlighted a few of them below.
Have you ever been on a project where essentially everything seemed to be mostly done but nothing seemed to really be done? Well, when it comes to using Scrum to get stuff done, acceptance criteria and the definition of done both play really important roles. And so today we'll look at how they're different, but also how they work together.
So are you a leader who wants your team to be able to make and keep commitments? Well, that's great. That's what we're going to talk about. Or maybe, you know, you're a team member who just wants everything to actually get done. Either way, this video is going to be helpful as we tackle the challenge of work that stays undone and how to deal with that, how to get it done, because it can be so frustrating when you expect something to be done and then you find it's not.
I've run into that where someone's like, Oh yeah, it's done. And I go in to get it and it's like, It's not done. Someone says it's 80% done, but then a week later it's still 80% done. A month later it's like 83%. And it's like, What have you been doing? What's going on? The truth is, it's just either done or it's not.
And that's where acceptance criteria and the definition of done are two tools that really help us combat this challenge of undone work. So let's dive in and start by briefly defining each of these, okay? Acceptance criteria. Acceptance criteria defines the requirements which must be met for the sprint deliverables to be accepted by the product owner. It's really like what must be true for this to be done.
But the acceptance criteria is specific to an individual task. It answers the question really what will be true when this task is completed. The definition of done, on the other hand, is, well, it's also a criteria, but it outlines what must be true for any product backlog item that the team engages in to be considered done.
So it's not specific to a given item, it's broader than that. So this criteria, it's broad and flexible enough to apply to all the backlog items, but it's still concrete and specific enough to be really clear, like, okay, did you meet this criteria? So the definition of done, it applies to all the work done by the team. It answers really the question What are we committing to do every time we complete a task?
So acceptance criteria is what what has to be true for this specific task to be done and what has to be true for like really any of our tasks to be done. So that's kind of how they both answer a slightly different question, but you can see how they're going to start working together again. Acceptance criteria, it's specific to given task definition of done applies to all tasks.
So every task should end up having both a specific acceptance criteria and a general definition of done being applied to it. Let's look at an example of what the acceptance criteria and definition of done look like for a given team. We're going to use the example of a creative team delivering some marketing collateral. So, okay, let's say that team is making a marketing campaign and the acceptance criteria for that item is given that which is the first step, a customer is already receiving email communication when they visit our site and engage in content related to, let's say, product X, then they automatically be subscribed to nurture campaign highlighting that product.
Okay, acceptance criteria takes this form of given that when and then that's the template. If you want more about how to write acceptance criteria, check out this video. I go all into it, cover all that stuff, but you can see that at the end of the sprint. This is how we know that functionality works. If it works that way, the task is done.
If it doesn't, it's not period. So what role does the definition of done play on that team? Well, that same marketing team is going to have a definition of done. Let's say this is their definition of done that they share for all their tasks. All the team members commit to that for everything we do, user testing gets performed and those results are shared.
The client. So they would have user tested some of that content. At least one demo is performed during the sprint to the client. So they're getting feedback before the end that that the success criteria or the acceptance criteria is met. Okay, that's kind of a given, but it still doesn't hurt to have in there. I've seen that a lot of times with teams.
The assets get delivered to the clients, the assets and the design files are in the proper folder. That's an important one, with definition of dones, the product owner accepts the user story. The there's an invoice submitted if that makes sense for the way this team functions. A customer survey gets sent out and an evaluation gets scheduled to follow up.
So do you see how like those criteria can apply to all different tasks in their backlog? Remember, the definition of done is a commitment for every task. So to be called done, it must meet all of the definition of done criteria as well as the acceptance criteria. Now you can see how this could be kind of overwhelming at first, but as you think through that list, most of those are really just like basic, like do the job kind of stuff.
But it's helpful because there's just no ambiguity anymore. Clearly stating them allows the team to commit to like this is what we're going to get done and that changes the team culture around getting stuff done. So imagine this whole team is clear about what's expected of them. They trust each other to get things done. I trust that you're going to get stuff done.
You trust that I'm going to get stuff done. Everyone is consistently delivering the right value with all the details taken care of. That sounds pretty good because then there's no more reworking what was mostly done but not really done. And that's why you want to use both acceptance criteria and definition of done when you're practicing Scrum on your team.
If you want to know more about either, check out the the videos, check out the links in the description. If you have a specific question about acceptance criteria or definition of done or how they all work together, throw that in the comments would love to engage with you there if you found this video helpful. Please like and subscribe and keep making more of them.
Thanks. See you next time.