User Story Templates
In it’s real essence, a User Story is the User’s Story - it’s the user’s perspective of what he wants. When we have that kind of a clarity, the next question would be, how would you frame the user story. The standard template goes thus.
As a <user>, I want <to do this>, so that <I can achieve this>
As a college registrar, I want to be able to connect a family member and a student quickly in the event of an emergency so that I don't have to search for the student while the family member gets more and more upset while waiting on the phone.
The purpose of a User story is to give a kind of human touch to the design process and make the designer think like the end user when defining something. This requirement is not a formal requirement. This is just a guiding principle which fits into the big picture of product development. But then, we have a problem here. Consider the famous diagram
Why does this happen? Because the mindset of the user and the mindset of the developer are out of sync with each other. Many have proposed alternatives to ensure such kind of a mismatch can be reduced -
The author Joe Natoli proposed this structure. This focuses on what happens if you don’t do this.
The <user> wants <function> to achieve the goal of <user goal>.
The current inability to do this is causing <adverse effect> for the organization.
Enabling users to do this would deliver <specific measurable value> to the organization.
Example:
The user wants register using a social media login to achieve the goal of quickly trying the demo with little effort.
The current inability to do this is causing potential customers to abandon the registration page.
Enabling users to do this would increase the number of prospective customer registrations and potentially increase sales.
Gherkin User Story template tries to help the developer by creating a chain of requirements.
Scenario— the behavior you’re going to describeGiven— the beginning state of the scenarioWhen— a specific action that the user takesThen— a testable outcome, usually caused by the action inWhenAnd— this continues any of the other three operations if necessary
Consider this user story.
As an admin, I am required to create a complicated password, so that my account is secure.
How do you write this in the Gherkin structure?
When setting a password (
Scenario),Giventhat I am an account admin,WhenI enter a password in the password field,ThenI should be warned of the password requirements,AndI should be allowed to make corrections right away,Thenthat I can create a secure account.
This is good. But, where’s the problem? It’s too verbose and oversimplified. When you try to frame a 100 user stories, you will end up getting confused over what you want to do.
On the other hand, Contra User Story Templates tell us what I don’t want.
As a <user type>, I do not want <a capability>, because it will hamper me in <achieving the goal in this way>.
There are other variants of this as well like the Jobs to be Done(JTBD) -
As a <customer identifier>, I want to <Increase/Decrease> the <what> of <whom> in <what> context
As a parent, I want to increase the safety of my child when they start driving for the first time.
This should satisfy the Customer Criteria.
Expected Result/A Mesaurable Unit/Context
That spots on the pan can be removed/as quickly as possible/when they are burned in
The concept of User Story makes one glaring mistake - it’s the user’s story. There is no need for the developer to know what the user wants. The translation of user requirement to a technical requirement is not the job of a developer, it’s the solution architect’s. The user doesn’t want a login page with a robust password. The user wants a website to login!! Other words, Value should be derived for a feature, not every single entity in the feature.
Saying that, the nearest I can see is Joe Natoli’s template which really helps the User Story Structure.
As a <user>, I want to <do this> but not <to do this> to <achieve this>. Not doing this will <cause this>. The end result should <look like this>.
I should be told what to do, what not to do, what do I get by doing this, what do I get by not doing this and how the end result should look like.
As a merchandiser I want to pay the supplier for his deliveries but not for his over deliveries to ensure supplier compliance. Not doing this will result in us paying extra to the supplier. The end result is that the supplier pays only for the stock he committed to deliver to us.
Verbose, workable, I don’t know but this is the information I want to see in any user requirement template.