A User Story Checklist

Scrumcrazy_header5.jpg
scrumcrazybtn.jpg

For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.


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 key 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.

Be sure you know who your key stakeholders are.

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 key stakeholder, and/or convincing a key 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 and put it on the Product Backlog... so long as you can say "Yes" to all of the other questions above.

If something fails Question #2 because there is no direct key stakeholder value, then the work to be completed is likely a task for the Sprint Backlog, or some work that needs to be represented on the The Dev Team Improvement Backlog. If the work is fairly small, you'll probably lean towards a Sprint Backlog task. If the work will be done later or is fairly large in size, then you'll probably lead towards the improvement backlog. This "non user story" work is often extremely important to accomplish, but it's not something that the key stakeholders can really appreciate, and it's not something that the Product Owner should have control over when ordering the backlog.

Should I use a User Story to represent bugs/defects in a system?

The short answer is "it depends." If it is a legacy or deferred bug, then yes, and it should end up on the Product Backlog(story points assigned). If it is any other bug, then it should end up on the Sprint Backlog(no story points assigned) and is not a User Story. See One way to handle Bugs and Production Support in Scrum for the longer answer.

Looking at our checklist above, the reason that legacy and deferred bugs are User Stories is because they have business value. At some point, the legacy/deferred bug was not fixed (deferred) because there were higher priority business value items to be implemented. This includes bugs that have existed for a really long time that no one knew about -- clearly the bug was not impacting the business in any meaningful way. In essence, the deferred bug fix became the equivalent of a deferred feature, and thus it now has business value attached to it.

Bugs where there was no business decision to defer are software defects. There is no business value in creating software defects. If anything, these kinds of defects detract from business value, which is really bad. These defects should be handled by putting them on the Sprint Backlog and fixing them immediately. Again, see more at the above link on handling bugs.

Other Good User Story Links edit




coaching(4).jpgForScrumMasters.jpgForProductOwners.jpgForScrumDevelopers.jpgPresentations.jpg