views:

129

answers:

3

My understanding so far: (please correct me if I'm wrong)

  • Ideally, COS are specified early by the product owner in the Sprint planning, facilitating a conversation. They can be considered an abstract definition that will form the base of the Acceptance Criteria for the user story or the feature.
  • Acceptance Criteria are developed by the Team and validated by the Product Owner (with conversations assuring a mutual undertaking). They are developed anytime within the Sprint cycle. They could be used to guide and set the focus for automated testing.
  • Summarizing, we could say: COS ---> Acceptance Criteria ---> Suite of Acceptance Tests.

While this is sound from a theoretical point of view, I feel I need more details (ideally, a written example) to better grasp this concept.

A: 

I think in SCRUM these terms means the same:

  • Acceptance criteria (most common for user stories)
  • Definition of done
  • Conditions of Satisfaction (I think this comes from traditional project management like ITIL)

When we define user stories we always collect acceptance criteria from Product owner. User story doesn't exist unless you collect the acceptance criteria. Development team never defines them. It is responsibility of PO to define acceptance criteria. Acceptance criteria for user stories selected for the sprint should not change during the sprint. The reason is that team has commited to these user stories based on estimate which has been done for initial acceptance criteria. The user story is done only if it passes acceptance criteria test during the sprint.

Conclusion: For me acceptance criteria are conditions of satisfaction and boundary of user story (and conversation).

Example: As a customer I need to pay my order with credit card so that I can make online shopping. Acceptance criteria:

  • Visa and MasterCard are accepted

At this point we stated that Visa and MasterCard have to be supported but for example AMEX hasn't.

Ladislav Mrnka
+5  A: 

I personally refer to the way Mike Cohn defined CoS in Agile Estimating and Planning. Here is an excerpt from an online chapter (with an example):

Conditions of Satisfaction

Every project is initiated with a set of objectives. Your current project may be to create the world’s best word processor. Creating the world’s best word processor, however, will typically be only one objective for this project. There will almost certainly be additional objectives regarding schedule, budget, and quality. These objectives can be thought of as the the customer or product owner’s conditions of satisfaction — that is, the criteria that will be used to gauge the success of the project.

Way back when I was in high school and assigned to write a paper about a book such as Moby Dick, I would always ask the teacher how long the paper had to be. She’d respond something like “Five pages,” and then I knew her primary condition of satisfaction. There were, of course, a number of additional, unwritten conditions of satisfaction, such as that the paper would be well written, my own work, in English, and so on.

At the start of release planning, the team and product owner collaboratively explore the product owner’s conditions of satisfaction. These include the usual items—scope, schedule, budget, and quality—although agile teams typically prefer to treat quality as non-negotiable. The team and product owner look for ways to meet all of the conditions of satisfaction. The product owner may, for example, be equally satisfied with a release in five months that includes one set of user stories as with a release a month later that includes additional user stories.

Sometimes, however, all of the product owner’s conditions of satisfaction cannot be met. The team can build the world’s best word processor, but they cannot build it by next month. When no feasible solution can be found, the conditions of satisfaction must change. Because of this, release planning and exploration of the product owner’s conditions of satisfaction are highly iterative, as illustrated in Figure 3.2.

Conditions of satisfaction drive both release and iteration planning

Figure 3.2 Conditions of satisfaction drive both release and iteration planning.

Once a release plan covering approximately the next three to six months is established, it is used as input into the planning of the first iteration. Just as release planning began with consideration of the product owner’s conditions of satisfaction, so does iteration planning. For an iteration, the product owner’s conditions of satisfaction are typically the features she’d like developed next and some high-level tests about each feature.

As an example, consider a travel site that includes the user story “As a user, I want to be able to cancel a reservation.” In discussing this story with the product owner, the developers learn that her conditions of satisfaction for this story include

  • A user who cancels more than twenty-four hours in advance gets a complete refund.
  • A user who cancels less than twenty-four hours in advance is refunded all but a $25 cancellation fee.
  • A cancellation code is displayed on the site and is emailed to the user.

Like release planning, iteration planning is iterative. The product owner and the team discuss various ways of best meeting the conditions of satisfaction for the iteration.

Feedback loops are shown in Figure 3.2 from the resulting new product increment back into the conditions-of-satisfaction boxes at the start of both release and iteration planning. Based on their experience developing the product increment during the iteration, the team may have gained knowledge or experience that affects planning at one or more of these levels. Similarly, showing the product increment to existing or likely users may generate new knowledge that would cause changes to the plans. An agile team will incorporate these changes into their plans to the extent that they lead to a higher-value product.

To sum up, here is how I see and use the terms:

  • CoS capture the expectations of the PO and they exist at various levels (release, iteration, story).
  • At the story level, I consider CoS as part of the additional details captured through Conversation.
  • Acceptance Criteria is how the PO will confirm that a story has been implemented to its satisfaction (the Confirmation). They are a more formal definition of the CoS.

All this is very close to your understanding (although I ideally prefer the PO to provide the Acceptance Criteria rather than validating the ones developed by the team).

Resources

Pascal Thivent
+1 Now I know I have to read that book.
Ladislav Mrnka
@Ladislav It's a good one, I liked it.
Pascal Thivent
@Pascal Yes, Mike Cohn is good author. I read two books which he wrote: User stories applied and Succeeding with Agile.
Ladislav Mrnka
A: 

@Ladislav Actually, while I'm not sure there is much difference between acceptance criteria and CoS, definition of done is something a bit different. It is the validations that each story must pass in order to be considered complete; they are technical criteria, whereas acceptance criteria and CoS seem to be different variations of business acceptance criteria.

Example:

  • Acceptance Criteria: Visa and MasterCard are accepted.
  • Definition of Done: All stories must pass QA with no critical bugs.
morganpdx