The idea is it doesn’t matter what points you give something. What matters is that you are consistent with how you do figure it out, as then over time you will be able to get a velocity that you can use to predict the amount of work you can turn over. That’s how I see it anyway.

Story points are unique to the team that is doing the work. Basically, a 21 point story for me could be a 3 point story for you.

In of themselves, the points are not important. Just size the stories to some amount of points that is reasonable and then do a sprint. The objective is to get a sense of how much work can be done in a sprint, to help create forecasts of when work will be completed.

As a Scrum Master myself this isn’t a question anyone outside of your work flow can answer. I’ve worked at organizations where we expected people to complete 8 points of work per sprint, and some where we expected people to do 30. Additionally, from a pure philosophy stand point, points measure complexity/uncertainty not time needed to complete the task. As such, you should be both reducing the average number of points per feature and increasing your average velocity over time.

OK, semantics aside, here’s some useful advice: jira has free accounts for individuals (check with their licenses before you sell any work) and is obviously built for software development. You can also install addons like Clone Plus that will let you clone epics and the stories within them. I’d recommend making a shell epic that contains the maximum amount of work a project would take, then appropriately size, sequence, and relate all stories to each other. After you have that template epic you can clone it and all the relevant stories underneath, then using Jira dashboards put them in the order they need to be done and use your estimated weekly velocity to see what you can do. Then you’ll have a list of tasks, how many points they total, and a rough timeline of story delivery

What works for me is only estimate short term work.

100 points is an average of 5 points per day. I recommend limiting your estimates to maybe 3 points. Because even if you get 5 points of work done today… it probably won’t be 5 points spent on what you planned to work on when you start the day. You need to plan for the unexpected and 2 points per day, every day, sounds about right to me.

Also if you think a task is worth 2 points, but you’re going to start work on that task tomorrow… then it’s a total waste of time to spend 10 minutes estimating the task now. Between now and when you start on the task you might decide not to do it, or make changes to the scope that significantly increase (or reduce) the amount of work required. Stick to “I can get these tasks worth three points done today”. Also try to split your project up into tasks that are 1 or 2 points (personally, I’d adjust your point system as well… a “point” is worth 30 minute at my company… and aim for 5 hours per day).

When you’re doing long term plans - don’t get into specifics. That works for other industries but it does not work with ours - our work is inherently unpredictable.

Rather than calculating an amount of time required - my long term plans are deadlines for certain milestones such as “ship a minimal viable product for QA/Testing” or “Finish the model for X” or “Setup performance metrics”.

Figure out what your budget is (say, $200,000 - or 2,000 points if you prefer), then split that budget proportionally among each milestone. Maybe your “performance metrics” milestone gets 100 points. That does not mean you think it will be 100 points of work. It means 100 points is the amount of time you are capable of spending on it right now. Assume it will be very different when you actually start work on it - regularly adjust points as you progress through the project. Maybe something is finished ahead of schedule and you decide to allocate extra points to something that could benefit from more work. Or maybe (more likely?) you’re behind schedule and you decide to cut something from the to-do list (as in, move it to the backlog, or reduce the scope).

Discussions around how much a project will cost should be less about the work required and more about how much you and the customer are both willing to allocate to the project. And if it feels like it can’t be done within the budget, then you don’t go ahead (for that you need to rely on experience). If the budget is over the work required - there’s always more work you can do. You could spend ten years doing A/B testing of colors and font sizes if you have the budget for that. And you can also cut corners corners to reduce a 100 point task down to half a point. Be prepared to do that - because it’s the only way to ship projects on time and on budget. Locking yourself into a detailed scope ahead of time doesn’t allow enough room to compensate for unexpected challenges or mistakes or a critical worker’s kid getting sick, leaving them unable to work in the last week before your deadline - all of these things and more will happen on every long term project. Long term detailed plans are worthless. It’s a huge amount of work to create those plans and you won’t follow the plan anyway.

I’ve been at a bunch of companies that use those processes and at best they are like weather forecasting. You can figure out what season you are in, and you can predict the activity of the next few days, but beyond that they are imprecise to the point of uselessness. For freelancing you mostly have to have done such projects all-up already, so you know what you are getting into; and have an idea of what code is out there that you can re-use in your project.

Expect to take horrible beatings on schedules multiple times. And be willing to turn away proposals if you’re not comfortable with the timeframes and other issues. As a solo provider there is a limit to how much uncertainty you can absorb.