How to run a large user story or how to split it up

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 that 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 with the user stories and go to Use Cases.

The main thing for a story to be split is the total estimate staying in over a week or two of development. The list of things you suggested does not look like it would get that big, but unfortunately there is no simple rule to break.

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

Begin by asking your team how they would do this job, where they would start to develop, and wonder if it is not possible to break the story there.

To help, I'll try to give you an example. Imagine how you would 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 unlink 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 the need for command lines to reduce possible human faults and speed up the work." - GUI "As a manager, I want to be able to visualize the products registered, calculate the profit and set the sales price on a screen to visualize the results in a simple way and that can communicate to other people of the company." - GUI

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

But to know if you have answered the whole backlog, it makes sense to look at the parent stories, it may be that the division in several stories still does not fully meet the original story and have the list of original stories to confirm that they attended well may help . If they are not responding well, the problem is still in the division of stories.

All good?

Excellent topic. But before thinking about dividing or not the story first, it is important for us to understand the real value of it. All User Story is made up of 3W - Who , What and Why ). Being that in Why is the value of business, what will really generate value for the user.

So let's reflect on your first story:

  

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

If I reach the end of my Sprint and give my client a database table, for example.

Has this our deliverable generated value for my client? Now, is it that at the end of a Sprint, the customer with a database table will get the product to be sold?

Well, probably not. If I can not generate value for my client with a history snippet, it does not make sense to have this snippet, that is, the story As store manager, I would like to register a product so that it can be sold. is the least feasible of my delivery.

To understand better, let's think like this:

Your deliveries should have a vertical rather than a horizontal thinking, as you are 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 INVEST concept:

I Independent: Is your story independent of others?

N Negotiable: Is your story negotiable with your customer?

V Valuable: Does your story generate value for your customer?

E Estimable: Is your story estimable?

S Small: is your story small?

T Testable: is your story testable?

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

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

A "User Story" can and should be split up as needed. Respecting the INVEST concept mentioned by the colleague in the previous answer, I will try to exemplify very simply:

Imagine a card, the standard size of a business card. Does your "User Story" fit this card? If your answer was no, then you do have to split it up.

Do not confuse "User Story" with functional specification.

I suggest reading this article: link