[JohnAaronNelson]

There was a part of the article that discussed that you create tasks, not stories.

You can group the tasks into stories or milestones or iterations or epics.

In general, he’s saying you should always keep breaking down a task until it’s a 1, since 1s are easy to estimate.

The key part that may be missed is the “mob programming” or “pair programming” aspect where all the engineers on a team sit together and work through a story or milestones or epic to come up with a list one 1 point tasks.

Obviously this still can’t be done, so the only effective end solution is maximum pair/mob programming unless all tasks in an iteration are accounted for and broken down into easily understandable and estimable bits of work.

There is at least some truth to the notion that if you use mob programming, estimating becomes pointless.

[Zanfa]

> The key part that may be missed is the “mob programming” or “pair programming” aspect where all the engineers on a team sit together and work through a story or milestones or epic to come up with a list one 1 point tasks.

My issue with this has always been that once an issue is straightforward enough to estimate as a 1 point task, you could’ve implemented the task already during the estimation process. The unknown effort is almost never in the writing code part, but figuring out the complexities around business rules & externalities.

But this doesn’t fix the process, it just moves the variability of effort & time into a different part of the process.

[brightball]

I have actually always had the same feeling about 1 pointers, but in this case you're talking about a collection of small tasks that make up a larger feature.

The larger feature probably couldn't have been implemented during the estimation process, but a single isolated small task could have.