Acceptance Criteria refers to specific conditions that must be met for a project to be considered complete. Definition of Done refers to the criteria which must be met for a project to be considered finished. And Project Scope refers to the work or deliverables that need to be met in order to complete a project.
Ok, I’m confused; what’s the difference?!
What's in here:
We look at 3 popular project management concepts, what they mean, and how to use them in your projects. These concepts are Acceptance Criteria, Definition of Done and Project Scope; and most people don't even know the difference. 🤓
What is Acceptance Criteria?
When we use the project management term Acceptance Criteria (AC), we’re talking about specific conditions that have to be met for a project, product or aspects within that project to be considered complete. When I say aspects, I mean things like sprint user stories or test cases.
Acceptance criteria is usually based on a project's objectives; it includes things like delivering a working product, meeting deadlines, or fulfilling specific customer requirements.
But before we move on, let’s take a quick look at what a user story is; you’ll see why in a bit! 😉
What is a user story?
In Agile software development, a user story is a brief explanation of a feature or functionality written from the perspective of the end user. It’s the smallest unit of work, meant to show how a software feature is going to provide value for the customer.
Product teams are big fans of user stories:
- They’re easy to understand
- They’re smaller than product features, which means they fit better in sprints
- They focus on people, rather than features
- They’re easier to track
Most product teams use a similar user story template, capturing the who, what and why: as a [persona], I want [functionality] so that [benefit].
What is a user story example?
A user story will look something like this: as a remote marketing manager, I want a good video and file sharing feature in our messaging app so that my team can collaborate in real-time while keeping everything in one place.
To estimate user stories, we use story points; I’ve got a nice article on story points if you’re interested! Now back to acceptance criteria.
Why is Acceptance Criteria important?
Managing good acceptance criteria is key when it comes to keeping everyone on track; people know what’s expected of them and there are no misunderstandings.
Also, agreeing on good acceptance criteria upfront reduces the risk of having development fail to meet user expectations. AC ensures that the solution you’re providing is high-quality because it has to meet the specific requirements of your customers, and the market as well!
How to create Acceptance Criteria?
The best way to create acceptance criteria is to work closely with the customer throughout the project. Managers typically use requirements documents or design specs to help create the AC. It’s a tricky process so a piece of advice is: make sure the AC are clear and concise, while covering all aspects of the project comprehensively.
Each project will have a different approach to defining acceptance criteria; but these are the main two we use:
Scenario-based acceptance criteria (Given-When-Then)
The Given-When-Then (GWT) formula can be used again and again to break down the user story into all possible scenarios you should test for and validate.
- Given - establishes the context at the beginning of the action
- When - input data you might need to enter once the action has been taken
- Then - outcome expected after the action (output data / end state)
Checklist or rule-based acceptance criteria
If the GWT formula doesn’t work or if you’d rather something simpler, you can use the rule-based approach; a checklist of rules that can be validated as the developer completes their work.
For a good example of scenario-based and rule-based acceptance criteria, check out this article!
What are the 8 tips for writing Acceptance Criteria?
These tips may come in handy when writing your acceptance criteria; oh and technically, they're 7:
- Have at least one acceptance criteria for every user story
- Make sure your AC have simple, clear pass/fail results
- Create every acceptance criterion on its own, independent
- Focus on the what (end result) not the how (approach)
- Include both, functional and non-functional criteria
- Write your acceptance criteria before implementation, not after
- Let someone who’s not involved in the dev process write the AC
- If devs write the AC, the Product Owner/Manager should verify after
Once you’ve created your acceptance criteria, make sure everyone involved in the project understands them.
How is Acceptance Criteria different from the Definition of Done?
Acceptance Criteria is a set of conditions that must be met for a project to be considered complete; but so is the Definition of Done. What’s the difference?
As a rule, acceptance criteria typically focuses on the end result, while the definition of done (DoD) focuses on the process by which a project should be completed. In this case, it’s actually the opposite of AC; we focus on the how (approach) instead of the what (end result) - see tip 4 in the previous section.
Building the right product vs. building it the right way
The main difference between acceptance criteria and definition of done lies in the scope. DoD applies to all of the work, while AC is specific to individual user stories. To put it simply, Definition of Done is about building the product in the right way, while Acceptance Criteria is about developing the right product.
What is the Definition of Done in project management?
We use Definition of Done to refer to the criteria which must be met for a project to be considered finished. It's a checklist of requirements to be completed before a project is “officially” done. The list includes things like finishing all tasks, meeting all deadlines, and making sure all stakeholders are happy.
Definition of done is used at the macro level, while the acceptance criteria is used at the micro level. For example, if the DoD criteria is set at the user story level, then it applies to all stories; which allows there to be a process, or common understanding across the team with respect to quality and completeness of these stories. On the other hand, you’ll have an acceptance criterion, individually set for each user story.
Why is the Definition of Done important?
You need KPIs or criteria against which you can measure the successful completion (or not) of your project. Simply setting or communicating the project goal and some indicators of success will not be enough.
DoD allows a Project manager, Product manager, Scrum master or other project leaders to create a clear checklist they can mark off as the team progresses. The Definition of done helps set a clear standard for what is finished and ready to be used, all the while helping avoid Scope Creep by clearly defining what is and isn’t included in the project.
What are 6 things to consider when creating the Definition of Done?
When creating the definition of done, make sure to consider the following:
- Make it achievable and realistic
- Review and update it constantly
- Make everyone aware of it
- Get everyone on board with the same goal: deliver high quality work
- Hold everyone accountable by periodically checking progress
- Consider the software/communication tools that work best for your project
For more on the Definition of Done (with examples) here’s a glossary article.
What is a Project Scope?
The project scope refers to all the work required to complete a project; that includes all individual tasks, activities and deliverables. To manage that in waterfall projects (traditional), we use a project scope statement - project planning document where we define the scope of the project. In Agile projects, we use a release plan and product roadmap as reference points for scope.
What is a Scope Statement?
The scope statement will define all the elements of the project scope, including the assumptions, project requirements and acceptance criteria! Now, in order to avoid being overwhelmed by the process of taking a large deliverable and turning it into a detailed timeline of activities, project managers will use what we call as Work Breakdown Structure (WBS) to help them. It’s a hierarchy made of 4 levels: project goal, broken down into project objectives, that are broken down into project outputs, which are in turn, broken down into project activities and deliverables.
What are the 5 steps to defining Project Scope?
- Identify project needs
- Come up with project goals
- Look at project limitations
- Define resources and budget
- Write a project scope statement
What is Scope Creep in Project Management?
When changes are made to the project scope without any sort of control procedure (like change requests), you end up with what we call as Scope Creep. Scope creep happens when changes are made that affect the project schedule, budget, costs and resource allocation, hence compromising the set milestones and goals. Scope creep is a very common project management risk.
What causes Scope Creep?
Funny enough, Scope Creep often happens because of good intentions, such as the desire to make a stakeholder happy or even a manager, by taking on more work than you can handle. And you know what they say: “the road to hell is paved with good intentions”.
What are examples of Scope Creep?
Take these two examples, which may seem innocent at first, but can do quite a bit of damage if the project lacks the capacity for them:
- A couple of new user stories get added to the sprint after development has started
- Someone on the dev team decides to add new features or enhancements without being asked to
How to manage Scope Creep?
Within the Agile project processes themselves, there’s a kind of existing safety net for managing scope creep: short increments and regular inspection.
In more traditional projects however, and given the longer periods of time between requirements, development and testing, it would be best to follow the Agile principles of shorter cycles and iterative inspection and embed them as part of your project quality assurance process.
Yes, Agile rocks! 🤘