As much as I value estimating the product backlog, not every team needs to do it. And those who do estimate the items on their product backlog need to understand why they do it, not just how to do it. There are two reasons to estimate product backlog items.
First, estimating product backlog items allows the product owner to prioritize the product backlog. An estimate represents the cost of an item. Without knowing the cost of an item, a product owner cannot successfully prioritize. If I don't know the costs of various cars, I'm putting Ferrari right up at the top of the list of cars I'd like to buy. And I'll follow it with Lamborghini and Tesla. But, whoa, those cars are expensive. Once I learn the cost of them, I adjust my priorities.
A product owner can know how much he or she wants a product backlog item without knowing the cost. But to correctly prioritize items, the product owner will eventually need to know the cost.
The second reason to estimate is so long-term projections can be made about the project. If a boss, client, or customer wants to know when a team will finish a set of product backlog items, those product backlog items need to be estimated. Similarly, if a boss, client, or customer wants to know how much can be delivered in three months, approximately three months worth of items need to be estimated.
Some product owners don't need to prioritize beyond a very simple sequencing of the work. Other product owners can take good enough guesses at the estimates that they can prioritize without bothering the team to do so. In some companies there may be no need to say where a team will be in some number of months or how long a stack of items will take to deliver. In these cases, it's not necessary to estimate the product backlog items.
There can, however, be ancillary benefits to estimating. For example, being asked to estimate forces a team to think about the work before they do and there can be value to that. (There is, though, of course also a cost to asking the team to do this.)
Knowing the reasons why to estimate product backlog items can also help fix a very common problem I'm seeing more often: Estimating the product backlog at the right time. The product backlog needs to be estimated early enough that the product owner can either prioritize or answer the above questions about when or how much will be delivered.
Putting story points on product backlog items during sprint planning is simply too late for those benefits to accrue. There are other problems with assigning story points during sprint planning but assigning them that late does not allow the product owner to take advantage of the new information in time for the sprint being planned. It's as though you wait until I'm on the Ferrari lot before telling me, "By the way, these cars are expensive." That may be early enough to stop me from making an expensive purchase. But it's not early enough for me to quickly figure out which cars I really should be looking at.
If your product owner doesn't need the estimates in order to prioritize well and if no one is asking for multi-sprint predictions of what will or can be delivered, don't bother putting story points on your product backlog items. But, if your project can benefit from these estimates, apply them earlier than during sprint planning so the product owner has time to think about and act on the new information.
