How to set good acceptance criteria in Scrum?

Scrum, an Agile framework designed to manage all the hefty knowledge work that comes with software development projects, places a strong emphasis on delivering value to the customer in short, iterative cycles.

One of the key components in this process is the establishment of clear and meaningful acceptance criteria for specific deliverables. They serve as the benchmark for evaluating the user stories and features delivered by the team in subsequent increments.

What are Scrum acceptance criteria?

In Scrum, acceptance criteria are a set of predefined requirements that a product or product increment must meet to be considered complete and ready for delivery. These criteria play a vital role in guiding the development team and ensuring that the product aligns with the customer's needs and expectations. Here are the key aspects of acceptance criteria in Scrum:

• Acceptance criteria are tied directly to individual user stories or features. They detail the conditions that a specific piece of functionality must meet to be considered complete and satisfactory from the user's perspective.
• These criteria are primarily concerned with what the feature does, how it behaves, and whether it fulfills the user’s needs and requirements outlined in the user story. They are about ensuring that the feature delivers the expected value to the user.
• Scrum acceptance criteria can vary significantly from one feature to another, as each user story or feature has its unique requirements and expectations, set for the purpose of each project.

Acceptance criteria vs Definition of Done in Agile

What is the Definition of Done (DoD) and why am I even mentioning it anyway? It’s important to discuss this concept alongside acceptance criteria as both share a common goal in Scrum projects: to ensure that the software product is developed to a high standard, fulfilling both user-specific requirements and broader project quality standards. The DoD:

• is a broader checklist that applies at the project or team level; it is a standard that applies to all tasks or user stories within a project.
• ensures that all work meets a certain level of quality and is ready for delivery, which usually includes criteria related to coding standards, integration, testing (both development and user acceptance testing), documentation, and release planning.
• remains consistent across the project or for the team - it establishes a clear and shared understanding among all team members of what it means for any work to be complete.

What’s crucial to take away from this section is the fact that Scrum acceptance criteria and Definition of Done have very distinct purposes: the DoD usually complements the acceptance criteria and differs in scope and how they are being defined. Consider the below project management aspects:

• Both are integral to Quality Assurance of the deliverable: Scrum acceptance criteria ensure that each feature or user story meets the specific requirements and quality expectations from a user's perspective. The DoD complements this by setting a standard of quality and completeness that applies to all features and tasks in the project.
• Both provide clear, actionable guidelines for the development team. Acceptance criteria offer a detailed, itemized list of conditions that a particular feature must meet, while the Definition of Done provides a checklist of criteria that signify the completion of any task or feature in the project.
• Both acceptance criteria and the DoD serve as a basis for testing and reviewing work. Scrum acceptance criteria are used to verify that a feature fulfills its intended purpose, while the DoD ensures that the work has been thoroughly tested, documented, and meets the overall standards set by the team.
• Both are crucial for the successful delivery of the project. Meeting the acceptance criteria ensures that the product is functional and satisfies user needs, while adhering to the Definition of Done in Agile ensures that the product is of high quality, reliable, and ready for release.

Acceptance criteria examples

Below, I’m citing three examples that demonstrate how acceptance criteria directly translate user stories into specific, actionable items.

Example 1: E-commerce Checkout Process

User Story: "As a customer, I want to easily complete my purchase so that I can efficiently check out with my selected items."

Acceptance criteria examples:

• Checkout interface: the checkout button should be clearly visible on the shopping cart page.
• Form fields: users must be able to enter shipping and billing information, including name, address, and payment details.
• Data validation: the system validates entered data for format and completeness (e.g., no missing fields, valid credit card format).
• Confirmation message: upon successful transaction, a confirmation message with the order number and a summary of the purchase appears.
• Error handling: if the transaction fails, the user receives an error message explaining the reason (e.g., insufficient funds, wrong payment details).
• Mobile responsiveness: the checkout process must be fully functional and user-friendly on both desktop and mobile devices.

Example 2: User Profile Update Feature

