The Product Owner (PO) is responsible for all of the Product Backlog Items (PBI):

• The wording of the PBI
• Each ordering of PBI’s business value
• Each PBI’s Acceptance Criteria

The Development Team are responsible for estimating the size and complexity of each PBI; this will be done initially just before development work begins.

During the development Sprint Planning, the Team must select the NEXT highest value PBI to be attempted during the Sprint.

However, as time goes on, the PO and Development Team need to apply any lessons learned from development so far to ensure that the candidate PBI are sufficiently well described and sized (but see Scrum.org Myth 14); this ‘confirmation’ is done during Backlog Refinement during which the following questions are answered:

• Is the wording of the PBI sufficient for the Development Team to understand what is REQUIRED?
• Has anything occurred to warrant any changes to the PBI wording?
• Are the Acceptance Criteria for each PBI complete and understandable to the Development Team?
• Is the initial size and complexity estimate for each PBI still valid?
• Are all the candidate PBI sized adequately? – A PBI that cannot be completed in 1 Sprint is too big and must be decomposed
• Is the Product Backlog ordering still correct?

All of these criteria and others to suit a specific situation can be documented as a ‘Definition of Ready’ checklist.

There are a series of blogs that make interesting background reading: Product Backlog Refinement explained.  See also Grooming the Product Backlog

Techniques

• Run the Backlog Refining session as a facilitated workshop, timeboxed to 2 to 3 hours or 10% of the Development Team capacity for a 2-week upcoming Sprint (see Product Backlog Refinement: Make the Most of It) 
• Anybody presents feedback from released increments
• Ask the PO what the next Sprint Goal will be
• ‘Modified’ Planning Poker: 
• Each Development Team Member has ‘YES’ and ‘NO’ cards
• Show an element of a PBI and ask participants to select a card
• All participants show their cards at the same time
• Ask each ‘NO’ what information they need or have
• PBI wording – use ‘modified’ Planning Poker technique with 
• Acceptance Criteria – use ‘modified’ Planning Poker technique with Development Team members and PO
• Sizing – use ‘modified’ Planning Poker technique with Development Team members (see also Resizing a Backlog, Story Splitting Cheat Sheet and Elephant Carpaccio Exercise)
• Ordering:
• Ask PO if there are any business value changes that require the Product Backlog to be reordered
• Ask the Development Team members if any PBI changes introduce new dependencies
• Spikes – if the Development Team do not fully understand a PBI or unsure how it might be developed, they can choose to introduce a ‘Spike’ item to the next Sprint Backlog to do some research into the problem
• Behaviour Driven Development (BDD):

Also known as Specification by Example (SbE)

• An extension of Test Driven Development that requires the use of specialised development tools
• Uses structured language to automate production of some development artifacts

Although using BDD requires a toolset that might not be available, you can use the structured language to create PBI Acceptance Criteria:

• Given {some context}
• When {some action is carried out}
• Then {a particular set of observable CONSEQUENCES should happen}

An example:

• Given my bank account is in credit, and I made no withdrawals recently,
• When I ATTEMPT to withdraw an AMOUNT less than my card's limit,
• Then the withdrawal should complete without errors or warnings.