Here's a simplified use case diagram of an online flight booking system:

As you can see, the diagram shows the goals that users have: an end customer wants to book a flight. The diagram does not show the steps to get to the goal, like searching for a flight.

Having such a high level use case diagram has benefits:

• It provides a big picture of the system functionality
• It helps developers and stakeholders to agree on the scope
• It can be used for long term, coarse grained planning

But use cases can also help with designing the structure of your product development organization.
An agile team should be able to deliver valuable software, as independent of other teams as possible. A use case is such a unit of value.

The use case Book flight is valuable on its own. It directly ties to the users' need to get from A to B. That's why it is a selling point for the software.

A typical application doesn't have more than 10 to 20 use cases. When agile teams are responsible for whole use cases that cut through the whole tech stack, the need for communicating with other teams is limited. That enables the teams to deliver value early and continuously.

But other factors may force a team to limit its responsibilities to parts of a use case. For example, the development capacity of a team may not be enough to develop a whole use case. Or the team doesn't have the necessary knowledge. Quality attributes may play a role as well.

Each organization needs to define its own criteria for distributing the work between the teams. And try it out in practice, to see if it works.