Can PO somehow skip sprint planning if done good refinement prior

How much of the "detailed Sprint Planning" you are doing right now is actually Product Backlog refinement which has been left too late?

Product owner can delegate his responsibilities to other person-it can be hired business analyst, or proxy PO from Scrum team itself. It is not wise to delegate PO responsibilities to Scrum master, but one of teh developers can do.

It can be done if neccessary, but to avoid teh risk of being disconnected from the team PO should try attenting scrum events(except for daiy scrum) relatively often.

It is true that there are a lot of product management responsibilities, perhaps even more than a single person can handle on their own. However, the breadth of product management isn't causing the problems you are experiencing here.

It may not be very possible for him to attend the more detailed sprint planning that lasts 4-8 hours for potentially multiple teams , and potentially multiple products.

What do you mean by this? Do you mean that a Sprint Planning covers more than one product? The Product Owner is responsible for multiple products? The Scrum framework is built around some core ideas. One of those ideas is that each product has a Product Owner. Another idea is that a Scrum Team is dedicated to a single product. If these don't hold true for your organization, then you are likely going to struggle not only implementing Scrum, but many of the underlying Agile values and principles since most tend to be built on these foundational ideas.

If you have multiple teams working on a single product and each individual team is comfortable with Scrum, consider looking to frameworks like LeSS and Nexus that help you scale Scrum and coordinate refinement, Sprint Planning, Sprint Review, and Sprint Retrospective among multiple teams working on a single product. These frameworks can also help a singular Product Owner support multiple teams, again as long as they are working on a single product.

However some of the team can make smaller backlog refinement session with him prior that lasts 30-60 minutes where we do a proper decomposition of stories, prioritize it, define definitions of done, do initial estimates, etc.

There should be regular backlog refinement sessions, outside of Sprint Planning. Having well-refined work will greatly reduce the time spent in Sprint Planning. This doesn't mean that there won't be any refinement during the Sprint Planning, but reducing the refinement can reduce the overall length. Previously, you mentioned Sprint Planning taking 4-8 hours. In my experience, teams that invest appropriately in regular and effective refinement can conduct a Sprint Planning session for a 2-week Sprint in 60-90 minutes.

There are many ways to do refinement. I've seen it done many different ways. Some teams always do refinement as a whole team. Other teams may do it in small groups and get together to synchronize and come to a shared understanding. Some teams may do a lot of individual refinement and meet as a whole to develop their shared understanding. Find the best way of working for your team, but make sure that the work is very well refined going into Sprint Planning.

I suspect that making sure that whole Scrum Team - including the Product Owner - is focused on a single product and that refinement is more effective will solve the problems with your long refinement sessions and your Product Owner not having the time to support them.

Great points from Thomas.

If Product Owner is time challenged, you can consider their role in Sprint Planning and perhaps they don’t need to attend the entire event. 

• Product Owner ensures attendees are prepared to discuss most important backlog items and how they map to Product Goal. This could be supported through refinements leading up to Sprint Planning, but this wouldn’t take into account any adaptations coming out of Sprint Review.
• Product Owner proposes how the product could increase its value and utility in the Sprint.
• Whole Scrum Team comes up with a Sprint Goal
• Developers select PBIs to include in the Sprint. This may require discussion with Product Owner.
• How the work will be done is for the Developers to sort out and Product Owner isn’t really needed for this (unless questions come up).

With this in mind, Product Owner could attend only the first parts if they are short on time.

In my years of being a Scrum Master, across a number of teams, Sprint Planning has rarely taken more than 90 mins for a 2-week Sprint. Typically only the very first Sprint Planning event for a new team has taken longer than this or in one case where Sprint Review resulted in a major pivot for the product that resulted in creation and refinement of a number of new backlog items at Sprint Planning.

Thanks for ideas guys. 

What do you mean by this? Do you mean that a Sprint Planning covers more than one product? The Product Owner is responsible for multiple products? 

No the sprint planning would not cover multiple products.

But there could be multiple teams and products to cover outside of the sprint that PO has responsibilities to cover besides the regular PM role.

Previously, you mentioned Sprint Planning taking 4-8 hours. In my experience, teams that invest appropriately in regular and effective refinement can conduct a Sprint Planning session for a 2-week Sprint in 60-90 minutes.

By detailed sprint planning I am trying to consider decomposing stories into technical tasks to make it work and coordinating between the members. Planning around full embedded stack to make product increment is slightly more complicated to plan than a web page increment.

What I want to say with this is that I believe maximum allowed time should be done for planning. Scrum say maximum 2 hours per week of sprint so I would prefer to take advantage of it. If we do it fast great, but it still needs to be reserved in calendar.

However that is not compatible with PO time. Do not want us to need too do too much outside of sprint coordination and post planning dev meetings. Because like that you need to ensure someone facilitates coordination and the meetings. 

