PSI planning is coming up with objectives and committing to them with the business in agreement with Product Owners(PO), Marketing, architecture team, System testing team and the targeted customers. Product owner will pick the features from the backlog and assigns a business priority. The top software features will be presented to the team by product owner.
The most common problems that are encountered during PSI planning is the estimation part. Since the software features are very high level and the developers may not realize the depth of the problem by reading once, the teams end up committing to the features, however in reality the effort required is more. Again this depends on the maturity of the scrum team. If the features that are going to be implemented are of the similar kind that was executed by the scrum team in the past, probably the team is pretty confident on the estimation. It’s true that each sprint is time-boxed and the team need not worry if a particular feature is not completely implemented due to incorrect estimation done; but the PSI end goal will be to ship something that's working and the customers can use it. To improve on this hurdle, have a look at Estimation Accuracy.
Another problem is that some feature that is partially implemented that can be shown to the users. Or the feature is completely implemented but the supporting hardware is not yet available. In this scenario, the effort spent in implementing a particular feature holds good, however the partially implemented feature can be 'hidden' from showing up to the customers and unhide when the feature is fully functional. To avoid this, plan and anticipate all the problems that may occur to release a planned software feature as potentially shippable increment.
It may so happen that after fully planning the PSI, new tasks may pop in during sprint executions such as a critical customer issue which comes as a very high priority from the management. Taking up unplanned activities must be minimized as much as possible to smoothly execute the PSI. Otherwise very low priority objectives from the PSI can be moved to the backlog and new task can be taken up but this has to be on case by case basis and not a good practice any way. There is another problem if new, unplanned activities are taken up during the PSI, that is, other dependent teams also need re-planning such as System Testing team to test the planned task if that is impacting the systems.
Make the scrum team members aware of the features that are in the backlog. This is usually during "Backlog Grooming". By letting people know the work that the team is going to take up, allows teams to think about the tasks and realize the depth of the tasks before even planning and thus helps a great deal during PSI planning.
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” - http://scaledagileframework.com
