It is common for daily work with your ERP to motivate suggestions for improvements to gain agility and automation. Now, it is very important how you transmit these requirements to your partner so as not to incur unnecessary development. In this sense, over the years we have encountered clients who, instead of expressing a need or a problem to be solved, try to provide a solution.
At TRIANGLE we work with SCRUM methodology and, for this reason, we recommend using user stories in these scenarios.
What are user stories?
User stories are short and simple descriptions of a functionality / feature / requirement told from the perspective of the user who wants the new capability.
They are usually a simple phrase or a short description of the functionality . Without going into details. This is so because if these user stories are not a priority, they are stored in the backlog and you will consider working on them in the future. The Product Owner (PO) and the team will prioritize the user stories to carry out based on the objectives that are sought to be achieved in each sprint.
With user stories we are able to focus on what is really a priority for the project without forgetting other needs.
How to write a good user story?
The first thing to keep in mind when writing a user story is the level of detail we want to get to. There is the possibility of writing a user story that covers a very large functionality or requirement. These user stories are known as “epic”. Of course, although the requirement is epic, we will have to divide it into several smaller user stories so that each one can be worked on individually.
We will not go into the detail of how we can add details to user stories, either by dividing the requirement or by adding satisfaction conditions. We will focus on how to write a good user story.
The fundamental thing you should always keep in mind is the following structure:
As a <user type>, I want <some target> so that <some reason>
[unordered_list style=’circle’ number_type=’circle_number’ animate=’no’ font_weight=”]
- As a: defines the role or person who will benefit from this functionality.
- I want : defines the action or objective to achieve. At this point it is essential that you describe what the user wants to do. As we have previously mentioned, you should not include the how. The how the partner will contribute with their know-how.
- So that : defines the reason why the user needs this change. Lets understand what the user is really looking for.
[/unordered_list]
For example, in the context of Dynamics NAV / Business Central we could say:
Like | I want | for
In this way, the partner who receives the request will be able to think about the best solution to respond to this need. As partners we are interested in understanding what the user’s need is, without having preconceptions to search for the best and most innovative solution.
On the other hand, to write a good user story we can follow the criteria we remember under the INVEST acronym . If the story does not meet one of these criteria, the team should consider reformulating it, or even leaving it off the list of requirements.
[unordered_list style=’circle’ number_type=’circle_number’ animate=’no’ font_weight=”]
- “ I ” – Independent : from all others. In order to facilitate prioritization.
- “ N ” – Negotiable: the end result comes from collaboration, not a closed contract.
- “ V ” – Valuable: it is essential that you add value to the user
- “ E ” – Estimable: regarding the supply of the requirement.
- “ S ” – Small: to be carried out in a sprint.
- “ T ” – Testable: it must be testable to validate that it meets the needs.
[/unordered_list]
What exists after writing a user story?
If we have written our user story we have already completed the first of 3 steps , specifically the one known as the Card. This requirement will form the backlog of ideas that the PO and the team will prioritize.
For this reason, the next step is the Conversation . When deciding to prioritize a user story, a conversation between PO and the team is necessary to clarify possible doubts.
Finally, Confirmation arrives, in which the PO will capture the criteria to be taken into account to ensure that the user story meets all expectations.
