One bit of advice I learned several years ago is to grow into this gradually.
Estimate what you can do in one month. Then set a date of 30 days away. Build your project for 30 days. When you get to the end of 30 days, stop.
Evaluate what you did in 30 days. DO NOT CONTINUE THAT PROJECT. It is done.
Based on your experience, estimate what you can do in one month. Then set another date for 30 days away. Build for 30 days. After 30 days, stop.
Again, evaluate what you did in 30 days. Do not continue that project. It is done.
Repeat this for about six months.
Now you will have a solid understanding of what you can do in a given amount of time. Now you can start yet another project. It is okay to plan this one a little bigger, maybe have aspirations for it to be four or six months big, but only plan out for the first month. Plan out that single month knowing what the last six months have taught you, then build for one month. Then build another one-month plan, build it out for a single month. Repeat.
For more than two years I was on a team that was building products for a major online store. Each programming team would launch a new set of online objects about every month, so we would have releases every two weeks. At any given time each programmer would have two projects in various states of completion. One might be in design while another is being polished. One might be in main development while the other is in final verification and testing. Since there was exactly one person of each discipline on the team, and we were responsible for our own estimates, we very quickly learned how much we could accomplish.
After a few months each of us were adept at estimating exactly how long a feature would take. At the end of two years, because were working with a stable code base doing variations on the same task every two weeks, we could typically estimate within a few hours how long a particular task would take.
It is the best way I know to learn how much you can accomplish in a given length of time.