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.
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?
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.
Could you share an example of "Acceptance Criteria" and how it evolved from the orignal authoring to its final state?
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.
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?
I have a question as how to handle a change in acceptance criteria with change in scenario/flow after end of story
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?
1. 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')
2. Should the acceptance criteria abt the old story should be updated in current story?
3. Should a new story be defined to incorporate the new changes in acceptance criteria?