A User Story Checklist

Sometimes it’s difficult to determine if something is a User Story or not.  Not everything a software team does is a User Story.

In my other article, User Story Basics , I talk about the definition of a User Story.  I will use that definition to make a checklist of characteristics a User Story must have.

  1. Does the story describe new or changed functionality in the system under development?
  2. Is the functionality primarily of value to a stakeholder playing a role other than the role of “developer on the development team for the system under development”?  Said another way, is the functionality primarily of value to a Non Development Team stakeholder?
  3. Is there a fairly unique written description of the story?  (This can be just a couple of words, like a title)
  4. Have conversations about the story, that clarify story details, taken place?
  5. Does the story have acceptance tests that convey and confirm when the functionality of the story is complete, correct, and present in the system under development?

If you cannot answer “Definitely, yes!” to all of the above 5 questions, then it is almost always… NOT a User Story.

With respect to Question #2, I tend to define ¨developer” fairly broadly, like Scrum does.  From the Scrum Guide: “[Development] Team members often have specialized skills, such as programming, quality control, business analysis, architecture, user interface design, or data base design…”.  On some development teams, people who play a role of developer also play a role of “product support member” for the system under development.  In this way, sometimes User Stories describe functionality that is important to someone doing production support.  Other than this one exception, though, functionality and features that are primarily of importance to developers are almost always not considered User Stories.  On the other hand, there is nothing wrong with a developer suggesting some functionality to a NDT Stakeholder, and/or convincing a NDT Stakeholder that some functionality will be primarily of value to that stakeholder.  If that stakeholder agrees, then you can re-classify that functionality as a User Story… so long as you can say “Yes” to all of the other questions above.

A question that often comes up is, “Should Fixing a bug be represented as a User Story?”  The answer is, it depends.  The only question we might have trouble answering “Yes” to is #2.  The first thing you should ask is this: What (already delivered) User Story Acceptance Test(or tests) fails due to this bug?  If you can’t point to one specific acceptance test, then it’s probably a missed acceptance test(meaning one was overlooked when the story was originally implemented) or a legacy bug(a bug introduced before you adopted User Stories), in which case, the bug should almost always be represented as a new User Story.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: