スクラムチームの分割を検討していますが、どういう点を考慮すればいいですか？

スクラムチームは10人程度までがよいとされています。これは人数の増加に伴ってコミュニケーションのオーバーヘッドが大きくなることが大きな理由です。したがって、10人を超える場合はスクラムチームの分割を検討することが一般的です。また、人数が10人を超えなくても、認知負荷の観点からスクラムチームを分割することもあります。

分割をするときには以下のような点について検討した上で、どのような形に分割するのかを判断してください。

1プロダクトにつきプロダクトバックログは1つになる。つまりチームを分割しても、どのプロダクトバックログアイテムをどちらのチームがやるのかを調整するためには、全員が集まったスプリントプランニングが結局必要になる
複数のチームが同一のコードベースを触ると問題が起こることが多い
明確に担当範囲（ドメイン）を設定すれば、認知負荷の問題は解決しやすい
さらに、それぞれの担当範囲をサービスとして独立させることで、同一箇所を触ることによる問題は回避しやすい。また、この場合はサービス自体を別プロダクトとして考え、別のプロダクトバックログを持たせることも可能になる
とはいえ、この場合は、チームの負荷が偏ったり、全体として見たときに本来重要なはずのことが後回しになったりする可能性がある
プロダクトの初期フェーズの場合は探索が多く、ソフトウェアの境界を見つけることは困難である。また無理に境界を作ると無駄なものばかりを作る可能性がある
チームを分割するときに、コンポーネントで分ける（サーバサイドチーム、フロントエンドチーム等）にすると、チーム間での依存関係や受け渡しが発生し、リードタイムが長くなる

なお、分割を検討するときは、事前に書籍『チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計』を読んでおくことをお勧めします。