機能をユーザーストーリーに分解する正しい方法
私が現在取り組んでいるユーザーストーリーのサイズについて質問しています。私が実装している機能は、Datepickerコンポーネントです。このコンポーネントのビジネス上の価値は、ユーザーが日付範囲をすばやく選択できるようにすることです。コンポーネントは、Webアプリケーションの複数のページで使用されます。
現在、この機能を説明する3つのユーザーストーリーがあります。
- 一度に2か月表示する
- 矢印をクリックして、表示された月をスクロールします
- 選択した日付範囲を強調表示します
私の主張は、ユーザーストーリーはどれもそれだけでは価値がなく、あまりにも「水平」であるということです。より「垂直な」アプローチには、現在の3つのユーザーストーリーの動作をカプセル化する「Datepickerコンポーネント」の単一のユーザーストーリーが含まれます。
より垂直的なアプローチがより良いアイデアであると私は考えるのは正しいですか？
より「垂直な」アプローチは、ストーリーの分割に関する一般的なガイダンスです。それが強化するものは：
- 製品全体に取り組むことができる多機能チーム
- 未舗装の道路を構築し、それに機能を追加する
- 追加機能の一部をエンドユーザーに役立つようにする
ただし、良い答えが得られないのは、通常、未舗装道路の準備作業が含まれるためです。 「比喩」を維持するには、パスをクリアして平らな表面を作る必要があります。そのようなものが、構築される最初のストーリーにマージされます。その後、追加の部分はすぐに進みますが、準備作業を適切に説明するのは困難です。それ自体はユーザーに直接的な価値を付加するものではありませんが、新しい機能セットに対応する必要があります。
この例では、最も簡単なものから始めます。
- 1か月表示
- 選択した日付範囲を強調表示します
次の話は：
- 2か月目を表示
最後に、
- 表示された月の前方スクロールと後方スクロールを追加します
この例では、ユーザーは最初の実装から最小限の有用性しか持っていません。次のストーリーは主にUIに関連しています。コントロールを並べ替えて、月を並べて表示する必要がある場合があるためです。月表示をまだ独自の表示コンポーネントにしていない場合は、今すぐ実行する必要があります。最後に、前後にスクロールする機能は、最終的にはより多くのバックエンドの変更になります。
これは、この場合の実行方法の例にすぎません。最初のストーリーで実行可能な最小のソリューションが何であるかを考えてください。そして、連続するストーリーごとに、アプリケーションをますます使いやすくしています。
あなたが発表したストーリーが水平にスライスされていることに同意しません。水平スライシングを使用すると、チーム内のさまざまな分野を対象とするストーリーや、完全な機能が完了するまでユーザーにany機能を提供しないストーリーが表示されます。
縦にスライスされたストーリーがある場合、たとえストーリーがユーザーのニーズを満たすのに十分ではない場合でも、各ストーリーはユーザーに何かを提供します。その意味では、あなたのストーリーは私にとって垂直スライスのように見えますが、異なる垂直スライスを作成することもできます（ @ Berinの回答で示されるスライス のように）。
それらを1つのストーリーにマージすることに関しては、「完全なDatePickerコンポーネント」のストーリーが1つのスプリントで簡単に完了するのに十分小さい場合にのみ考慮する必要があります。
あなたがリストしたユーザーストーリーで私が抱えている問題は次のとおりです。正確な実装が考えられており、誰かがその周りにユーザーストーリーを書き込もうとしているようです。それはユーザーストーリーのポイントやメリットではありません。ユーザーストーリーは、ユーザーのニーズを念頭に置いて作成する必要があります。何かのようなもの：
会議の主催者として、カレンダーから日付を選択できるようにしたいと思います。時々、それが第3土曜日であることがわかっていて、日付がわからないことがあります。
そしてその上に：
会議の主催者として、今月よりもさらに計画を立てられるように、見ている月を切り替えられるようにしたいと考えています。