In August of 2003, Bill Wake used the INVEST acronym
to describe the characteristics of a good user story on the XP123 blog:
I (= Independent)
N (= Negotiable)
V (= Valuable)
E (= Estimable)
S (= Small)
T (= Testable)
I only intend to deal with the last letter above, the "T" for "testable." Bill says:
A good story is testable. Writing a story card carries an implicit promise: "I understand what I want well enough that I could write a test for it." Several teams have reported that by requiring customer tests before implementing a story, the team is more productive. "Testability" has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met. If a customer doesn't know how to test something, this may indicate that the story isn't clear enough, or that it doesn't reflect something valuable to them, or that the customer just needs help in testing.
For me, user stories are not "done" (or even ready for estimation) until proper acceptance criteria are in place. I don't intend to discuss what constitutes proper acceptance criteria here. For those interested in that separate topic, I've provided a link below to an article by Walter Jackson, "What Characteristics Make Good Agile Acceptance Criteria?
" My only intention here is to instead strongly emphasize the need for acceptance criteria before
assigning story points to a user story. I can't overemphasize just how crucial it is to have proper acceptance criteria in place before user stories are relatively sized using story points!
Bob Galen says that he normally looks for "three to five, but no more than eight crisply defined tests that are the conditions of acceptance for a user story." In my experience, if there are more than eight criteria that must be satisfied before an individual user story can be accepted (and is "done"), it might not be possible to complete that story in a single two-week sprint. Similarly, I sometimes find it nearly impossible to estimate story points for a user story without having the acceptance criteria in place. I've worked with teams that perform the relative sizing exercise (using story points) for a group of backlog stories before adding the necessary acceptance criteria. Then, when the acceptance criteria is added later, they discover that the story may in fact be too large to fit in a sprint and must be split (or they discover that the story was actually considerably smaller than estimated once the acceptance criteria is understood).
The practice of developing acceptance criteria for user stories after sizing them with story points can be costly and wasteful. My advice is to coach teams to properly define the acceptance criteria for a user story before sizing the story. It should be a standard practice that teams never size user stories without proper acceptance criteria already being in place.
Galen R. Scrum Product Ownership: Balancing Value from the Inside Out,
2013: Robert Galen and RGCC, LLC, Appendix A.