On this article we intend to answer 5 questions about US.
- WHAT is a US?
- WHY we need a US?
- HOW would you write US?
- WHO would write US?
- WHEN do we need US?
WHAT is a US?
The User Story is a description, in a common language, of specifics behaviors in a software system putting the end-user at the center of the conversation. It represents the smallest piece of a real customer value to be delivered.
The aim of the User Story, which is to articulate how a piece of work will deliver a particular value back to the end-user, also represents the conjunction ring between the user benefits, technical people and business in term of expected market outcome. Therefore, it is crucial to understand how a User Story can be written to be clear to all the people involved in.
A good User Story it’s written in non-technical language and it provides:
- context for the teams
- let the team define what benefits the product will bring to the target
- drive collaboration and creativity
Once a User Story is ready to go, the team should be able to get from there:
| How to provide it | |
|---|---|
|
WHY they are request to build a functionality (what’s the value they bring to the end-user) |
Nowadays the User Story is a real standard way to represent business opportunities, translated then in technical solution building a valid and solid product. The reason why this is such a common way in the software development environment is explained by it’s own benefits. It helps you to plan, track and delivery business value constantly without loosing focus on the end-user; since most of the time users identification along with their problems drive you on a tangible Product development. Moreover, working on small and deliverable items is the only way to remain flexible and adapt to the business and priority changes. |
|
WHAT is the exact expected outcome. |
The smallest deliverable of value for the real user [Usually a User Story contains Title, Description, Acceptance criteria and useful links]. A common template is: TITLEAs a <ROLE>   Basically this template defines a Persona performing an action to achieve a specific need E.g: AS A Foody people I WANT TO see all the available restaurants in my area SO THAT I can order the food I like the most DESCRIPTIONThis section is crucial because we have to give context in a clear way. Explaining how the Customer Journey is going to be impacted, describing some use cases to outline the behaviour and the user context. Having a foody customer which introducing their own address, then the application should be able to list all the restaurants available in their area for the delivery service. The options to filter restaurants by rating and cuisine type will help our users to find the perfect match for their own food desires External sources such as design, attachments or metrics to be tracked are part of the requirements to achieve the objective this section. ACCEPTANCE CRITERIAThe acceptance criteria represent the conditions to pass before reaching the full validation of the development. Ref to: “AS A Foody people I WANT TO see all the available restaurants in my area SO THAT I can order the food I like the most”. Here an example:
When the acceptance criteria are written along with the team, this is the perfect moment to understand the full functionality of the feature facilitating the development phase. |
WHY we need a US?
Nowadays the User Story is a real standard way to represent business opportunities, translated then in technical solution building a valid and solid product.
The reason why this is such a common way in the software environment is explained by it’s own benefits.
It helps you to plan, track and delivery business value constantly without loosing focus on the end-user; since most of the time users identification along with their problems drive you on a tangible Product development.
Moreover, working on small and deliverable items is the only way to remain flexible and adapt to the business and priority changes.
HOW would you write US?
The User Story represent a user issue and a problem to be solved. Once identified the type of user, need to explain what issue our development is going to solve for them. It’s important each user story describe a single action (more details about how to split User Story here) in order to guarantee the reason and the value to be achieved.
If you want to know more about best practices and pattern to use when you’re writing a certain story, please refers here.
WHO would write US?
The Product Owner is the one who writes it but it’s not uncommon to have a group of people contributing to the same User Story.
WHEN do we need US?
Since the User Story is a fragment of a Product plan, you can write it in every moment of the product life cycle development.
Conclusions
When all said and done, if you want you User Story to be understood by anyone involved in, make sure you’re focusing on a real and valuable end user problem and the way to fix it. Paying attention at the used language to be sure the message will be delivered in the proper way.
