How to run a great user story or how to split it

Question

I’m new to this methodology, and I’m having a lot of problems with the following user story:

1 As store manager, I would like to register a product so that it can be sold.

And on the card details, I put some requirements like:

• The product name must be up to 50 characters long
• The product has a category
• The product has a cost price
• The product has a sales price
• etc....

However, this user story seems too big, because contemplates:

1. The creation of the user interface;
2. Creating the table in the database;
3. The creation of the product class;
4. The creation of the repository
5. The creation of a Factory;
6. Handling of possible errors (e.g., limiting the field to 50 characters, checking if the user has specified a category for the product, etc...)

It complicates me even more, that in this user story there are fields for cost price and profit margin, which generated me a new user story:

2 As a manager, I would like to be able to provide a cost price, so that from it I can calculate the profit and set the sale price

I know I could try to break the user story into smaller ones, but I think it would be incorrect something like:

As a manager, I would like there to be a screen to register products, so I can register products

As a manager, I would like there to be a space in the database, to store the products I create

How do I break this function? How do I split the tasks for the team? If I break the user story into smaller ones, I should delete the father that generated them?

Justification for the answer

For those who are interested, I will explain why I accepted this answer. I tried to do what @Rodrigo Guiotti said. The solution was this same, breaking the user story into smaller ones, I just needed to have a little bit of creativity as suggested. I broke into parts like: register...

1. basic data;
2. profit;
3. tax data;

That way I was able to divide the tasks well.

Answer 1

You know the remedy already in your question. You really need to divide the epics in a way that makes sense to you and your team. But the division you proposed does not help much and if you intend to define exactly how the solution will be, you will hardly be able to stay only with the user stories and go to Use Cases.

The main thing for a story to be divided is the total estimate to be more than one or two weeks of development. The list of things you suggested, it doesn’t seem like it would get that big, but unfortunately there’s no simple rule of breaking.

You’ll need creativity, especially at the beginning. Then you get the hang of it.

Start by asking your team how they would do this job, where they would start to develop and ask themselves if it’s not possible to break the story there.

To help, I’ll try to give you an example. Imagine how you’d like to divide the work into two people. That you think one person should do the graphical interface and another should do the database. In this case you could split and disassociate the database from the interface:

"As a manager, I want to have the registration of all products and their cost prices so that I can subsequently calculate the profit and set the sales price." - BD "As a manager, I want to be able to add products to the register using a screen, without needing command lines to reduce possible human failures and speed up work." - GUI "As a manager, I want to be able to visualize the registered products, calculate the profit and set the sales price on a screen to view the results in a simple way that I can communicate to other people in the company." - GUI

---

As for the last question, whether it is better to erase the story so as not to have repeated stories or not... It depends on your organization and for you to have better control of what was asked and actually accomplished, it is usually worth looking only at the daughter stories, since they are the ones that are being planned and developed.

But to find out if you attended the entire backlog, it makes sense to look at the parent stories, it may be that the split into several stories still doesn’t fully meet the original story and having the list of original stories to confirm that they met well can help. If they’re not responding well, the problem is still in the story division.

Answer 2

all good?

Excellent topic. But before thinking about dividing or not the story first is important to understand the real value of it. Toda User Story is composed by 3W - Who (whosoever), What (what) and Why (because). Since it is in Why that is the business value, what will actually generate value for the user.

So let’s think about your first story:

1 As store manager, I would like to register a product so that it can be sold.

Would it be that if I reach the end of my Sprint and deliver to my client a database table, for example.

Did this deliverable of ours generate value for my client? Now, will the end of a Sprint, the customer with a database table will get the product to be sold ?

Well, I probably wouldn’t. If I cannot generate value for my client with a fragment of history, it makes no sense to have that fragment, that is, the story As the store manager, I would like to register a product so that it can be sold. is the minimum viable of my delivery.

To understand better let’s think like this:

Your deliveries should have a vertical and not horizontal thinking, because it is thinking vertically, as in the image, that you will be delivering value to your customer.

When you come across how to analyze whether a User Story is good or not, think about the following technique. The concept of INVEST:

I Independent: its history is independent of others ?

N Negociable: your story is something negotiable with your client ?

V Valuable: your story generates value to your customer ?

And Estimable: your story is estimable ?

S Small: your story is small ?

T Testable: your story is testable ?

If your story meets the questions of the INVEST concept, you have a quality history. Being much more specific your story perfectly meets the concept.

However, I see that you are concerned about the various tasks that are needed to then complete and deliver User Story. This is natural, and if it’s too much, just take a story. With time and experience with this and other types of stories you and your team will gain speed and will deliver more and more.

Answer 3

A "User Story" can and should be divided when necessary. Respecting the INVEST concept mentioned by my colleague in the previous answer, I will try to illustrate in a very simple way:

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 do need to share it.

Do not confuse "User Story" with functional specification.

I suggest reading this article: http://blog.myscrumhalf.com/2011/10/user-stories-o-que-sao-como-usar/