Have you ever heard someone in software development refer to a "user story"? It sounds like a fairy tale, but a user story is actually a integral part of development and product management. And many product managers are looking for the perfect user story template.
A user story (also known as a feature) is comprised of one or more sentences in the everyday or business language of the end user or user of a system. It captures what a user does or needs to do.
In the context of developing great software, user stories are the basis for defining the functions a system must provide and to facilitate requirements management.
In the most simple terms, a user story captures the who, the what, and the why of a requirement in a concise way.
User stories are a quick way to handle customer requirements. You can avoid tedious documentation or formalized requirements -- and push work forward without performing administrative tasks related to maintaining them. User stories allow product and development teams respond quickly, and to do so with less overhead.
A "theme" is a collection of related user stories. For example, a hospital registration system might have themes around patients, point of care, outpatient care, medical chart generation, and financial processing. Themes can be used organize user stories into releases -- or to group them so that sub-teams can work on them.
A simple structure for defining user stories can look something like this:
As a X, I want to achieve Y so that I get Z.
X is the user, Y is the thing they want to achieve, and Z is the value delivered by that thing. For example: As an avid golfer I want to see unbiased reviews of a public courses near a specific location so that I can decide where to hit the green when I travel.
The most useful way to validate a user story is through verbal communication. Conversations between the product team allow you to exchange information and collaborate to ensure that the correct requirements are expressed and understood by the entire team.
A user story also includes confirmation information. This information is communicated through conditions of satisfaction, or acceptance criteria that clarify the desired behavior.
The development team can use the info to better understand what to build. It also enables them to test that the user story has been built and implemented during the release in such a way that the end-product will achieve the desired outcome.
More complex feature templates can include a high-level outline (basic areas of the business that are impacted by the product or feature), functional-based layout (breaking a large product into discrete chunks of functionality), and questionnaire format (posing a series of questions to outline the features).
But for product managers or software developers looking for a simple and effective user story template, nothing beats the classic approach: As a x-person, I want to achieve y-thing so that I get z-value.