Good acceptance criteria examples as a model

[Bil Simser]

Can anyone share a bit of the context they're working in and what they
consider good acceptance criteria to match up? I know the aspects of
good AC and (think) I've written some acceptable items in the past.
One of the current projects I'm on is just spinning up and the stories
and AC are atrosious (much like my spelling of that last word). When I
look at it I know it's wrong (contains implementation details, lists
off things not related to the goal of the story, etc.) and I'm looking
to find some examples to help the BAs understand as a model of what
could be better for the team.

Again, this is a subjective thing as everyone's example is different
and I don't want to get into a holy war about how you must do, or do
not, there is no model; but we can cite some good examples of TDD code
so why can we not do the same with BDD specs and AC here?

Thanks.

[Joe Ocampo]

This is an issue I always deal with when I introduce Agile into new
culture. Lower level concepts bleeding into Story definitions.

I am a huge proponent of the following story template.

As as {User or System role} I want {some feature} so that {some
statement that compliments the business value stream}

As you use that template it focuses customers to think about business
functionality rather then system functionality. (of course if you are
building a framework these constructs often blur)

Use screen sketches along with a domain model to drive out stories.
For instance if you are building health system and the screen has to
take in patient data. Patient data is usually an enormous task.
There are tons of data that has to be acquired dependent upon the
medical vertical you are supporting. Break the screen into tangible
chunks that can be delivered:

As a patient I want to enter in my basic information so that I can
works towards completing my initial screening.
ACC: Last Name should be required
ACC: First Name can not be longer then 12 char.
ACC: Phone number should use this format (###)-###-####

etc.

As as patient I want to enter my employment information so that I can
works towards completing my initial screening

This exercise continues until the the feature of completing the
initial screening is complete.

You have to have your team start to think in term of quick wins! Not
quick wins in the sense of "As a blah I need a label so that...", "As
a blah I need a text box..." those stories will demoralize a team
quickly.

I hope this makes sense.

JO

[Olof Bjarnason]

I read on a blog post yesterday of this story-template:

(Role): In order to (achieve some value) I want (some feature)

Example:

CAM User: In order to undo a mistaken disconnect, I want to be able to
connect a toolpath and a part.
(taken from my day job, I work in the machine control industry)

This template puts the WHY? (achieve some value) before the HOW? (some
feature), focusing on the most important aspect of the story first,
that is.

It also reads aloud as the statement from an actor in a play, which I
think is a communicative bonus ;)

Salesman: In order to sell more programs, I want the Forms to animate
when minimized.

My 2cc

2008/5/22 Joe Ocampo <agil...@gmail.com>:

[Bil Simser]

Joe,

Thanks, that's exactly the boost I was looking for. I like how you've
split up the patient information into chunks as it makes sense and
even though it just divides a single screen of data up, the goal
aligns with what I would think is completing a data entry screen.

I was struggling this morning as I came across a similar story which
is driving me batty trying to *fix* the AC so it makes more sense and
the developers can actually build from it. Here's the story (modified
to protect IP):

As an engineer I can add and modify attribute values for a given
widget so that specifications for that widget are captured.
ACC: only user can add / modify values of a widget at one time.
ACC: default values are displayed based on the projects defaults
ACC: mandatory fields must have values
ACC: user adding content can indicate that the information captured
for the widget is complete

I feel this has a few core problems ("add and modify" is the first
smell, trying to figure out how to not sink into the CRUD model when
specifying stories like this). The "so that" part is just asinine. The
first ACC isn't bad and I'm okay with it. The second ACC smells but
not sure what's wrong with it. The third ACC is okay, but rather
vague. I prefer the format you mention where fields are specified (but
other than breaking up the form, if possible, how do you deal with say
dynamic forms or dozens of fields?). The last ACC bothers me because
it almost smells like a different story and voilates SRP for this one
(e.g. Set widget information as complete or something).

Any additional tips would be appreciated here.

> > Thanks.- Hide quoted text -
>
> - Show quoted text -

[Morgan Persson]

As an engineer I can add and modify attribute values for a given
widget so that specifications for that widget are captured.
ACC: only user can add / modify values of a widget at one time.

I'm not sure I understand this one, does it mean that  some other role cannot add/modify widgets?

ACC: default values are displayed based on the projects defaults
ACC: mandatory fields must have values
ACC: user adding content can indicate that the information captured
for the widget is complete

