4 Variations of User Stories Agile Project Managers Should Know

As an agile project manager, you may need to conduct requirements elicitation or work with a BA team that performs elicitation.  Either way, you will need some familiarity with the common forms of agile requirements.  As with all projects, requirements are an important element for success. 

Having the right requirements and having them understood by those doing the project work is critical.  In the "Dig for Requirements" chapter of my book, Accidental Agile Project Manager, I discuss what is considered to be the most basic and universal form of user stories:

As a <role>, I want <function or capability>, so that <benefit>.

Example: As a homeowner in California, I need earthquake insurance, so that I can afford to rebuild in the event of a disaster.

This is often referred to as a role-function-benefit story due to the structure.  These stories describe the functional requirements for many agile projects.  The non-functional requirements typically accompany the user story as confirmations (e.g., for the insurance policy,  under $400 per year and renewable annually).

There are other forms of user stories which can be used to highlight and put a focus on other aspects of the requirements.  For example, we might want to highlight the value or motivation of the requirements.  There are also other forms of requirements we may need to address items such as bug fixes and technical tasks which need to be completed, and these too may need a slightly different script for the story.

Here are 5 variations of user stories you may want to consider for improving the requirements for your agile projects:

1. Highlight the value.  Sometimes it is important to emphasize to the team the expected value of the capabilities they will be creating.  If this is the case, then the user story can be in the form:  In order to receive <value or benefit> as a <role>, I want <function or capability>.  A story in this form is also beneficial if you want to emphasize the importance of testing for the provided value to assure it becomes a part of the solution.  Our revised example might be "So that I can rebuild my home as a California homeowner living through a natural disaster, I need to have an earthquake insurance."
2. The 5Ws.  At times, more information may be helpful to narrow things down by including the 5Ws (who, what, when, where, and why).  The 5Ws can be incorporated into a user story as: As <who><when><where>, I want <function or capability>, because <why>.  Now our example story might be "As a homeowner in 2020 living in Southern California, I want earthquake insurance so that I can afford to rebuild in the event of an earthquake."
3. System or Technical Stories.  System stories are used to provide a focus on a process or task which may need to performed in a certain way, or other actions that must be taken as part of the development iteration. They may be a little less structured and perhaps contain an additional sentence or two to highlight some other aspects of the requirement.  One form the first sentence may take is: <Action verb><subject> so that <role> gets <value or benefit>.  An example of a system or technical story might be: Upgrade MS Project to the latest release so the project manager has access to the latest functionality for resources. Only the PM workstation will be upgraded for now.
4. Job Stories.  Job stories focus on motivation, rather than role.  They take the form of situation-motivation-outcome, and they may be scripted as: When <situation>, I want <capability or function> so that <value or benefit>.   An example is "When the resource plan is constructed, I want to upgrade MS Project to provide access to the latest features."

Any of these stories can be modified and shifted to emphasize or include what is most important for the requirements, and add other elements as necessary.  If the role of project manager is important for the job story, it could be modified to "When the resource plan is constructed by the project manager, I want to upgrade MS Project to provide access to the latest features."

As an agile project manager in a servant leadership position, it will be important to be familiar with these types of stories so you can develop better requirements or coach those creating the requirements to use these other story forms when there are benefits.