Acceptance Criteria for Non-Software Teams
Agile and Scrum are often thought of as software-specific processes that ‘tech people’ do. To be fair, it is stated in the title of the Agile Manifesto (agilemanifesto.org): “Manifesto for Agile Software Development.”
What if we change the term “software” and replace it with “solutions.” Does that open up a broader range of work outside of software teams? Do marketing teams deliver solutions? Human resource departments (think hiring and recruiting)? How about fundraising departments? Higher education? Event planning? These and other groups deliver solutions that can benefit from Agile by taking complex work, and breaking it into small, meaningful chunks to help teams execute and create value to their customers. "Teams" means all teams - including non-software teams.
However, these teams may not have been exposed to the Agile framework and therefore some of the concepts like acceptance criteria is not as clearly defined for non-software teams.
Let’s start with the components of a User Story
Components of a User Story:
- Story title
- Short descriptor of the type of work
- Written in user story format
- Acceptance criteria
Story format
- A User Story has a specific 3-part format that contains a Persona/User, Action and Value
Acceptance criteria refer to a set of predefined requirements that must be met to mark a user story complete
It helps to:
- Define the scope and reduce ambiguity: Acceptance Criteria defines the boundaries of user stories. They provide precise details on functionality that help the team understand whether the story is completed and works as expected.
- Acceptance criteria is a communication tool: Acceptance Criteria synchronize the visions of the Stakeholders and the Team Members so that everyone has a common understanding of the requirements. Team Members have full transparency and know exactly what kind of behavior a Feature or Story must demonstrate.
- Manage and set expectations: Acceptance Criteria specifies what exactly must be completed by the Team.
- Defending against scope creep mid-sprint: Acceptance Criteria helps prevent from additional requirements being added to the defined work.
Types of Acceptance Criteria
Verification List Acceptance Criteria
- Formatting your user story requirements as a checklist is a viable and most popular option. You simply work as a Team to define a list of pass/fail statements that the functionality must meet in order to be marked complete. I believe this format to be better suited for Stories.
Given/When/Then Acceptance Criteria
The Given/When/Then style of user story requirements is similar to the traditional formatting for user stories themselves. I believe this format to be better suited for Features.
- Scenario – the name for the behavior that will be described
- Given – the beginning state of the scenario
- When – specific action that the user makes
- Then – the outcome of the action in “When”
Examples of Acceptance Criteria for non-software teams
Here’s an example of Feature at a university in donor and alumni relations planning a large event with acceptance criteria in the Given/When/Then format.
Description
Event marketing materials will inform and inspire community members to attend the event and financially support the scholarship program.
Benefit Statement
Education that people will learn what is happening and will want to financially support the scholarship program.
Scenario – Attending an event to financially support a scholarship program
Given – The community members receives marketing materials
When – The community member decides to attend the event
Then – Then the community member registers for the event
Here’s an example of Story from the Event Marketing Materials for planning the large event.
Description
As a guest at the Event, I want to see a slideshow that includes photos of scholars, event details and sponsor logos so that I am informed and engaged during the event.
Acceptance Criteria
- Collect photos of scholars
- Collect lotos of sponsors
- Receive presentation copy (text) for slides from editorial team
- PowerPoint presentation design
- Sign-off/approval
Here’s an example of Feature of a human resources team onboarding new full-time employees using acceptance criteria in list format.
Descriptor
As a new team member I want to be able to demonstrate my knowledge so that I can continue to develop skills and reinforce learning
Value Statement
Team members who demonstrate learning and understanding are better positioned to be successful in their roles
Acceptance Criteria
- Benchmark training completed before checking for understanding
- Training assigned
- Training assessment results shared with leadership (might be a scheduled meeting)
- Feedback from leader provided through a scheduled meeting at monthly intervals
- As needed, additional learning opportunities identified
Here’s an example of Story from the onboarding new employees.
Descriptor
As a new team member I want to be able to demonstrate my knowledge so that I can continue to develop skills and reinforce learning by scheduling logistics
Acceptance Criteria
- Develop the ability to track training progress
- Develop training plans
- Schedule training as needed
Other acceptance criteria formats
Yep, you read that correctly. One-size-does-not-fit-all, especially with non-software teams. While most Features and/or User Stories can be covered with two formats mentioned above, your Team can invent their own acceptance criteria given it serve the purposes, is written clearly in plain English, and cannot be misinterpreted.
What else?
Generally speaking, the Product Owner has content authority of the Stories, however it is the responsibility of Team together to help define, refine and write acceptance criteria together.
Even if you’re a non-software Team, do not neglect the acceptance criteria because it solves multiple problems at once. They document customer and/or stakeholder expectations, provide a user perspective, clarify requirements, prevent ambiguity, and increase transparency.
Make sure to choose the format that you find works best for your Team or experiment with your own. Different types of User stories and Features may require different formats and testing the new ones that work for you is a good practice.
Questions?
Let us know where your organization is on their Agile expedition, and we'll set up a consultation to assess what your needs are. Strategy & transformation is PinnacleTek.