Split tasks so they don't take more than a morning or a day.
If you want to know how much a big project will take, you count the tasks, multiply by the half days and there you go.
You can also get a good sense of your throughput when each story is roughly the same.
If a task takes longer or shorter, doesn't matter, it'll bring the throughput of the week down, and next time you're doing this sort of thing you'll likely split it. Just keep counting tasks.
With more sophisticated estimation you'll still get it wrong, so the point is to make the process of planning faster and simpler, since you won't get it right with a bunch of investment anyway.
That is sophisticated estimation. So in order to say a project will take a month, first you'd have to plan it in such detail to break into like 40 half day tasks? That's more detailed than most waterfall shops.
In practice I've reduced the time spent in planning sessions and gotten more reliable throughput quarter over quarter like this, but feel free to do whatever works for your team.
Is this similar to the "No Estimates" talk by Alan Holub[1]?
And that possible interpretation is assuming that "slowest" and "team performance" are even measuring the right thing and not accounting artifacts. (Does completing the same work in the same time get counted differently when it's tracked as two 3-hour tasks vs three 2-hour tasks vs 12 "no estimate" tasks?)