How to determine users stories?

4

An important process in software development is organizing what really needs to be developed and prioritizing what needs to be done first. From what I've seen, one strategy to do this is to use user stories.

What I have found quite difficult is to determine these user stories. Some people may even say, "This is very simple, just talk to the end user," but things are not so easy. There are cases where the end user does not want to collaborate at all, says he does not have time to be debating these things and he is still angry if we try to deepen the discussion about what needs to be done.

In addition, I am often in doubt as to the granularity of user stories and various other aspects. After all, it's not enough to use the process anyway, you have to use it in a way that is actually useful for development, in a right way.

What I have been looking for, in this case, is a process that allows us to build user stories in the best way. Since this is a fairly common procedure, which I see many developers using, I believe there must be a process, a recipe, to get the user stories right.

Before you say the question is based on opinions, I want to make it clear that I am not seeking opinion of what one or the other thinks is a better way. I do not deal here with the subjective part, but with the objective part based on experience alone. The right way to do it, which really works for a better development, a process that based on experience actually works and produces user stories that will be useful in the end.

In this case, is there a process that allows the user stories to be systematically obtained for software development?

    
asked by anonymous 26.12.2016 / 15:34

1 answer

1
The "User Story" is based on the concept of cards, that is, each "User Story" is written on a card containing the actor (who wants) the action (what he wants) and the functionality (what the result expected).

Imagine a card, the standard size of a business card. Does your "User Story" fit this card? If your answer was no, then you need to break it down into smaller ones.

Do not confuse "User Story" with functional specification.

On the difficulty of extracting the necessary information from the customer, this is the role of the PO (Product Owner), who certainly has experience as a systems / requirements analyst and has his means of "pulling the client's language". >

The Scrum methodology assumes that the team is pro-efficient, and this includes the stakeholders.

To develop a project with Scrum, the client must be aware of how this will occur and what role it will play during the course of the project. One of the pillars of Scrum is: Transparency.

If the client is not receptive to an agile methodology, you may need to look for other ways / processes to manage your project.

    
26.05.2017 / 22:33