6

I am having trouble differentiating user stories and acceptance criteria.

An example on I saw elsewhere state -

User Story:
As a user of the library catalogue, I want advanced search options on the front page so that I can quickly and easily refine my search

Acceptance criteria:
- I can limit the search by format/type.
- I can delineate the search by date range.
- I can limit the search to publisher information such as title, author, subject, place, publisher and call number.

What I don't quite understand is how/why the items are acceptance criteria as opposed to a user story in their own right e.g. for last acceptance criteria, a user story could be: As a user of the library catalogue, I can limit the search to publisher information such as title, author, subject, place, publisher and call number

9

Yes, you can write that as a user story

What I don't quite understand is how/why the items are acceptance criteria as opposed to a user story in their own right

In the specific example you gave, I would say, yes you can write that as a user story. In fact, you may find that you can further break it down into even smaller stories. I personally prefer more granular stories, to the extent possible. So, the real question is where do you draw the line?

In order to get an answer to that question you should check the INVEST mnemonic created by Bill Wake.

You stop breaking it down further if it becomes a mere technical task without delivering value to the end user or is not testable.

Jeff Sutherland modified Bill Wake's mnemonic slightly: "I" as Immediately Actionable and "S" as Sized to fit (Max of ~50% of velocity).

4

The user story text provides the context and/or the headline of the functionality the team should deliver. The acceptance tests give guidance about the details of said headline and how the customer will accept them. The two of them together provide the whole deliverable. They can be in the same sentence, however it is easier to process information: context and criteria separately.

  • 1
    This answer is good because it recalls that the context of the user story covers the acceptance criteria as well. That context is more important than the acceptance criteria because it can inform scope decisions whereas acceptance criteria are hard and fast rules. The goal is to allow the user to "quickly and easily refine their search", not to limit the search by type per se. – kojiro Nov 4 '15 at 12:03
1

Thanks for putting up the question!

User Story gives the dev team the overall pictures. They can further break down the user story to smaller task to make it more digestible for other dev members to consume. There may be technical stories like for example :

"Indexing database to retrieve search results" which may be a story that is decomposed from the user story that the dev team needs to do but is not shown in the acceptance criteria.

The acceptance criteria ( i think this refers to Definition of done) more or less define the test cases that need to pass for the story to be completed. These test cases for my team in specific are what we use to define our test cases. If any of these test cases fail then we say that the task is not done.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.