何のためのガイドライン？

ひとまとまりの機能をリリースするためのエピックや、次のスプリントでの完成が期待されているユーザーストーリーに関して

• 「思ってたよりやることが多くて終わらなかった」
• 「このままだと価値を提供するには不完全で、リリースできない」
• 「リリースはしたものの、なんとなくしょぼい」

とならないために考えるべき事柄をまとめています。

機能に関連するユースケースはどれくらいありますか？

• 関連するユースケースをリストアップしましょう
• WF やデザインがない状況でイメージするのが難しい場合は、簡単な画面スケッチでよいので書いてみましょう。

そもそも根本的なソリューションの方向性が複数見つかったり、新しい概念を導入する必要性が発覚する場合、リファインメントのレベルでの検討が足りていない可能性があります。PO や SM に連絡して課題の着手を見送るか、WF やデザインのいったんの完成を完了条件をとして課題に取り組みましょう。

ユーザにリリースするために最低限必要なユースケースはどれですか？

リストアップしたユースケースのうち、リリースに真に必要な項目を選別します。「価値を感じられる最小の単位」になっていることが望ましいですが、その判断基準はプロジェクト・プロダクトの性質やフェーズによってあまりに多様なので良い感じに考えて……

開発にあたって、技術的な不確実性はありますか？

技術的な不確実性が含まれている場合、スプリントの期間内に（あるいは時間が十分にあっても）実現できない可能性があります。また、実現のために何らかのトレードオフが発生するケースもあります。

1. もし実現できたら最高のユーザビリティを提供できるが、できるかどうかわからない
2. 不確実性は依然として殘っているが、できないこともなさそう
3. 機能やユーザビリティの面で水準が下がるが、確実に実現可能

2, 3 を採用してもリリースに足る品質を維持できると思えるなら、その方向で実現を目指しましょう。そうではなく 1 で不確実性の解消に真っ向から取り組む必要がある場合、スプリントの期間内に終わらない可能性が高いです。直近のスプリントは不確実性の解消に取り組み、次のスプリントで本格的な実装とリリースを行えるよう準備しましょう。

その機能が維持しなければならない品質はどの程度ですか？

最低限必要な機能を実現する場合でも「とりあえず動く」以上のプロダクトを出荷する必要があります。提供しようとしている価値をユーザが適切に評価してくれなかったり、プロダクトの品質や信頼性を損ねる可能性があります。