No option is fully correct.
Tell the PO that no one tells the dev team on how to turn the sprint
backlog into potentially releasable functionality. It is up to the Dev
team to meet their commitments.
This is only partially correct. Although it's true that it is solely up to the Development Team on how to turn Product Backlog Items into Increments of potentially releasable functionality, it's important to realize that Development Teams also do not commit to completing Product Backlog Items during a Sprint. Development Teams - really, everyone on a Scrum Team - commits "to achieving the goals of the Scrum Team". On a Sprint level, the goals of the Scrum Team are expressed in the form of a Sprint Goal. Therefore, it's safe to say that the Development Team commits to the Sprint Goal.
Coach the PO on complex software development and tell her that the
work (sprint backlog) emerges during sprint and so all the PBIs that
were forecasted for the sprint cannot be completed everytime.
This is also only partially correct. It's true that software development is a complex task and work may emerge during the Sprint. The entire Sprint does not need to be fully planned at Sprint Planning and it's likely that the Development Team will learn more and adjust the Sprint Backlog as the Sprint progresses. However, I would suggest that, over time, the team should get better at being able to forecast the amount of work that they can get done within a Sprint timebox. It may not happen 100% of the time, but if the team isn't getting better at expressing their confidence in achieving the Sprint Goal and completing the work at the Sprint Planning, that is a skill that may need to be developed.
Ruaidhrí Primrose's option is also partly correct:
This isn't just about coaching the PO, it's about coaching the dev
team to have the skills to communicate to the PO (and others) why
their selected Sprint Backlog is appropriate and sensible.
Not only should the Development Team make their Sprint Backlog transparent to stakeholders (including the Product Owner), but they should be able to communicate why the Sprint Backlog is in the state that it is in and why they are making the decisions that they are making. Often this should be in respect to the Sprint Goal.
However, I'd present yet another alternative. In addition to coaching the Development Team about managing their Sprint Backlog, I'd also suggest coaching the Product Owner in crafting a Sprint Goal. The Sprint Goal is the objective of the Sprint that can be met by implementing selected Product Backlog Items. However, I suggest to teams that the goal should not be to simply complete a set of items but the outcome of those items - the team may be able to fully or partially satisfy the goal without completing all of the Product Backlog Items selected for the Sprint. I also suggest that a team limit the number of Product Backlog Items that relate to the Sprint Goal - if the Sprint Goal requires implementation of more than 60-70% of the selected Product Backlog Items, there's not a lot of room for undiscovered work or unanticipated events before the team cannot meet the goal.
So, here are my recommendations on what to coach:
- Coach the Product Owner on the complexities and emergence in software development.
- Coach the Product Owner on developing a cohesive Sprint Goal. The Development Team may also need some guidance here, as crafting a Sprint Goal is a collaborative effort during Sprint Planning.
- Coach the Development Team on how to ensure their Sprint Backlog is transparent and how to explain or defend it to stakeholders, including the Product Owner.