Acceptance Criteria: A Way To Clarify Intent

Do you struggle to communicate the intent of requirements to development teams? Is there frequently misunderstanding, no matter how clear you try to be in defining user stories?

Acceptance criteria are a useful tool to clarify intent. It is common practice to write a set of acceptance criteria for each user story. A set of acceptance criteria specifies the conditions the software must meet before it will be accepted as done.

In other words, they are assertions about behaviour together with clear descriptions stating how to decide whether each assertion passes or fails.

A good set of acceptance criteria can be readily translated into manual or automated test cases.

Acceptance criteria can be functional or non-functional. In both cases, you should state what the expected behaviour is, not how to implement the expected behaviour.

For non-functional requirements, there is no point repeating generic non-functional requirements, which should be negotiated with the team, documented for an entire product and applied equally to all user stories. Examples are target devices and minimum performance standards such as response times. However, any exceptions or departures from generic non-functional requirements should be captured as separate acceptance criteria.

Tips to write better acceptance criteria:

  • Every user story should have at least one acceptance criterion (if you cannot write down how to determine if the user story is accepted, how will you accept it?)
  • Each acceptance criterion should be independent (in testing terminology: atomic)
  • Acceptance criteria focus on the what (intent) not the how (implementation)
  • As product manager (/product owner), if you can, explain the user story to the team, then get the team to write acceptance criteria (reviewing the team’s proposed acceptance criteria is an effective way to check for shared understanding)

The Power of Clear Sprint Goals

What does a product owner really do?

According to the Scrum Guide 2017, a product owner:

  • Is responsible for maintaining the product backlog
  • Helps the  team decide which backlog items to add to each sprint plan
  • Accepts (or rejects) backlog items and features resulting from each sprint
  • Works with the team to refine (clarify, prioritize) the backlog

If a Product Owner follows the Scrum Guide to the letter and focuses on just the above tasks, will this really optimize value the team delivers? What’s missing?

Use sprint goals to communicate intent

The best research into human communication tells us that we understand each other better through the use of stories, and a particularly powerful storytelling technique is the use of metaphors. How is the relevant to the product owner role?

A list of backlog items – like a “to do” list – is a great way to break a goal into constituent, individually achievable pieces. But without knowing what the goal is, a list of backlog items is missing a key element. What’s missing is the intent. With a clear goal, we communicate intent. Just as a picture can be worth a thousand words, a statement of intent can bring meaning to many backlog items.

The purpose of having sprint goals is to focus the team on the desired outcome, as opposed to simply implementing a bunch of discrete user stories. It helps provide the team with the why, in addition to the what, and helps to focus sprint planning on what really matters to deliver the outcome. Developers are smart people. Knowing why they are working on a given set of tasks will help focus their intellectual efforts.

Good sprint goals help the team focus on what matters, and can help the team deal with uncertainty when the product owner is not present.

Sprint goals also help facilitate stakeholder communication. Imagine coming across an executive at the office water cooler and she asks you what the team is working on. If you rattle off a list of backlog items in the current sprint, their eyes will glaze over from the detail. If you can tell them a coherent sprint goal though, your story is told effectively in a sentence or two.

Having goals encourages everyone to “think before you act”.


Tips for better sprint goals

Sprint goals can be of different types, for example goals might be to deliver a feature (“get the widget ordering feature ready for release”) or to address a risk (“ensure system architecture delivers adequate system performance”). And a single sprint may have multiple goals.

A good sprint goal clearly specifies intent and is measurable.

Some good and bad sprint goals:

  • “Complete the 7 user stories pulled into the sprint plan from the product backlog” (BAD: Does not specify helpful intent)
  • “Improve widget XYZ” (Bad: Vague and not measurable)
  • “Customers can recalculate a site annual budget in less than 10 seconds” (GOOD: Specifies intent and is measurable)