Many people are familiar with Bill Wake's INVEST acronym when it comes to user stories. Even though I've heard a number of criticisms launched at conferences, from my experience it is still very popular in current teaching material.
Althought INVEST can be used to review user stories, when I look at the quality aspects of a process overall I would like to have a different approach. With user stories in each various incantations being very popular in the Agile world, I would therefore want to be able to review from an outsider's point of view, possibly that of a coach or consultant.
My friends Ashish Misra and Aditya Garg have come up with what I consider to be an excellent list [1]. I have deemed to name it the User Story Quality Factors:
Completeness: Any team or organisation will develop a way of capturing user stories. This might be internalised or published in a similar fashion to a Definition of Done. Therefore does te story have all the information it is supposed to have? Does it have traceability from previous documentation or discussions?
Consistency: The way the specification is formatted, the language used and the way the requirements are presented should be consistent throughout.
Ambiguity: Is it free of any ambiguous statements?
Specific: Is it free of generalised statements?
Realisable: Does the requirement make sense and is it possible? Has all of
the information been included in order to deliver the product?
Testable: If the user acceptance criteria is not testable it cannot be built with confidence.
Traceable: Who wants this requirement and why is it needed, what business strategy does it support?
Measurable: How are you going to measure if the requirements have actually been delivered and are operational to specification? Quantification applies to both user acceptance criteria (that which tell you that you can release) and success criteria (that which tells you that your release is a success in the market). If I don't see this I usually teach people the basic of Planguage - Name, Scale, Meter & Goal.
Acceptable: Is the use of calculations, language, logic and formulas correct?
Achievable: Is the user story achievable within an sprint (iteration-based) or a acceptable number of cadences (iteration-less)? If not, then consideration must be given to splitting the user story in to smaller units that still deliver value.
Independent: It is best if stories are independent. Sometimes this is not completly possible, thus one-way directional dependencies are acceptable. Circular and two-way dependencies are not allowed, otherwise prioritisation and planning problems will occur. The latter will also indicate that there are other issues within the context of a project or business value increment.
[1] By their own admission, Ashish & Adi would not declare full originality to the
idea, but rather that it has been a fusion of ideas, influenced by the
streams of time. Maybe a similar list already exists in another
publication. If anyone reads this and can point me to that, then please
do so - appropriate credit needs to be given.
