The zeroth rule of software estimating

I realized that before even the first rule of software estimating must come:

Know why you are estimating.

We take it for granted that software estimating is something we must do. For many people, this is obvious. But when we start talking about why we estimate, I see many different answers. Perhaps it is not so obvious after all.

Some of the answers I have heard:

1. To decide which work to do next.
2. To decide how many items to start working on in an iteration.
3. To decide how many people to hire.
4. To sync up long-lead work (e.g. marketing).
5. To evaluate and reward the performance of individuals.
6. To evaluate and reward the performance of teams.
7. To measure the impact of changes in process, tools, technical debt, etc.
8. As a lever to push people to work harder.

It's common to choose more than one. This can produce really wacky results.

Whatever your reasons are, it's worth understanding them deeply. Is that something you really need? Is this approach really going to give you that result? Are there other ways that are more effective?