User Story: "As a registered user, I want to be able to update my profile information so that I can keep my personal details current."

Scrum acceptance criteria examples:

• Access to profile: users can access their profile settings from the dashboard.
• Editable fields: profile fields such as name, email, password, and phone number are editable.
• Save functionality: changes are saved when the user clicks the 'Save' button.
• Feedback on save: The user receives a notification confirming that profile changes have been successfully saved.
• Data validation: the system checks for valid email format and strong password criteria.
• Security prompt: for sensitive changes (e.g., password), the user is prompted to re-enter their current password.

Example 3: Search Functionality in a Library App

User Story: "As a library app user, I want to search for books by title so that I can find specific books quickly."

Acceptance criteria examples:

• Search bar accessibility: a search bar is available on the main page of the app.
• Input recognition: the search function recognizes input of at least three characters.
• Result display: search results display books with titles matching the search query.
• No result handling: if no matches are found, the app displays a 'No results found' message.
• Performance: search results load within 3 seconds.
• Sorting options: users can sort the search results by title, author, or publication date.

The purpose of acceptance criteria in Scrum

The concept of Scrum acceptance criteria was introduced first and foremost to aligning the expectations of everyone involved in the project - something that is of utmost importance especially when your team is distributed across different locations. They are fundamental in bridging the gap between the conceptual and practical aspects of software development, set to ensure that the final product aligns with the project's goals and user needs. This is achieved through the below aspects of product development, which are set forth by the acceptance criteria:

Defining success metrics

Acceptance criteria serve as a concrete definition of what success looks like for a given feature or user story. They help everyone involved understand when a task is completed satisfactorily - a level of clarity that is vital in agile development.

Managing expectations

They play a key role in managing stakeholder expectations. By defining the scope and functionality of a feature upfront, acceptance criteria help in setting realistic expectations and prevent scope creep.

Guiding development

For developers, acceptance criteria actually act as a project roadmap. They provide specific, actionable objectives that guide coding and design decisions. Such focused guidance eliminates ambiguities and ensures that the team works efficiently towards the agreed-upon goals.

Facilitating communication

They foster better communication between stakeholders, including product owners, developers, and users. By clearly stating what is expected from a feature, acceptance criteria minimize the risk of misinterpretations, which are common in complex software projects.

Enhancing Quality Assurance

Defining meaningful acceptance criteria is invaluable for testing. They provide a basis for creating test cases and scenarios, ensuring that all critical aspects of a feature are tested. With testing, Scrum acceptance criteria also help to ensure that the features meet the required standards.

What makes acceptance criteria meaningful?

Scrum acceptance criteria play a vital role in guiding the development team and ensuring that the product aligns with the customer's needs and expectations. Here are the characteristics of well-defined acceptance criteria:

Clarity 

Clear acceptance criteria are first and foremost unambiguous. They are expressed in a straightforward language that leaves no room for multiple interpretations. They are simple and to the point, and avoid overly complex explanations and technical jargon that could confuse non-technical stakeholders. This is crucial in ensuring that developers, testers, and stakeholders have a consistent understanding of what is expected.

Conciseness

Effective agile acceptance criteria are concise, communicating the essential points without unnecessary elaboration. This brevity makes them easy to read and understand. They concentrate on the essential aspects of a feature, avoiding tangential details that could divert attention from the main objectives.

Testability

Good acceptance criteria have clear, measurable outcomes. They often include quantifiable metrics, such as performance benchmarks, which provide a tangible way to evaluate the feature's success. This allows testers to objectively assess whether a criterion has been met. Good criteria will allow testers to create test scenarios, helping them to cover all relevant use cases in their assessments.

Relevance

Each criterion should be directly tied to a user story or feature requirement. This ensures that the criteria are relevant to what the end-users need and expect. They should align with the broader business goals and objectives of the project. This alignment guarantees that the feature contributes meaningfully to the overall success of the product.

Achievability

The criteria set should be achievable within the constraints of the project, including time, budget, and technical capabilities. They should be feasible, taking into account the existing infrastructure, technological capabilities, and skill sets of the development team.

