Agile Tip #5 – Learn to Love Acceptance Criteria
Tip #5: Start to love and embrace acceptance criteria.
Ask 10 mature agile teams “How do you know when you’re ‘ done done ’?” and you’ll get the same answer from each one… get serious about writing acceptance criteria.
Acceptance criteria is the handshake between the product owner and the team on what “done done” really means. Until the acceptance criteria is met, the team isn’t done with the story. Period. However, the value of acceptance criteria only starts here. Acceptance criteria provides the stage for some of most meaningful conversations and interactions that can happen on an agile team.
On my own team we routinely have some of our best interactions as we start digging into the acceptance criteria for each story on our backlog. Inevitably we all start with our own ideas about what “done” means for a given story. However, as we begin to discuss the acceptance criteria presented by the product owner what ensues is a series of “ah-ha moments”. A shared understanding of the story begins to emerge. A comment one team member might elicit the following response from someone else… "Ah-ha, great point… I never thought of that.” Regardless of who is being enlightened, the power is in the fact that the product owner and the team are building together a shared understanding of what “done” means for each backlog item. And, this is happening before the team has written a single line of code… before any work has been done… before commitments have been made… and before the sprint has begun. By collaborating on acceptance criteria the team is minimizing risk and greatly increasing the chance of delivering successfully.
I don’t think it’s a coincidence that the first bullet in the Agile Manifesto states “… we have come to value individual and interactions over processes and tools”. Agile teams work together. And by working together, they create better software. Start learning to love acceptance criteria and see if your team isn’t more successful delivering software.
Comments
- Anonymous
July 09, 2010
Aaron, do you just write the Acceptance Criteria in the Description field, or do you represent them more formally, perhaps with Test Case work items? I would think that having some formal representation of the Acceptance Criteria that could be represented on a task board would be very helpful. Do you recommended this practice or have an alternative? - Anonymous
July 12, 2010
Both. I always start by detailing the Acceptance Criteria in the Description field as bulleted list - this happens before Sprint planning. During Sprint planning the Acceptance Criteria is often adjusted and modified as ashared understanding is built.During the sprint we then create Test Case work items to track the work invovled in ensuring the critieria is met. There isn't always a Test Case for every item however... it usually depends on the nature of the item in the Acceptance Criteria. - Anonymous
May 03, 2011
Could you share an example of "Acceptance Criteria" and how it evolved from the orignal authoring to its final state? - Anonymous
May 03, 2011
Regarding the sentence: "Regardless of who is being enlightened, the power is in the fact that the product owner and the team are building together a shared understanding of what “done” means for each backlog item."You don't state it, so I am not sure if the "shared understanding" results in an updated Acceptance Criteria that records this new state of enlightenment? I am afraid that the temptation to move ahead to coding might be too great, for the value of recording what is "already known" seems a waste of time to those on the team. - Anonymous
May 18, 2011
In what details should we write the acceptance criteria for a dialog or user control? Should we include the design of the dialog and its behavior step by step? - Anonymous
September 13, 2011
Hello,I have a question as how to handle a change in acceptance criteria with change in scenario/flow after end of storyExample,In previous story the flow of the my page was from login screen to add user page. The story was marked completed.After 3 stories, client demanded the flow to change from login page to View user page.So how to define acceptance criteria now?Should the acceptance criteria be edited in the old story? (I dont think this should be done as it hampers Agile rule of 'Done is done')orShould the acceptance criteria abt the old story should be updated in current story?orShould a new story be defined to incorporate the new changes in acceptance criteria?