スクラムにおいて、フロントアプリとサーバーアプリを1つのチームで開発するか、別々のチームで開発するかは、次のような要素に左右されます。

1つのチームで開発する場合

スクラムは小規模なクロスファンクショナルチーム（開発、テスト、デザインなど、必要なスキルを持つメンバーで構成されるチーム）で運営されることが理想です。このため、フロントエンドとバックエンドのスキルを持つメンバーが1つのチームで協力して開発を進めることが推奨される場合があります。

メリット

迅速なコミュニケーション:
- フロントエンドとバックエンドの開発者が同じチームにいるため、意思決定や問題解決が迅速に行われます。
- ユーザーストーリーに対する統一的な理解が得られ、仕様の変更や調整も柔軟に対応できます。
統合された視点での開発:
- フロントとバックエンドの機能がシームレスに統合されるため、チーム全体で共通の目標に向かって効率的に作業できます。
- 1つのチーム内でユーザー体験の全体像を把握しやすくなります。
継続的なデリバリー:
- チームがフロントエンドとバックエンドを統一して開発するため、スプリントの最後にリリース可能なインクリメントを一貫して提供できます。

デメリット

スキルの偏り:
- フロントエンドとバックエンドのスキルを持つメンバーが少ない場合、1つのチームでの開発は難しくなる可能性があります。
- 特定の領域にリソースが集中してしまい、作業が遅れるリスクがあります。
複雑なシステムには負荷:
- 大規模なシステムや複雑なアーキテクチャでは、すべての技術領域を1チームで対応することが難しくなることがあります。

フロントエンドとバックエンドを別々のチームで開発する場合

スクラムの基本的な原則は1つの小規模なチームがすべての作業を担うことですが、複雑なシステム開発においては、フロントエンドとバックエンドを別々のスクラムチームで開発する場合もあります。この場合、Scrum of Scrums（SoS）やScaled Scrumのような大規模開発の管理手法が使用されます。

メリット

専門性の活用:
- 各チームがフロントエンドまたはバックエンドに専念できるため、それぞれの領域での専門性が高まり、技術的な深みを追求できます。
- チーム内の技術的な問題に素早く対処でき、効率的に開発が進められます。
並行作業の効率化:
- フロントエンドとバックエンドが異なるチームで並行して進められるため、開発速度が上がる可能性があります。
- 大規模プロジェクトでは、依存関係が整理されて進捗管理がしやすくなります。

デメリット

コミュニケーションのコスト:
- フロントエンドとバックエンドが異なるチームに分かれることで、チーム間でのコミュニケーションが重要になります。情報の共有ミスや依存関係の管理に課題が生じることがあります。
- チーム間の連携を綿密に取らないと、フロントエンドとバックエンドで仕様が噛み合わない問題が発生する可能性があります。
スプリントの調整が必要:
- フロントエンドとバックエンドが別々のタイムラインで進む場合、スプリントの終了時にリリース可能なインクリメントを提供するために、調整が必要です。
- チーム間での調整や同期が求められます。

結論：スクラムにおける選択肢

小規模または中規模プロジェクトでは、1つのクロスファンクショナルチームがフロントエンドとバックエンドを担当することで、コミュニケーションや調整が容易になるため、これが推奨される場合が多いです。
大規模プロジェクトや高い専門性が求められる場合は、フロントエンドとバックエンドを別々のチームで開発し、Scrum of Scrums（SoS）などの大規模なプロジェクト管理方法でチーム間の調整を行うのが適切です。

それぞれのアプローチで重要なのは、チーム間のコミュニケーションと調整が効果的に行われるような仕組みを整えることです。