Lack of rigorous, well-defined Acceptance Criteria can lead to delays and even poorly built products which do not answer the need for which they were intended.
What are acceptance criteria and why are they important
- Acceptance criteria in a story are the definition of ‘done’ for the story.
- They are a formal list of requirements that describe a set of features, capabilities, conditions that meet the user’s needs as defined in the story.
- Acceptance criteria set the bounds for the story and the scope of the work the story entails.
- They are a key piece of communication between the user / client / product owner and the builder / developer.
- While they do not define the implementation details and ‘how’ the story must be built, the acceptance criteria define ‘what’ requirements must be met for the story to be considered ‘done’.
- This allows the development teams to design and build the user story with a clear idea of what must be built and what must be tested.
Acceptance criteria should define:
- current or pre-existing features / functions that will be used or are assumed to already be available if applicable
- change in any existing user action / behavior
- checks on the user actions that must pass
- negative scenarios
- appropriate error handling and alerting
- outcome of user action / behavior
- key performance / speed / metric for system performance as relevant
- functions / features that are not in scope if applicable
Who defines acceptance criteria:
Usually acceptance criteria are defined by consensus. Ideally the user behavior and system performance expectation, as perceived by a user, should be defined by the Product Manager. Additional standards that must be met for performance, tracking and internal system use may be defined by the Development and Operations teams as well.
What are effective acceptance criteria:
There are several ways to define acceptance criteria and depending upon the type of product and user story, different methods may be more relevant or easier to implement.
Before jumping into the actual methods that may be used to define acceptance criteria, the following points must be kept in mind:
- Anyone who reads the acceptance criteria should be able to understand them
- Must define ‘What’ must be done not ‘How’ it must be done
- Must always be from the user’s perspective
- Must be specific, clear, concise and testable
- Must be within the scope of the story
How to define effective acceptance criteria
- Scenario-based acceptance criteria define the user journey or user experience through describing various scenarios that the user will encounter and how the experience must be handled.
Example: A user has the choice of several options for choosing and customizing a widget that we build for them: The navigation paths that are possible and allowed should be detailed.
- A picklist of standard sizes of the product
- An option to create a custom size for certain features of the widget by going to a different page on the app or browser.
- Returning to the original screen with the customization saved.
- A choice of finishes.
- A choice of delivery options.
- A choice of shipping options.
- A payment method and transaction with confirmation.
- The acceptance criteria must detail which paths are valid, which paths are complete and what happens when a path is completed, or left incomplete.
- The user may be able to save some customization to their account or profile.
- The user may be able to share the customization to external parties or not etc.
- Rule based acceptance criteria usually list a set of criteria that must be met for the story to be ‘done’. These include display fields and branding colors / logos etc. , size, appearance and shapes of visual elements.
Example: A landing page for a first time or returning user, who is requested to create an account or login with existing account:
- The logos and standard branding colors for the page or app are displayed.
- Check for existing users with email or userid as the case may be.
- Checks for password requirements for strength.
- Checks for MFA rules.
- Checks for recovery options etc.
- Custom and hybrid Rules+Scenarios used together are, not surprisingly, the most common form of defining acceptance criteria for complex product features, where both Scenarios of user experience are defined along with specific Rules and additional testable descriptive requirements.
No one way of defining criteria is better than another, and the best way is usually the one that answers all questions that any reader of the story may have, be it from the product team, development team, executive sponsor or another product and project stakeholder.
What happens if acceptance criteria are not clear or missing:
Unclear acceptance criteria can cause many headaches and derailments in the product development process:
- User requirement may be met but not in the way intended by the product manager / or described in the product roadmap.
- Testing may be successfully completed but the feature does not meet the user’s needs.
- Rework may be needed or additional requirements may be created for fixing or changing older features affected by current change.
- Rework is needed as performance metrics are poor or not met.
- Error handling for negative scenarios is ambiguous or undefined.
- Extra features / functions may be built when not needed or prioritized.
- Potential for scope creep
- Additional spending of resources – time and money – to ‘fix’ the story
Kaiburr helps identify stories missing acceptance criteria like the example below –
With just 15 minutes of configuration, Kaiburr produces real time actionable insights on end-to-end software delivery with 350+ KPIs, 600+ best practices and AI/ML models. Kaiburr integrates with all the tools used by the enterprise Agile teams to collect the metadata and generates digital insights with a sophisticated next generation business rules engine.
Reach us at contact@kaiburr.com to get started with metrics driven continuous improvement in your organization.