Self management of dev team is a myth. Its usually someone who is doing the initiative of coordinating the missed gaps, does not magically happen.

I would prefer that standups are only thing that is required for any further coordination.

Anyway based on input I think perhaps best is to just have good refinement being done before the planning so we can even skip PO on planning and focus on actually brainstorming on how to solve the stories. Less stories may fit then initially estimated on refinement but as long as they are prioritized should work ok. But I will think more on this before I go with proposal.

If you have multiple teams working on a single product and each individual team is comfortable with Scrum

Yes there is that complexity too, I was not talking about it at all. This is something else to consider and tackle.

One team has a team member needed but for few of the stories. That I figure we can just get him for several sprints and return.

Other team is well, smaller then main one and I am not sure you need scaled scrum for 2 teams.

Should be manageable. No need to overengineer project and create unnecessary overhead. Will just have to think on something that fits.

Obviously, one person cannot effectively cover all PO activities for large products.

Per Scrum Guide: "The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable"

It is about accountability, not responsibility. The Scrum Master needs to help the Product Owner to find techniques for effective Backlog management. That includes suggesting sharing the responsibilities and helping to get the individuals to share those with them. For example, advocating to the organization to hire someone if needed. Why not.

Jacek. I am not sure you can fully delegate responsibility of PO. The "above work" you quote are mostly talking about help with backlog refinement and prioritization.

To the topic at hand I do not see how you can have PO skip the topic of the post. Even though this is what I am trying to avoid.

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.

Self management of dev team is a myth. Its usually someone who is doing the initiative of coordinating the missed gaps, does not magically happen.

I beg to differ.  I have worked with teams at many companies that self-organize.  In the instances where there is "usually someone who is doing the initiative of coordinating ... " it is not because the teams needs an individual to do it, it is because that individual chooses to contribute that effort to the team.  Or it is because one individual feels that they should be the leader and asserts control. I do not mean to insult you, but your last response seemed a bit like you could fit into my second category.  And given that your only certification is the Professional Scrum Developer, I am going to assume that you are one of the Developers on the team. 

As a person that has fulfilled all of the responsibilities mentioned in the Scrum Guide, I firmly believe that self management is possible. But only if everyone on the team respects the skills and abilities of everyone else on the team.  Trust and respect are required in order for a group of people to self organize. 

To address your original question.  Yes, the individual fulfilling the responsibilities of the Product Owner could skip Sprint Planning if good refinement is done.  However, I would not recommend it.  That individual still has responsibility and accountability to ensure that the work being done during the Sprint is the work that best uses the Developer's time.  They are still responsible and accountable for interacting with stakeholders and other Product Owners.  They are still responsible and accountable for helping to remove impediments. There are activities done in Sprint Planning that impacts all of those responsibilities and accountabilities. 

As others have said, continuous refinement can help to shorten Sprint Planning.  Refinement can be done in many ways. I have worked with teams that did a large part of their refinement asynchronously.  They would spend time reviewing Product Backlog Items and leave comments on the item in whatever system they used to manage the Product Backlog.  Each person could read the others feedback and they could discuss it via comments. In the end, it helps to document the conversations and capture decisions. Other teams preferred to have scheduled sessions where the team would gather for a specific period of time and discuss items together.  In all of the teams that refined their Product Backlog outside of Sprint Planning, they were always able to complete Sprint Planning well under 2 hours.  My last team was able to plan a 2 week Sprint in less than 30 minutes. 

To wrap up, I will leave with this.  The Sprint Retrospective is a perfect event for discussing this type of thing with your team.  As a group, all of you can decide on an experiment that you will do during the next Sprint. At the next Sprint Retrospective, discuss how it went and make adaptions based upon the new information you have acquired. This is key to how a team can self organize and self manage. And it gives everyone a voice in the solutions which will create the sense of ownership that will encourage them to be successful.

Thanks for the feedback related to the topic.

However I disagree on the first topic and arguments from authority never gave much sway over me.

Yes developer is my main responsibility.

The way I see it is that self organization is a myth. If you do not make process on which most of self organization will be facilitated you will see self organization does not work. Therefore you have to organize the self organization... 

In case you notice somewhere inadequate process and thing still work, be sure someone is picking up the slack. It does not need to be one developer but can be multiple.

However does not need to guarantee to hold no matter how much respect you put. As they can just lose motivation and not do it, it could be just bad time of a year, who knows, and what you are having in the end is late project and lot of diluted responsibility.

I assume this is the reason you have all this events to facilitate the self organization. However to me word "facilitate" is quite much same as word "organize" in that case it is questionable how you are self organized if you got organized :)

Refinement and planning are distinct activities. The idea that one more refinement session obviates the need for the PO's participation in the planning doesn't make sense. The Scrum guide is pretty clear about the PO's role in the planning.

As others have already noted, the PO doesn't need to attend the whole meeting. The decomposition of stories into technical tasks, in particular, is of no interest to the PO.