This checklist is for use on a ‘mature’ User Story, i.e. a User Story that has undergone some discussion and iteration.
Who creates User Stories? The Business Analyst
A User Story is usually in this format:
As a ROLE I want a FEATURE so that I get a BENEFIT. This is then checked against ACCEPTANCE CRITERIA to understand whether or not it is DONE.
The standard elements are shown in capital letters.
The Big Three Questions
A. Immediately after reading the User Story is it obvious what the User Story is about?
B. Does each element of the User Story add significant value and therefore avoids duplication or partial duplication of other elements?
C. Is it totally 100% free of ‘the how’/the solution?
The Top Ten Questions
1. Are there less than 6 questions making up the acceptance criteria?
2. Is the ROLE specific and does everyone on the project know what that role does?
3. Is the User Story less than 26 words and is the acceptance criteria less than 51 words?
4. Is there an area on the User Story for making important notes that may not be covered by the normal standard elements?
5. Do the elements of the User Story clearly correspond to a WHO, a WHAT and a WHY?
6. Is the User Story annotated to clearly show whether or not it is small (for working on) or large (in need of further decomposition, aka an Epic)
7. Are all of the acceptance criteria written without any form of pseudo-code (e.g. can I book a course in the next financial year, as opposed to, if course-date > this-fin-year AND < this-fin-year+2)
8. Has the User Story reached ‘its final state of why?’ i.e. has the question why? been asked enough times that we now have the real requirement and not a symptom or intermediate requirement.
...and finally, just to be on the safe side:
9. The WHO isn’t ‘user’ is it?
10. Make sure that there is nothing in the User Story that goes anything like ‘as a stock controller I want to control the stock so that the stock is controlled’?