User stories, a requirements format utilized in Agile software development, are typically formatted with the following template:
As a (type of user), I want (some goal), so that (some reason).
This template can be modified to suit a project’s need. In this post, we’ll show how user stories themselves can be broken down into tables and made more usable for agile projects.
We’ll utilize the following example for this post:
A large engineering consulting company concerned with employee retention and job satisfaction is building a new software tool that will automate the review process of all employees. All employees are subject to an annual review, but depending on their department and rank within the company, employees may be subject to additional reviews throughout the year. This system will replace a manual, informal review process.
Breaking Down User Stories
In this example, an individual user can interact with this system in a number of ways (an employee hoping to get promoted, an employee reviewing their supervisor during annual reviews, etc.) Because each conditional state of an employee will involve different user requirements, we’ll adjust the user story template above to include a user conditional statement:
As a (type of user), (with a conditional), I want (some goal), so that (some reason).
Let’s write a few user stories for the review process of an engineer who has just been hired into an entry level position with the company. Company policy requires a review after 90 days of being with the company, in order to evaluate the new hire for organizational fit.
As an HR Rep, who is authorized to initiate reviews for new employees, I want to be notified when new hires have reached their 90 day mark, so that I can initiate a 90-day review.
As an HR Rep, who has initiated a 90-day review, I want to notify the new hire of all of the requirements of the 90-day review, so they can begin to submit their evaluation in the system.
As an employee, who is under 90-day review, I want to create a login for the HR review system, so that I can log in to submit my 90-day evaluation.
As an employee, who is under 90-day review, I want to log in to the system, so that I can view the requirements for my 90-day evaluation.
As an employee, who is under 90-day review, I want to submit the names of two peers I have worked with since being hired, so that they can contribute to my 90-day review.
As an employee, selected to peer review a new hire, I want to be notified when I have been selected to review a new hire after 90 days, so that I can log in to the system and submit my evaluation.
You’ll notice in the above set of user stories, each fragment of the sentence is divided by commas. Writing user stories in this way makes breaking them down into a table very easy. For stories written in Excel, you can utilize the “text to columns” tool to break a story down into its parts.
[Select column of stories > Go to the Data tab in Excel > Click Text to Columns > select Delimited, separated by commas in the wizard to divide text between commas].
If we do so with the list of above user stories, our table looks like this:
Tracing User Stories
By breaking the user story down into its parts in a table like this, it becomes easy to filter stories to trace requirements back to models as appropriate, to ensure no requirements are missed. For example, we can filter the table of user stories by the “As..” column to focus on one user group at a time. You can view all of the user requirements from an employee’s perspective, view all of the conditional states that employees can undergo, and then trace these stories back to a Roles and Permissions Matrix to confirm all employee permissions are covered with user stories. We can also filter by the “I want…” column to group individual requirements into larger epic stories, or features. For example, you can sort by any “want” that includes a notification to ensure that all desired functionality is built in to the “notifications” feature.
This strategy is particularly helpful for projects that have a variety of user groups, user state transitions, and large number of requirements. Creating a table like this can help a huge document of user stories become more usable. They can be sorted and traced to other models, and can be viewed in a way that helps teams prioritize stories in the backlog and assign them to development sprints. Ultimately, you want to format your user stories in a way that makes them the most usable for a project; breaking them down into their parts can be an effective strategy for doing so.
