Agile Advisor

Acceptance Criteria: Get Everyone on the Same Page

Microsoft's Aaron Bjork explores how to use acceptance criteria to get everyone on your team running the same play.

• By Aaron Bjork
• 06/28/2011

On any team, whether a professional sports team or a software team, success is achieved only when all team members are on the same page. When the quarterback of a football team drops back to throw a pass, he is depending on everyone on his team to do his part to run the right play. Linemen must execute the correct blocking scheme, and receivers must run precise routes. Success is achieved when everyone works together to run the same play. Now, consider the result if every team member ran a different play? Success would be highly unlikely.

Software teams are no different. When a team commits to completing a story, every member of the team must be on the same page. A lack of alignment from the start results in waste, rework and decreased morale. How do you go about ensuring that everyone on your team is running the same play? One tool commonly used by Agile teams is known as "acceptance criteria."

The Handshake
What are acceptance criteria? I often describe acceptance criteria as the handshake between the product owner and the team regarding the definition of "done." The acceptance criteria are a list of things a user will be able to do with the product after a story is implemented. When the acceptance criteria are met, the story is done. It is that simple.

Acceptance criteria do not reflect everything the team needs to do to implement a story. Specific and detailed tasks track that work. Instead, acceptance criteria record what a user will be able to accomplish with the software after the story is implemented. Think of the acceptance criteria as defining the finish line in a race. When a team has finished the work to satisfy the acceptance criteria, they have crossed the finish line.

The product owner on the team is responsible for writing acceptance. It should be specific and complete. Any story without acceptance criteria is not ready for implementation.

Shared Understanding
The value of acceptance criteria starts with the handshake, but doesn't end there. The actual acceptance criteria set the stage for some of richest conversations and interactions on the team. It provides the context for conversations leading to what I call a "shared understanding."

A football team uses a playbook to achieve alignment. Each play is designed, communicated and eventually executed. In much the same way, members of a software team need to be on the same page when tackling stories from the backlog. This starts with communicating what the team is going to build. What does success look like when a story from the backlog is complete? What will a user of the software be able to accomplish when a story is delivered?

For any story on the backlog, team members inevitably start with a unique understanding of what "done" looks like. This is natural and should be expected. Even with the simplest stories, individuals often start with widely different perspectives and ideas.

This starts to change though as the team digs into the acceptance criteria. A shared understanding of the story begins to emerge. A comment from one team member might elicit the following response from another: "Ah-ha, great point... I never thought of that."

Regardless of who is being enlightened, the power lies in the fact that the product owner and the team are together building a shared understanding of done. Everyone is getting on the same page.

During this process, the acceptance criteria are adjusted to reflect the new shared understanding. By the end, the team is aligned about what "done" looks like for each story. The team is now ready to run the play.

If your team is struggling to understand "done" or can't seem to identify the finish line, work with your product owner to write down a simple list of acceptance criteria for each story. You'll quickly build a shared understanding and get everyone on your team running the same play.