3 ms·

This kind of cheerleading is a big hit with the people who consume estimates... not so much with the slobs stuck producing them.

ramses0 3y ago
The slobs stuck producing them (aka: myself) then break down a project into: Project => Area(epic/feature) @ T-Shirt Size => ...you're done... 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. Inputs: XL @ [ 25 stories, 33 stories, 52 stories, ...etc... ] => Mean/Median/StdDev L @ [ 20 stories, 15 stories, 18 stories, ...etc... ] => Mean/Median/StdDev ...etc... ...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.

ramses0 3y ago

The slobs stuck producing them (aka: myself) then break down a project into: Project => Area(epic/feature) @ T-Shirt Size => ...you're done... 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. Inputs: XL @ [ 25 stories, 33 stories, 52 stories, ...etc... ] => Mean/Median/StdDev L @ [ 20 stories, 15 stories, 18 stories, ...etc... ] => Mean/Median/StdDev ...etc... ...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.