Well-Refined Backlog

Who does not want to have a well-refined backlog?
Unfortunately “well-refined” does not have a universally accepted definition. Neither it is a DIN standard. 

So, any team, any org can have its own interpretation of a “well-refined” backlog. 
Here is my interpretation of what I mean by “well-refined” backlog. It consists of 5 aspects.

1:  User Stories should/must be sliced. The thinner the slices, the better it is. 

2: PO should have a fair idea about the Value of each slice. Value as it would be perceived by the Market/Cust. Even though this is always an educated guess, a PO who knows the pulse of users/market will be able to take that educated guess. 

3: Eng folks should have a fair idea about the Cost (Effort) of each slice. A rough guesstimate is preferred rather than chasing the illusion of an Accurate Estimate. In fact, chasing this Accurate Estimate has some seriously damaging side effects.

4: PO should have a fair idea about the Acceptance Criteria of each slice. This will nudge the PO to be outward-focused.

5: PO should have a fair idea about whether this slice is needed now, or it can wait. Again, when PO is outward-focused, s/he can easily take a call on this. 

A well-refined backlog automatically helps the team to prioritize their work as per the RoI it will produce.

A well-refined backlog will help the team to radically reduce the "waste" since the team is encouraged to build, showcase, & seek feedback on slices, rather than shipping the entire User Story. 

A well-refined backlog will save a truckload of time that would have been spent on "accurately" estimating User Stories.
Since the team anyway would not be building the User Story in its entirety, it would be meaningless to estimate a User Story in its entirety.