Traditional agile suggests “sizing each task” (work estimated to be less than one sprint).
I’ve found that simply “counting each task” is more effective... instead of trying to estimate the difference in sizes, it's easier and more accurate to try to divide the work into similarly sized chunks. There may be "the usual" variation around delivery pace, but at the end it all averages out. Usually 5-10 chicken-nuggets-per-sprint (or 10-20 or whatever your pace is) gives you the "fine grained" velocity or pace that is useful for getting rough estimates in the medium-term.
Extraordinarily large "chicken nuggets" become clearly visible because they "take too long" and that's a conversation with the task owner about trying to keep sizing down, or a clue to break them down or add more people (and consequently- more tasks/stories).
For overall project size estimation, you can/should have more S/M/L/XL concepts, with effectively back-testing of estimated size to task breakdown count, or be able to state "in the last quarter, this team delivered 2XL, 4L, 3M, 8S".
Who knows the true size differential between the 17 delivered (well, maybe if you do further breakdown, and simple task counts you can...), but it's a starting point.
Team size may change, focus may vary, vacation varies, amount of non-productive (maintenance, planning, migration, compliance) work may change, but at least it starts giving you a starting point.
Finally, recognizing that variance should narrow over time. Driving from SF-to-NY may have an initial estimate of "1234", but if you get to Iowa and you're at 800, then you have a much better chance/estimate that the remainder will be another ~800.
Your variance should be smaller because you're estimating a smaller sized item (only half the work), and you're estimating (nay- duplicating!) actual observed delivery pace.
TL-DR: don't size stories, do size "epics/features", consistently track delivery, backtest based on previous data, refine estimates as you get closer, be able to estimate when you're "past" the 50% mark
If you can backtest/backport simply the COUNT of stories associated with enough epic/feature sizes, then you can forward-predict an arbitrary new "@ SIZE" to determine an approximate story-count.
...basically "the slobs producing estimates" are on the hook _MOSTLY_ and _ONLY_ for accurately accounting/tracking/submitting _CURRENT_ work (ie: put your stories in the sprint/board/backlog). The only other responsibility is being _CONSISTENT_ on submitting and tracking mostly "similar sized items" instead of "wildly varying sized items of indeterminate complexity.
If there are "large and wild" areas, they should be bumped up and "promoted" to an epic/feature rather than tracked as a sub-task on an existing epic/feature (talk to your manager/product-owner ;-).
It's relatively straightforward to maintain that "story hierarchy" of "Project => Feature/Epic => Story/Task". It's relatively straightforward to estimate Feature/Epic sizes (S/M/L/XL, with extra attention or avoidance of L/XL, strictly because there tends to be more variation on those sizes).
With relatively straightforward math tracking backwards four quarters (how many stories in total were closed by this team?), breaking down a "new project" or "new work" becomes more an exercise in "is this big or small?" rather than "what precise date or size is this particular piece of work."
For a high confidence interval, commit to _LESS_ Projects/Features than you'd done before (and you have StdDev to guide you on the probable upper and lower bounds), other than that, just prioritize at the Project/Feature level to get the most important or most valuable work scheduled ASAP.
Traditional agile suggests “sizing each task” (work estimated to be less than one sprint).
I’ve found that simply “counting each task” is more effective... instead of trying to estimate the difference in sizes, it's easier and more accurate to try to divide the work into similarly sized chunks. There may be "the usual" variation around delivery pace, but at the end it all averages out. Usually 5-10 chicken-nuggets-per-sprint (or 10-20 or whatever your pace is) gives you the "fine grained" velocity or pace that is useful for getting rough estimates in the medium-term.
Extraordinarily large "chicken nuggets" become clearly visible because they "take too long" and that's a conversation with the task owner about trying to keep sizing down, or a clue to break them down or add more people (and consequently- more tasks/stories).
For overall project size estimation, you can/should have more S/M/L/XL concepts, with effectively back-testing of estimated size to task breakdown count, or be able to state "in the last quarter, this team delivered 2XL, 4L, 3M, 8S".
Who knows the true size differential between the 17 delivered (well, maybe if you do further breakdown, and simple task counts you can...), but it's a starting point.
Team size may change, focus may vary, vacation varies, amount of non-productive (maintenance, planning, migration, compliance) work may change, but at least it starts giving you a starting point.
Finally, recognizing that variance should narrow over time. Driving from SF-to-NY may have an initial estimate of "1234", but if you get to Iowa and you're at 800, then you have a much better chance/estimate that the remainder will be another ~800.
Your variance should be smaller because you're estimating a smaller sized item (only half the work), and you're estimating (nay- duplicating!) actual observed delivery pace.
TL-DR: don't size stories, do size "epics/features", consistently track delivery, backtest based on previous data, refine estimates as you get closer, be able to estimate when you're "past" the 50% mark