How To Write A Good User Story?
Tags: productivity, ux, webdev
Published: 2020-01-07 10:18:52

<p>If you want to know <a href="https://pagepro.co/blog/2019/12/11/what-are-user-stories-and-why-you-should-be-writing-them/">“What Are User Stories And Why You Should Be Writing Them”</a>, read the other article, but if you are already familiar with User Stories, it’s time to actually learn how to write a good one.</p>
`The most important thing is to look at the product (or a specific functionality) from the perspective of a person that will use, or experience it.`
<h2><b>User Story Formula</b></h2>
<img src="https://pagepro.co/blog/wp-content/uploads/2019/12/roman-mager-5mZ_M06Fc9g-unsplash.jpg" alt="equasion written on the big board" class="wp-image-2392"/>
<p>We can easily craft a short and simple formula that will represent the user’s mindflow:<br></p>
<h3>Based on a role:</h3>
"As a `role person` , I can `a goal` so that `why`"
<h3>Based on a class of user:</h3>
As a `particular class of user` , I want to `be able to perform/do something` so that `I get some form of value or benefit`
<p>Make no mistake. “Simple” is far away from “Easy”. The process itself requires solid behavioral insights and your absolute focus on the user’s expectations. </p>
<p>This formula will help you build very simple, yet effective User Stories for any kind of user.</p>
<p>Let’s give them an example for better understanding: </p>
`As a user, I want a camera icon in the chat write box to capture and send pictures so that I can click and share my pictures simultaneously with all my friends.`
<p>This way, you make it extremely clear and easy to understand for developers, what type of user is expecting what kind of outcome from a specific functionality or feature.</p>
<h2><b>Good practices </b></h2>
<p>How to make sure your User Story is well written? </p>
<p>Here are a few practices to follow: </p>
<ul><li><strong>Think like the User!</strong></li><li>Engage the whole team when writing a User Story (just make sure it won’t end up with the endless discussion and the idea pollution). </li><li>Start from Epics and break them into smaller User Stories.</li><li>Identify User Stories with numbers or letters. </li><li>Indicate how much time is needed for each Story. </li><li>Indicate priority.</li><li>Clarify User Stories from a technical point of view (do not include technical requirements in a story!).</li></ul>
<h2><b>Wrong practices</b></h2>
<p>Let’s flip the coin now. Make sure to do not:</p>
<ul><li>Use Epics for Tasks, or break them into substories.</li><li>Use the stories that were not approved.</li><li>Divide low priority Epics into user stories - it may be a waste of time.</li><li>Include technical requirements. </li></ul>
<h2><b>Acceptance Criteria<b></h2>
<img src="https://pagepro.co/blog/wp-content/uploads/2019/12/goodrecords.png" alt="light showing a good records" class="wp-image-2393"/>
<p>By definition, acceptance criteria are <em>“Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholders.”</em></p>
<p>In other words, when the user is getting some precondition and do some action then he expects a specific result. Acceptance criteria are all the results that should satisfy his expectations. </p>
<p>Let's consider that you are chatting with a friend on your phone. You should be able to capture a picture and after clicking on a picture, you should be able to add a caption to the image before sending it.</p>
<p>But what If there is a problem with starting your phone camera during that? In this case, Acceptance Criteria will be an error message like ‘Camera could not be started’, or else.</p>
<h2><b>What about technical requirements?</b></h2>
<img src="https://pagepro.co/blog/wp-content/uploads/2019/08/56770516_10156923608917870_4133732372577255424_n.jpg" alt="" class="wp-image-1098"/>
<p>It’s all beautiful, but at the end of the day, the developer needs to have a piece of the clear technical information he can follow. </p>
<p>Again, don’t mix Technical Requirements with User Stories. </p>
<p>They should be used together, to complement each other, not to substitute each other.</p>
<p>User Story should deliver a meaningful context to the Technical Requirements so that the developer can clearly understand the functionality from the user’s point of view.</p>
<p>Here’s another example: </p>
<h3>User Story: </h3>
`As a team member I will have my “Kudos to spend” balance renewed every month, so I can give them to other users.`
<h3>Technical Story: </h3>
`In order to renew the “Kudos to spend” balance, the CRON on the Heroku must be configured to start each first day on a month. An endpoint for starting reset points feature must be created.`
<h2><b>Summary</b></h2>
<p>To sum it all up using User Stories bring many advantages to the development process, as it is a simple way of clarifying the product’s goals and functionality.</p>
<p>This can significantly improve the collaboration of different parties - users, product owners, developers - and bring a lot of useful insights from each one of them. </p>
<p>Being clear is extremely important in the development process, as it saves a lot of time and money. </p>
<p>Done well, they can help you avoid hours of additional communication and put all the resources into the execution.</p>