Reconsidering User Stories
User stories, one of the most common agile techniques, are used by delivery teams to support their iterative planning efforts and are typically used to represent items in a backlog. Until recently there has been a general agreement about the form that user stories should take—usually some variation on a three-part template that identifies the role, the feature, and the reason for the stories.
Additionally, the characteristics of good stories have been described using a couple of different acronyms CCC and INVEST. These ideas are often used as "training wheels" to familiarize people new to agile with the basics of the approach and how it organizes work.
These ideas are helpful for a lot of delivery teams transitioning to agile, but they can also inadvertently reinforce behaviors associated with phase-based approaches in which team members rely heavily on requirements documentation. Most information on user stories found through a web search discusses how to write them, reinforcing the idea that user stories are the primary requirements artifact used in agile approaches.
However as systems engineer and author Tom Gilb discusses in this video, user stories by themselves are not sufficient to describe the problem and good characteristics of the solution.
The idea of INVEST also has its detractors, including agile practitioner Nader Talai who looked at INVEST and noted that those characteristics may not make sense when a team must frequently deliver value to stakeholders.
So how do delivery teams reconcile the value of user stories as planning tools without expecting them to be the end-all-and-be-all requirements artifact that they were never intended to be? The answer may be to go back to treating them as they were originally intended—a promise to hold a conversation.
Consultant and writer J.B. Rainsberger suggested a new template for user story cards to reinforce the idea that they are simply placeholders. Timo Bezjak, an agile development expert, further reinforces the importance of the conversation when he discourages teams from trying to write the perfect user story.
To address Tom Gilb's concern in the video—a concern shared by many in an enterprise setting—that some information needs to be written down to go along with the story, it may be helpful to use an approach where the delivery team creates a mock-up first and then identifies the stories that result from it.
User stories can be a very useful tool when used as a placeholder for planning purposes, which was their original intent. They should be used in addition to the other tools your delivery team finds helpful when giving value to your stakeholders.
If you use them properly and don't expect more out of them than what they were intended to provide, you will find user stories very effective.
