Every day, product owners face the challenge of coming up with the correct acceptance criteria to help the team understand the story. During the acceptance testing, you almost never fail to hear from the team that the acceptance criteria were either not clear enough or not detailed enough. In situations where there are problems with the delivered output of the story, this argument is especially pronounced.
My challenge as a Scrum product owner has always been to convey to the team the concept that user stories are the starting point of a conversation. Mike Cohn succinctly states that "acceptance tests are expectations," and as such I consider them, at their most useful, "a best shot a product owner takes in describing the boundaries of the story with information available at that instant."
In such situations, product owners are no different from any enterprise managers who make decisions based on limited information at hand. Management texts propound that managers do not make optimized decisions for the problems they face; instead, they look for safe solutions. That is, they base their decision making on heuristics, including the principles of satisficing and bounded rationality.
The word satisficing was coined by Herbert Simon in 1956. Alistair Cockburn and Jim Highsmith explain it as "the point of diminishing returns" in their book Agile Software Development. They describe it as the place in Agile software development where a product or feature is "sufficient to purpose."
Normally in an Agile environment, there isn't enough time to evaluate all the possible scenarios and come up with a detailed list of acceptance criteria that will complete the story as a whole. The product owner usually has to come up with acceptance criteria that are good enough to move game forward, and the team has to take that and run with it.
How good are these acceptance criteria from the product owner? Well. . . . This can be answered if we understand bounded rationality, a term also coined by Herb Simon. Bounded rationality is the idea that, in decision making, the rationality of individuals is limited by the information they have at hand, the cognitive limitations of their minds, and the finite amount of time they have to make decisions.
So how does this work when a product owner is coming up with acceptance criteria? We can all agree that, at the outset, the product owner is operating with a limited amount of information. He or she begins conversations with the customer and stakeholders by looking for scenarios for the stories, thus beginning the search for the right acceptance criteria. But in reality, the list of criteria is likely to be far from exhaustive. The product owner and team will identify a limited list made up of the more conspicuous choices. These are the choices that are highly visible, easy to find. In most cases, they will represent familiar set of criteria and tried-and-true solutions.
Once this limited set of alternatives is identified, the product owner will begin reviewing them with the team. But the review won't be comprehensive, and the team won't carefully evaluate all the alternatives. Instead, the review will likely begin with alternatives that differ only to a relatively small degree from the choice currently in effect. Following familiar and well-worn paths, the team will continue to review alternatives only until the product owner identifies an alternative that is "good enough"熔ne that meets an acceptable level of performance. The set of alternatives that meets the "good enough" criterion ends the search. So the solution the product owner comes up with represents a satisficing choice rather than an optimal one.
In traditional development methodologies, these partial requirements would pose a problem. However, the beauty of Agile development is that "good enough" choices are more than sufficient to get the ball rolling. In Agile intermediate work, products aren't important as models of reality, nor do they have intrinsic value. They have value only inasmuch as they help the team make a move in the game. An intermediate work product is to be measured for sufficiency (Agile Software Development, A. Cockburn and J. Highsmith).
Is it sufficient to remind or inspire the involved group? Is it sufficient to allow the team to experiment with the problem to identify solutions? Is it sufficient to initiate conversations within the product team to look for adjacent possibilities?
This idea of "good enough" acceptance criteria has to be evangelized by the product owner so that the team will understand that user stories are "idea igniters," not the traditional software requirements that developers are used to receiving from project managers or business analysts. In my opinion, once this change in mindset occurs within the team, the issue of the presence of detailed acceptance criteria (or the lack thereof) won't matter.
1. Acceptance criteria need not constitute an exhaustive list; they should be sufficient to get the game moving forward.
2. Acceptance criteria are temporal in nature. That is, they help the team validate the story based on the functionality the product owner had in mind at a distant time in the past.
3. Because acceptance criteria are temporal artifacts, they add no intrinsic value to future deliveries.
4. As the Sprints progress, acceptance criteria become refined through each story iteration to create a workable product.
5. Acceptance criteria can never be complete, as they embody expectations that change over time.
Now揺ave fun writing user stories!