The project is large enough, but according to the "agile development" methodology, it is necessary to split the project into sprints of 1-2 weeks each.
Each sprint should end with a completely working version of the product, albeit with very limited functionality. After each sprint, this functionality will become wider. Everything seems to be clear.
But something I got stuck with the beginning. As I begin to write down the task for the sprint in terms of functionality, I immediately understand that it doesn't even smell for two weeks. At least a month, or even two!
How is it usually done in studios working with this method?
Maybe throw the interface on a "piece of paper" and start with this (from the front-end)?
Or plunge headlong into the most difficult of the functional – and implement it?
Or just sit down and start thinking over the structure of the database? (but there is a danger that I will miss something important, and then redo the whole structure of the old one).
How do you build a kanban?
The main point of Scrum is to maximize feedback without distracting developers too much. For this, iterations are introduced. The essence of iteration is to obtain an increment – a usable increment of the product. Suitability for use (readiness) is the main criterion. Because only what can be used can give real, high-quality feedback.
Prototype – Gives feedback. The base scheme is not at all.
Note that Scrum is a methodology for teams of 5 to 9 people. You don't need it entirely.
There are no ready-made methodologies for one-person teams. Do it in the order that suits you best.
The only thing I would advise you (since you don't know at all what to grab onto) is to start not from the interface or the base. And with scheduling the main user story. Choose the most important of them, and implement one by one (adding tests , base and code as necessary).