Programming

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.