How to set sprint goal with multiple deliverables

A sprint goal should be aligned to the product goal. 

For scaled scrum which utilises Nexus, the result of Nexus Sprint Planning is:

● a Nexus Sprint Goal that aligns with the Product Goal and describes the purpose that will be

achieved by the Nexus during the Sprint

● a Sprint Goal for each Scrum Team that aligns with the Nexus Sprint Goal

● a single Nexus Sprint Backlog that represents the work of the Nexus toward the Nexus Sprint

Goal and makes cross-team dependencies transparent

● A Sprint Backlog for each Scrum Team, which makes transparent the work they will do in

support of the Nexus Sprint Goal

Your Sprint Goal doesn't have to be inclusive of all of the Product Backlog Items selected for the Sprint. In fact, in my experience, it's normal for it to not be inclusive of all of the selected Product Backlog Items. Absent of more specific data regarding teams or organizations, my approach is to ensure that the Sprint Goal is associated with no more than about 70% of your selected Product Backlog Items. This maximizes the chances of the team consistently crafting goals that are realistic and achievable, and the regular ability to meet the goals helps to build the stakeholders' trust and confidence in the team.

Part of the purpose of the Sprint Goal is to help the team focus. If things start going wrong in the Sprint, it helps remind the team of what their commitment to their stakeholders is and gives them something to replan toward. Even if the full body of work isn't achieved, if they can meet their goal, they've delivered something valuable to stakeholders to move the product forward, closer to the Product Goal.

Now, if you have 2-3 things that are all equally important and you can't build a team focus on one of them, then that seems to be a broader problem with how the commitments are laid out. Perhaps the higher-level goals and plans are too aggressive for the team to consistently achieve. One of the fundamental principles of being agile is maintaining a sustainable pace, and it's likely that the aggressive commitments aren't sustainable in the long term.

We are working in scaled agile project.

I don't think you are. You need to have Scrum working well in your own team before you scale.

In that, usually our scrum team has multiple functionalities that are delivered in a sprint - which are planned according to Program Increment.

You should plan your Sprint to meet a Sprint Goal. The Product Goal ought to give a sense of direction over multiple Sprints. In Scrum, increments are the Done work provided in the course of Sprint execution.

So we were struggling to have a single sprint goal here.

Yes, it seems that the Sprint is being planned to serve another purpose.

For starters, have are clubbing 2-3 functionalities together as a sprint goal which are of separate flows.

Have the team members self-organized themselves around those separate functionalities and flows in the first place? Have they decided that it makes sense to work jointly as a team on them?

We are working in scaled agile project.

That is great but is the Scrum framework actually being used within the scaled agile project? A "scaled agile project" says nothing about the framework or methodology that you are using to scale or the basis on which you have established individual team productivity. Your answer falls in the documentation for the process/framework you are using.  For example, if this is SAFe or LeSS, there is very little chance that a Scrum related answer will help you.  Yes, they use some Scrum terms but that doesn't mean they are using the Scrum framework. @Ian Mitchell nails this point based upon some of the things you state. 

If I were to give an answer that relates to the Scrum framework, it would be almost identical to what @Thomas Owens stated.  Whether that will work within the processes/rules/framework that your organization is using to scaled agile is not something that any of us can know. 

Just wanted to confirm if this is the right way or if not what should be the right approach.

Even if we all knew for sure that Scrum is being used as described in the Scrum Guide, we can't give you this answer.  There is no "right way" or a "right approach".  We can all give you our opinions and experiences.  But the Scrum framework does not provide a "right" answer. 

Thomas Owens mentioned focus a couple of times.

That's one of the Scrum Values, along with courage, commitment, openness and respect.

Do people in the organization share these values? If so, putting emphasis on one main thing, and making the necessary choices to get everyone there, should be possible. It isn't necessarily easy, but it is possible.

Many great advices are mentioned here. My two cents would be to highlight that the fact that you join 2-3 functionalities into one spirit goal may not be bad, however you may have problem with putting enough effort into understanding why those functionalities are important to address together during this sprint? What kind of value they jointly offer that we want to create?

Consider this example for mobile banking app, let’s say that we take during planning such functionalities like:

• Ability to find nearby users via Bluetooth,
• Ability to transfer $ via phone number,
• Ability to send request for payment to a phone number

If we just simply glue such features together and say that it is our goal, that means nothing and serve no purpose. However if we put effort to understand why we want to focus on those features we may find for example that our goal is to “Enable our users to quickly transfer founds to each other with minimal need for filling recipient details”.

In context of such goal those features may be now understand better how they are in fact linked together, and as we know why we run a sprint and what are we striving for, each of this selected features are questionable and the team can make decisions thanks to focus on goal, not on features only. That enables them to find better ways to achieve it, for example they may decide to drop those Bluetooth feature and pursue NFC based one to simply touch phones and transfer founds.