- When doing estimate, should each part be estimated separately? How to calculate "total" estimate?
All the teams participate in the same Sprint Planning, discuss all the aspect of the User Story and fully estimate it.
You first need a reference User Story which has 1 Story Point. You discuss this User Story so that all the parts are understood. It may be:
"As a web user,
I want to reset my password,
So that I keep using my account"
It has design, frontend, backend work.
Then, you ask the Developers (design, frontend, backend) to give their estimates on how much more complex your story is, than the reference story. If it's just as complex as the reference User Story, then it gets 1SP.
The user story estimation contains all the work to get it "Done". All of it.
2.How to avoid spillover? If most of the tasks are entangled like this, it is possible that few tasks will be done-done, since the work is serial instead of being parallel
You need to practice iterative development, most notably the inspection and adaptation.
In your case:
This story has a three parts:
1.Login form design
2.Backend API implementation
3.Frontend implementation (with styles and connecting to backend)
During Product Backlog Refinement you come up with some initial drafts for the three parts and add them to the User Story. Then you have an imperfect User Story, but still one which has all the parts, so all the Developers can start working on it. The User Story is selected for a Sprint and further discussed during Sprint Planning. More details are added.
Then you start working on it.
Iteration no. 1:
Based on the User Story details, the frontend uses the draft design and expects some backend endpoints, mocks them. All the work is integrated on the development environment.
One-two days later, the Developers and the Product Owner have a look at it (literally, on the UI). This is inspection. And decide how to modify it further. Adaptation comes next.
Iteration no. 2:
The design is updated. The frontend updates it. The backend delivered some endpoints. The frontend removes some mocks and uses actual endpoints. This is adaptation.
One-two days later, it's feedback time, again. Somebody clicks the login button, it doesn't work. Is it frontend or backend fault? Backend. The design could use a different font. This is inspection.
Iteration no. 3
The backend fixes and delivers all endpoints. The design is updated with the new font. The frontend puts it all together.
One day later, it's feedback time, again. Now it looks good and works as expected. This is inspection.
Now you merge the stuff and deploy it to staging environment. The Product Owner can now show it to stakeholders for more feedback.
More iterations might happen until it's "Done".
It's not exact science, it's complex, but this is the flow of working and collaboration.
Because one part might be delivered slower than the others, you (the faster one) may switch to work on something else. You may even demand feedback on partial work (design and frontend with fully mocked backend).
These things can be smoothen out in the Sprint Retrospective. In a true cross-functional team, the frontend can do some design and the backend can do some frontend (and/or vice versa) so that all the Developers deliver at the same time and you don't have to wait on one another. It's all planning, expertise and capacity.
Separating the people by expertise doesn't help at all, it only makes things worse. It makes the feedback loops longer. So, while you may think the User Story is "Done", you actually haven't received (yet) some feedback which will make you update it again, as a "bug".
There's no splillover if you expect it. You should actually want this feedback ASAP to get "Done" with it. Obviously, if you think it's "Done" and some unexpected feedback comes, you need to put more work in it and have less time available for other User Stories or Bugs.
3.How to commit on something that is so uncertain (other people's work)?
Along with inspection and adaptation, transparency is the third Scrum Pillar. Just be honest and collaborate to deliver the common User Story, to achieve the common Sprint Goal. This is commitment.
In Scrum, commitment was changed to forecast because the former has bad implications on the quality of work.
After committing to deliver a list of Product Backlog Items, the Scrum Team, foremost the Product Owner and especially the stakeholders may feel that there is an obligation to actually deliver all of them at the end of the Sprint.