What is not a user story?

Question

I have a problem at work, where we just started using scrum as a development team. I am having some problems with user stories that are provided to us, as they do not seem to match my interpretation of user history.

Here is an actual example of the user stories we provided for this sprint:

• As a website user, I want to have a registration page so that I can register and provide my data.

• As a user-seller, I want to receive confirmation in the registration form in order to provide the correct information. (This applies to form validation)

• As a trading user, I want to support the registration so that all the questions that I have about the required details answer me. (This applies to tool tips in the form)

The first in my head is the user's story. The second two, apparently, are the traditional requirements of the first user story, and I think that they should probably be the criteria for accepting the first user story.

Another confusion I have in the last sprint we had:

• As a user, I want to be able to access the website.

• As a user, I want to be able to enter the site with the username.

The product owner says these are two different user stories that need to be tested separately.

My problem is that when creating test cases and eligibility criteria for the second two, this is difficult because they are so specific and so related to the first user story. It seems that we just put the traditional requirements on the card on the board and call it something else. I basically just want to know if I'm not wrong about this / why?

It just seems to me that we are currently just letting users create everything they want as user stories, rather than helping them filter them from requirements into correct user stories. I was told that we need to keep them separate for reporting, so that we can keep a log of everything that the user asks.

Answer 1

User stories focus on customer values .... Actual work is done through collaboration revolving around user history as a system of development progress .... To limit the scope, user stories have jointly developed eligibility criteria that determine when a user story meets the expectations of stakeholders . Often there are cases of testing developed as code (with development based on tests) or documented as code.

[Emphasis is mine.]

As a user, I want to be able to access the website.

As a user, I want to be able to enter the site with the username.

Since none of the client’s values ​​matter, nor user history.

You use application software to manage information, make decisions and (ultimately) take action. If the user's history does not contain any hint about what information, decision or action is taken, there is no client’s value , these are just technical passwords - implementation details that the client must endure in order to get to the interesting part of the application.

An input, in particular, has a client value of zero. This is a checkpoint that the IT center creates between customers and the valuable information they need to make decisions and take action. This is a security mechanism, and most people actually don't like security. Security is superimposed on the IT client. The most popular password (IIRC) is "aaaaaaaa". What for? Customers don't like security.

A detailed, microscopic login of user history may be a sign of an inability to see real value for the client.

---

It just seems to me that we are currently just letting users create whatever they want as user history

Good.

I was told that we need to keep them all separate for reporting, so that we can keep a log of everything that the user asks.

Not a bad plan, really.

The problem is to separate the "crap that the user said" from "things that make sense that we can build." It is very important that users can say whatever shit they want to say. It is a good thing to let them run.

Periodically (before each sprint) you give priority to the crap that the user said in several things that (1) you could build during the sprint, and (2) create the most significant and dramatic user value that you can create. Some stories will ignored. Some of them will have a low priority. Some of them will be combined, and some will be divided. Some things said by the user will be inconsistent. Some will be outright lies. Some of them will be incomplete. All is well. It so happened that the user said. Not divine directives from the lips of the gods directly to you.

This revised set of user stories controls the sprint. Now you are starting to collaborate with users to get details, write test cases, determine acceptance, etc. Etc.

As you run to delivery, users can continue to talk shit, which will be added to the backlog of unfulfilled user stories. It is very important that users can say whatever shit they want to say. It is a good thing to let them run.