アジャイル開発をしていく中で、バックログアイテムが大きすぎてイテレーションに収まらないといったケースがあります。このような時、イテレーションに収まる範囲で分割することで、成果物に対して早くフィードバックを得ることができます。
バックログアイテムの分割には「データの境界」「操作の境界」「制約」などの概念を利用することが一般的です。また、フィードバックを迅速にエルために、ユーザーストーリーの形式を保持したまま分割することが良いとされています。
しかし、ユーザーストーリー単位の分割が困難なケースも存在します。
このような状況では、ベストプラクティスに固執するよりも、タスク単位での分割をチームで認め、それを実行する方が効果的です。例えば、Swagger定義の作成やWeb APIの実装のみを行うことで、大きなストーリーの不確実性を軽減し、チームとしてアウトプットを出すことができます。
ただし、この方法にはデメリットも存在します。バックログアイテム間に依存関係が生じたり、バックログの優先度が変わり不要な実装や手戻りにつながる可能性もあります。それでも、分割を行わずに何もアウトカムもアウトプットも出せないよりは、何かしらのアウトプットを出すべきです。それがチームの成長に繋がり、将来的なアウトカムに繋がり、プロダクトゴールに向かう礎となるからです。
※ アウトプットを出す目的を履き違えないでください。ビルドトラップに陥ることを推奨しているわけではありません。
この考えの根底には、デュアルトラックアジャイルとの向き合い方。あるいはエンジニアとビジネスの距離感で紹介される強いチームを作るにはイテレーションが必要に近いものがあります。
アジャイル開発におけるベストプラクティスは、厳格に守るべきルールではなく、その背景を理解し、状況に応じて柔軟に対応することが重要です。時には、プラクティスから逸脱する選択をすることもありますが、その際には適切な説明責任が求められます。タスク単位での分割を「いざという時の手段」として共通認識として持ち、状況に応じて適用することが、持続可能な開発とチームの成長に繋がります。