How to properly divide the development of a web project into a user story?

Question

Agile

We are trying to implement a flexible methodology for developing web projects in the team. Prior to that, we worked on the classic waterfall (Cascade model), but the projects drag on in time.
At the moment, the task has come to transfer a large project from one platform (asp.net) to another (php). And I had a question, how to properly approach the user-story of the project.
The project must go in any case through:

• interface development
  
• layout
  
• software part
  
• Admin panel
  
• API
  

Colleagues, I ask for your help :)
The principle of working on the methodology has developed completely, plugging it into the user story (although I may be wrong)

Answer 1

At one time, this book served for me (a couple of years ago) as a good introduction to the topic, I recommend it. I think you will find answers to most of your questions in it.
It should also be taken into account that all Agile methodologies require constant (and in my opinion more) involvement of the customer in the process, in comparison with traditional approaches. For example, in the place where I work now, with all my love for User Stories, Scrum, I perfectly understand that any attempts to implement them are doomed to failure - because. the customer does not need it, it is not interesting, not when. And to impose Agile just for the sake of developers to play around is not the best idea. They tried to implement different chips, but everything went to waste due to the low involvement of the customer in the process. Although we successfully use individual, purely technical Agile features in development: TDD, CI, refactoring, well, and many of XP in development take root well, the developers are satisfied. By the way, our platform is also php =)
At the same time, based on past projects, I can judge that when the customer is available on an ongoing basis and is interested in the process, work on Scrum may well be successful. So user stories can be successfully used as a universal tool for backlog formation.
In general, I described in my own words the principle "The customer is always there."
Another of the fundamental principles (in the same book, it is given a lot of attention, as far as I remember): interface decisions should be made as late as possible. Topics of layout and interface and should not be disclosed for as long as possible. Go from functional system requirements, not from interface prototypes! In general, I personally consider designing from a gui to be a great evil and a sign of a low competence of a business analyst, if the project is more complicated than a business card site, you should look towards DDD. Fowler seems to have a statement about good software design on the same topic (I reproduce from memory, I can be wrong both in accuracy and in the source):

Imagine that at the end of the project it turned out that the program should not have a web interface, as planned, but only a command line, for example, or a mobile application!
If such a change can be accepted, without changes in the core of the system, then the architecture is suitable.

Answer 2

As always and everywhere, people have not fully studied agile / scrum and post something ..
No where is it clearly stated that the customer should be involved in the process.
First of all, SCRUM is a management framework that allows you to streamline processes, establish communications and deliver increments iteratively.
What form your increment will look like is up to you personally. In the form of a user story, in the form of a checklist / idea / tasks / epics, etc.
If we are talking about real Agile Scrum, then we assemble a team, isolate it from everything except our project, and further along the methodology:
(there are only 2 simplest processes where you need a customer for 1-2 hours in 2 weeks. a typical mistake is to call him everywhere like this is taught at stupid trainings for $ 1000)
1. We collect Wishlist from the customer and shove it into the backlog
2. We gather and groom the backlog by splitting epics into small stories or even smaller epics
3. We do sprint clearing and split the backlog into tasks, evaluating everything one by one
4. We agree on the increment and what Definition of Done
5. We work iteration along the way, holding daily status rallies to synchronize statuses and identify problems early
6. Demonstrate what happened at the end, collect feedback from the customer and format the backlog, returning to it what is not ready and everything that did not fit into the sprint
7. We do a retrospective and make sure that we are digging in the right direction and do not do anything extra, or we add to the work processes what should be done
8. Return to point 1
I will add that the backlog can contain everything from epics, user stories and ending with individual tasks, bugs, etc.
When you start to estimate the cost and terms of the project under Agile/Scrum, you step on the same rake. If the customer does not know what he is going for, then this is not Agile.
Our clients are already with bumps and are ready to pay money without imagining the cost of the project as a whole, and even more so its timing. More than that, it's startups. On the experience of launches and failures of good projects. One of them is already in its 4th year on the market and raised 20 lam in the US and is now one of the most successful online stores in the US.
Initially, the customer had show-off money in his pocket and 2 people worked on the project - backend and ayos and dug and dug until they grew to a permanent team of 5 people (backend, frontend, aios, android, qa) who continuously work on the project and dig in sprints in sequence. And no one is chasing anyone. The customer bathes in the bubble

Answer 3

the right approach to setting the user story of the project

A user story - or user scenario - is a high-level description of a feature . It does not contain (or rather should not) any details on how exactly the feature will be implemented. That is, no references to the fact that "the user clicks on something", or there "the user sends a request to the API". Only business squeeze.
The main thing is to understand why you are doing this and how it differs from waterfall. Agile != scrum or kanban, you don't have to drive through user stories, etc. The point is to reduce the feedback loop . In order for the client to see the result, he waited not a couple of months, but a couple of weeks. So that features get into testing more than once a month, but at least once a week. Well, etc.
Well, I recommend watching the talk: Agile is Dead • Pragmatic Dave Thomas

Answer 4

"The project must go through anyway" by doing so, you already remove yourself from the agile methodology.
And then the user story is just small tasks, moreover, integral ones.
And these puzzles should have a business price.
For example, "add a function to the API" for business is many times more valuable than "Add animation to a button".

Answer 5

The project has already been implemented, with all user stories. Or are you going to add new features? The transfer is still a little different from the development of a new project (you already see the entire volume, the details are worked out, some can be used, etc.), I see no reason to describe the user story again.
The topic of layout and interface is not disclosed in this section. Apparently, the design is also new, perhaps the user story has really changed