Estimate ALL the items!

Myth: All items on the Product Backlog need to be estimated
Variations:

• Upfront estimation
• Estimates are required for the PO to prioritize the backlog based on ROI
• An estimated Product Backlog is required for a Release forecast

Follow-up myths:

• Re-estimate frequently

Category: Backlog myths
Danger: Low

The basis of the myth

The Scrum guide says, "Product Backlog items have the attributes of a description, order, estimate and value."
Traditional project managers creating an upfront Work Breakdown Structure are used to attaching estimates to each piece of work early on in order to produce the Project Plan. So, the entire idea that the Product Backlog should be completely estimated upfront is a mix of project thinking and

Why is it a myth?

Again, read further: "Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process ..." - it's completely fine to add estimates at a later time. This, of course, means that it's completely fine if there are backlog items without estimate!

Assumption #1: All items will be delivered

Why do we need estimates about items that we will not deliver? Only when we are sure that an item will ever be delivered, it's estimate will be important. In turn, until we know that it will be delivered, the estimate is not important.

Assumption #2: There's value in the estimate
Estimation takes time. To justify investing this time, the estimate needs to have value. So, we assume that the generated estimate will actually be used for something. Estimate that deprecate before being used are waste.

Assumption #3: We need upfront information

A Product Backlog tends to consist of items that will be done in the near future and items that will not be done in the next few Sprints. How does the estimate about items that won't be worked on affect the plan?

Assumption #4: We know what we're up to

As the product develops over time, the basis on which a new feature is built also changes over time. Let's use this image: When you are standing on the beach, it will be difficult to estimate a skyscraper. Once you've built 20 houses of varying size, it will be much easier to estimate that skyscraper. Until we know enough about our product, many estimates are just haphazard guesswork.

Consequences

Tedium

Combined with a huge backlog, upfront estimation turns into a long, tedious meeting. As developers start to feel tired, they'll be very complacent in the estimation, reducing the accompanying discussion and thereby the accuracy of the estimate. After half a day of estimation, you might as well roll dice: Your estimates will be good for nothing.

Guesswork

Based on assumption #4, the accuracy of early estimates will be very low. How does a a probably-just-plain-wrong estimate actually add value? How likely is a plan based on guesswork better than a plan made without details?

Extra effort

When estimates are made way ahead of time, the backlog items will need additional attributes, such as "When was the estimate done, how likely is re-estimation needed" etc., adding extra effort with no value. Again, CRUFT increases, leading to a viscious circle consuming an ever-increasing amount of precious, limited time.

Re-Estimation

When estimates are outdated because of new information, they need to be re-estimated. However, this means that the original estimate had no impact on the final product: The previous estimate is waste. The more often we discover that an estimate becomes outdated, the more wasteful our estimation approach is.

Remedies

Question, "What do we need the estimates for?" and limit effort to the need.

Create awareness in the team and organization that new information invalidates previous estimates, and so the value of future estimates quickly approaches 0.

Keep "Just in Time" in mind for estimation as well. A Release spanning more than 3-4 Sprints is most likely subject to many changes, so do not even feel pressured to estimate every item for the Release. Create a crude approximation for the Release scope, a better approximation for the Sprint - and simply forget about the future until you get there.

Refinement may be used to estimate items that will be coming up in the next 1 or 2 Sprints to create a better Sprint Plan if estimates are needed and still missing.

Until you know whether an item will even be realized, do not waste time estimating it.