Maybe this one should be split into into 2 acc. criterias?
How about:
1. user can indicate that the information captured for the widget is complete.
2. User can add content (is this the same as the first acc. criteria?)
or is it
Given a user adding content
When the user indicates the information for the widget as complete
Then the widget status should be set to complete
 

I feel this has a few core problems ("add and modify" is the first
smell, trying to figure out how to not sink into the CRUD model when
specifying stories like this). The "so that" part is just asinine. The
first ACC isn't bad and I'm okay with it. The second ACC smells but
not sure what's wrong with it. The third ACC is okay, but rather
vague. I prefer the format you mention where fields are specified (but
other than breaking up the form, if possible, how do you deal with say
dynamic forms or dozens of fields?).

I would add some examples. You dont have to cover every permutation but enough to feel confident that it works. Dimishing return and all that.

/Morgan

[Derick Bailey]

> As an engineer I can add and modify attribute values for a given
> widget so that specifications for that widget are captured.
> ACC: only user can add / modify values of a widget at one time.
> ACC: default values are displayed based on the projects defaults
> ACC: mandatory fields must have values
> ACC: user adding content can indicate that the information captured
> for the widget is complete
>

the AC you have listed is difficult to "fix" without knowing what this
system really is. So for this example, I'm going to make the claim
that this project is an Engineering Change Order system (a system that
allows engineers and line workers to request changes to existing
parts, including how a part is built, the documentation for building
it, peer reviews, approval processes, etc). Because I don't know
anything about your actual system, though, these examples are very
contrived and probably do not fit your needs very well.

I see an issue with your format for AC. Try using this template for a
while - it will often allow you to pull business value of the language
vs technical detail. "When <verb>, then <verb> [and <verb>, ...]".

Some times there are specific needs to put technical details in AC.
For example, the customer may require that you use a very specific
database table to retrieve a list of options, because that table is
the master list that is updated by another system. This type of AC may
not make sense to format in the When, Then template. For example, it
may be written "The XYZ list must always be loaded from the XYZ_Master
table".

Based on these assumptions and suggestions, here are my edits to your
AC's.

> ACC: only user can add / modify values of a widget at one time.

When creating a change request, lock the product for the person
requesting the change

> ACC: default values are displayed based on the projects defaults

When creating a change request, default the Change Type to "Assembly
Documentation", and the default the assigned engineer to the engineer
that owns the product line.

> ACC: mandatory fields must have values

When creating a change request, require that the following information
be provided: product's model #, change type, and a description of the
change that is requested.

> ACC: user adding content can indicate that the information captured for the widget is complete

in my contrived example, this may be a story in itself, not an AC. ...
As a Change Approval Engineer, i want to publish the product changes,
so that the line workers will have the latest information and the
change requester will know the changes are complete.



hope that helps.

-derick.

[Bil Simser]

Derrick,

Thanks for the replies as little things help in greater understanding.

For the example below (or any example) is there some kind of cutoff you do
when dealing with lots of fields to capture information? It's well and good
if there are 3 or 4 like you show, but what happens if there's 10? Or 20?
Someone had mentioned breaking the stories up into sections, but that
doesn't seem to align with delivering a story that following the independent
principle if I have to break up information capture into 3 chunks of 8
pieces of information each (even if you could logically break up the
information).

[Derick Bailey]

The first step I would take is to re-evaluate the functionality /
behavior that is being requested in the story. Is this truly a single
story? Do we absolutely need all 20 fields to be part of this one
story? Or should it be broken into multiple smaller stories? The
answer may very well be that it is a single story - we must have all
of these fields on this one story because that is the only place that
they make sense. If this is the case, then I would look for the
business terminology that can aggregate the fields into a smaller set
for the AC.

Let's take a shopping cart checkout for example - what do you think of
when you hear the words "Shipping Address" and "Billing Address"? I
think "name, house / apt #, street name, city, state, zipcode, etc.
etc." - there are at least 5 or 6 fields that can be aggregated into
this ubiquitous language element. So, when we write our AC for a
shopping cart checkout process, rather than listing out all 20 fields,
we could keep it simple by having a data dictionary that tells us what
fields are included in "Shipping Address" and then saying this in the
AC:

When checking out, require a shipping address and a billing address.
The shipping address and billing address may be the same.

Once you start aggregating the fields into the ubiquitous language
terms, you may find that your design, implementation, and overall
usability of the system are improving greatly because you can now see
some better workflow for the system you are creating - "Oh, shipping
and billing address may be the same. I'll give create a checkbox that
says 'Shipping address is the same as the billing address' so that the
checkout process is easier."

Hope that helps.

-derick.