This is great, thank you. Another approach is to do forecasting based on historical throughput (eg tasks/day). Generally using "story points" or other guesstimates turn out to be redundant if you have actual data (actual project by mostly the same team).

It takes into account stuff like n% of issues "blowing up" into subtasks, and some issues taking longer.

I read a great article on the subject which I've unfortunately misplaced - but the general gist is touched on in these:

"Forecasting software project’s completion date through Monte Carlo Simulation"

https://towardsdatascience.com/forecasting-software-projects...

"When will it be done? A data-driven approach to estimating project completion"

https://screenful.com/blog/when-will-it-be-done-a-data-drive...

"When Will It Be Done: Project Forecasting in Kanban(ize)" (product ad)

https://kanbanize.com/blog/project-forecasting/

"Project Forecaster"

https://github.com/rodrigozr/ProjectForecaster/wiki

And maybe this project is of interest:

https://microsoft.github.io/forecasting/

In general I'd like to be able to just point a tool at N "completed" GitHub projects, and a fresh one - and get a forecast that adjusts as issues are completed and added (possibly filtering on issue tags in completed and new project) - but I'm not aware of anything out of the box for that.

That was quite fascinating. Thanks!

Thanks for mentioning Screenful. Just wanted to comment on your remark:

"In general I'd like to be able to just point a tool at N "completed" GitHub projects, and a fresh one - and get a forecast that adjusts as issues are completed and added (possibly filtering on issue tags in completed and new project)"

That's exactly how our Forecasting chart works. You can import any number of repositories and projects (classic or new) and get a forecast for the remaining work. You can learn more about that chart from this guide: https://screenful.com/how-to/how-to-read-the-forecasting-cha...

Thank you for that link, you sum up the idea that sometimes counting total tasks works fine quite well:

> Will this work if my tasks aren’t all the same size?

> The short answer is yes, your work items don’t have to be the same size for this approach to work. The chances are that If you take 100 tasks in the past and compare those to a sample of 100 tasks in your current backlog, they will be the same size on average. Also, they are likely to be the same size on average regardless of how you measure (e.g. in story points or by some other estimate) or simply by task count.