Its not so much as estimation as a whole work style, but

Make it work -> Make it right -> Make it fast

is arguably the best way to go about things, then structure your work around that.

Ive done this with greenfield projects when I used to work for Amazon (while still ironically operating under scrum), and was able to get SD2-SD3 promo within 2 years (entering an an SD2).

In terms of planning work, you basically allocate people as necessary. The first part deals with a lot of unknowns, so estimation is pointless - basically everyone is on board in terms of getting software up and running and talking to other software.

Once you have that, making it right is a lot easier to estimate because you can do a lot more fine grained planning (like for example, a certain team member that worked on a feature can add all the correctness and unit testing way faster than someone who has not)

Then making it fast is basically just optimizations, which can be done by a subset of team members while the rest work on adding features (and adding features needs to be done in the same way - make the feature just work, make it correct for all use cases, and then make it optimal)