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.

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.

About the Author

Aaron Bjork is a Principal Program Manager at Microsoft working on Agile experiences and tooling within Team Foundation Server (TFS). Prior to joining TFS in 2008, Bjork worked as a software engineer and development lead in Visual Studio. He is passionate about Application Lifecycle Management solutions and has a strong desire to see teams improve their software engineering practices. Follow Bjork on his blog at blogs.msdn.com/aaronbjork.

comments powered by Disqus

Reader Comments:

Mon, Jul 18, 2011 Ishwar Nataraj Bangalore, India

Hi Aaron --> So basically the project plan defined for the project which one works on is the acceptance criteria of the project?? Also is there sort of a different acceptance criteria when it is sprint based?

Tue, Jul 12, 2011 Aaron Bjork Seattle

Thanks Tim. Good suggestion. I'll definitely cover acceptance criteria in detail in a later column.

Mon, Jul 4, 2011 Tim Ellison Richmond, VA

Thanks Aaron. One suggestion though since many folks have no idea what Acceptance Criteria is. Elaborate on what it might look like when manifested as part of a user story. As Marc mentioned, it is somewhat akin to traditional software requirements and it would be good for the readers to understand from your point of view how it differs. A quantifiable comparison between traditional requirements (the system shall..., when the user chooses the ... the system responds by ... ) and acceptance criteria (I can..., I cannot...) would demonstrate their power.

Thu, Jun 30, 2011 David NJ

Requirements are subject to interpretation. Acceptance tests are a way of making sure that both the dev team and the product owner have a common interpretation of those requirements. Over simplified example... Requirement: System displays number 8 on page. User clicks button. System displays half of 8. Acceptance test: When the user clicks the button the page will display 0, i.e. the bottom half of 8. If left to dev team interpretation alone ... it would likely have displayed 4. Armed with the Requirements and the Acceptance Tests it is likely that the system will behave properly the first time it is tested.

Thu, Jun 30, 2011 Marc

Amazing. What's the difference with requirements? My take: there is no difference, just different words. So after years of denying the obvious, namely that thorough and continuous requirement analysis is essential for successful software development whether it is incremental or not, we now suddenly realize it is true? Amazing!

Tue, Jun 28, 2011 Jon Hunter Boston

Good stuff Aaron. We started using acceptance criteria earlier this year and it's done exactly what you describe.

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.