scrum, sprint and testing process

If you were to organize into cross-functional teams, a good portion of this problem would be resolved.

Instead of requiring "Feature 1" to need multiple teams to complete, ensuring that each team has all of the necessary skills and allowing a single team to take "Feature 1" from concept through integration and delivery would reduce, if not eliminate, the hand-offs. Then, you wouldn't need to worry about scheduling the integration testing or final verification because the team would be able to do that as they complete and integrate the work.

Although there are cases where platform teams or complicated subsystem teams make sense, the general recommendation has been to align teams with value streams or end-to-end functions and slicing changes such that the team can complete valuable, end-to-end work each Sprint. Even if the change can't be done in one Sprint, the team can maintain the integrity of the Increment.

Thinking about your organizational structure will probably have much better results than looking at your process or tying to solve scheduling problems.

Have people chosen to self-organize along the lines you describe, or does it just reflect present organizational constraints and thinking?

Scrum is very good at highlighting structural impediments quickly, and the pressure will be on you, and the team, to change Scrum rather than the company itself. There's an organizational gravity to be overcome. If you give in to that pressure, any "agile change" will be molded to the organisation's current form and shape, and the expected improvement in outcomes will not be achieved.

So how would the people you mention choose to self-organize around the work at hand? Are they empowered to do so...and is self-organization a skill they may have to be further encouraged to learn?

I agree with @Thomas.  You describe a process that is very waterfall-like.  I visualize a Gantt chart with mutiple bars running simultaneous and then arrows protruding from the end of each into a 5th bar that is marked as Integration Test. What you are creating is a gate to production that every "feature" has to go through.  It makes me wonder what happens if the backend team makes a change that would impact the already completed UI?  Also wonder what the UI team would be doing if they have already completed their work on "feature A"?

You may be using terms from the Scrum framework but it does not seem that you are actually using the framework.  In Scrum there is a team of self-managed, self-organizing cross functional individuals that are focused on delivering value every Sprint.  An Increment is delivered every Sprint and the increment must be usable.  

I suggest that you read the Scrum Guide (https://scrumguides.org/index.html) to gain a better understanding of the framework.  Then as @Thomas suggests, focus more on the organizational structure that will make you successful.  The process will follow along as you organize to be more agile. 

Thank you all.  Appreciate for giving guidence.

I will go through the guide and will propose / talk to mgmt for the same.

Thanks Bhavesh