Negotiability

Acceptance criteria should be flexible enough to accommodate changes in requirements or insights gained during the development process. They should allow for adjustments without compromising the core objectives of the feature.

User-centricity

Good acceptance criteria are focused on the end-user experience. They consider how the feature will be used and the value it will provide to the user.

Comprehensive coverage

While being concise, they should also be comprehensive enough to cover all critical aspects of a feature: including edge cases and exceptions.

7 steps to setting meaningful acceptance criteria

Setting acceptance criteria is a dynamic and collaborative process that requires a deep understanding of user needs, clear communication, specificity, and an iterative approach. By following these steps, product owners can establish a solid foundation for their development teams to deliver high-quality, user-centric features that align with the broader objectives of the project.

Before I delve into the process, I’d like to draw your attention to 4 common mistakes to avoid:

• Being too broad or vague, which leads to different interpretations.
• Overloading with details, which restrict the team’s creativity.
• Ignoring non-functional requirements, which means you’re forgetting about performance, security, and usability.
• Not reviewing criteria regularly, which creates a risk of becoming irrelevant.

Step 1: Start with User Stories

Begin by thoroughly understanding the user stories. These stories should reflect the needs and expectations of the end-users, offering a clear picture of what the users want to achieve with the product. Dissect each user story into its essential components will help you identify key functionalities and requirements that the acceptance criteria should address.

Step 2: Involve the team

Setting the acceptance criteria is a collaborative process (collaboration is in fact one of the fundamental principles of Scrum)! Involve the development team, QA testers, and other stakeholders in the process of setting acceptance criteria. This collaborative approach ensures diverse perspectives and a more comprehensive understanding of what needs to be achieved. Encourage open communication and feedback. Team members may offer insights or raise concerns that could significantly impact the formulation of the acceptance criteria.

Use language that is easily understandable by all stakeholders, irrespective of their technical background. Avoiding technical jargon is crucial in ensuring that everyone has the same understanding of what the criteria entail.

Step 3: Be specific throughout the process

Use language that is easily understandable by all stakeholders, irrespective of their technical background. Avoiding technical jargon is crucial in ensuring that everyone has the same understanding of what the criteria entail.

Specificity in acceptance criteria is key. Each criterion should be detailed enough to convey exactly what is expected without leaving room for interpretation.

Finally, incorporate real-world scenarios to explain the criteria. This approach helps in visualizing how the criteria will apply in practical use cases.

Step 4: Focus on UX

Center the criteria around how users will interact with the feature. Consider the user journey and how the feature fits into this journey. When you’re at this stage of the process, focus on the desired outcome from the user’s perspective. What should the user be able to achieve or experience as a result of this feature?

Step 5: Prioritize

Distinguish between what is essential and what is a nice-to-have. This prioritization helps in focusing on the most critical aspects of the feature. I’ve written a separate article on the different prioritization techniques you can employ throughout the process. Also: do consider the risks associated with each criterion. Higher-risk aspects might need more detailed and stringent criteria.

Step 6: Consider different scenarios

Think about different scenarios in which the feature will be used. This includes considering edge cases and unusual user behaviors. Identify potential challenges or limitations that might arise in different scenarios. This foresight can help in creating more robust acceptance criteria.

Step 7: Update regularly

Acceptance criteria should not be static. As the project evolves, so should the criteria. You should regularly review and adapt the criteria to ensure they remain relevant and aligned with the project’s progress (in accordance with the third pillar of Scrum). Incorporate feedback and lessons learned from each sprint to continuously improve and refine the criteria for better alignment with project goals.

Scrum project management at RST Software

We are a software development company working with the Scrum methodology. We specialize in React Native development, and have extensive market experience in delivering location-aware products such as mobility solutions, and an extensive portfolio of bespoke solutions that includes marketplace platforms, chat application and video streaming services. If you’re interested in working with us, just contact us directly via this contact form and we’ll take it from here.