How to determine Stories users?

Asked

Viewed 113 times

4

An important process in software development is the organization of what really needs to be developed and the prioritization of what needs to be done first. As far as I have seen, one strategy to do this is to use Stories user.

What I have found quite difficult is to determine these user Stories. Some people might even say, "This is very simple, just talk to the end user," but things aren’t that easy. There are cases where the end user doesn’t want to collaborate at all, says he doesn’t have time to debate these things and still gets angry if we try to deepen the discussion on what needs to be done.

In addition, I often have doubts about the granularity of the Tories user and several other aspects. After all, it is not enough to use the process anyway, it is necessary to use in a way that is actually useful for development, in a certain way.

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

Before you say that the question is based on opinions, I want to make it clear that I am not seeking an opinion on 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 only. The right way to do, which actually contributes to a better development, a process that is based on the experience actually works and produces Stories user that will be useful in the end.

In this case, there is a process that allows the systematic obtaining of the Stories users for the development of a software?

  • 2

    If users who have knowledge of the domain do not make a point of participating in the survey/validation of the requirements complicates a lot. The way is to explain that the development based on divination costs very expensive and not the results ... the customer makes a point to buy/pay for something that does not even know what it does .... You also explain that not using software to solve the problem is the best solution.

  • 2

    I even started to answer, but the answer was... opinionated. : ) I think your question is important and fair. But it’s hard to answer. If there was an infallible recipe,. :/

  • About the user not collaborating, these cases usually result from misinformed stakeholders. They pay for what they believe to be useful, but they have never talked to their own users. I want to say that the problem is somewhat outside its scope (it is an intrinsically institutional problem), but nothing prevents you from updating your own Tories users to try to also serve as a communication facilitator. In fact, I believe that agile methods help in the sense that users tend to notice earlier when something is effectively good and improves an activity.

  • @rray "The way is to explain that development based on divination costs very expensive and not the results". Explain to whom? The guy who pays probably already knows it. The guy who works just wants to... work. I’m sure the problem there is communication, but I don’t think it’s between the client and the developer. :)

  • 1

    @Luizvieira, it is true, I think that this subject would be better to discuss with smaller questions, perhaps a little more objective. I’ve even been thinking about splitting this question into smaller ones with more specific points. That’s a subject I’ve never really felt comfortable with. What I’m currently trying to figure out is how to come out of scratch and get in an organized backlog. I don’t say formal, since I work alone but organized from the point of view of being clear what needs to be developed.

  • It is not an issue properly classified as software project (design software). Removing this tag will make it easier to locate issues.

Show 1 more comment

1 answer

1

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

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

Do not confuse "User Story" with functional specification.

About the difficulty of extracting the necessary information from the customer, this is the role of PO (Product Owner), which certainly has experience as a requirements/systems analyst and has its means of "pulling the language of the customer".

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

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

If the client is not receptive to an agile methodology, maybe you should look for other means/processes to manage your project.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.