ユーザーストーリーは、独立して価値があるか、または独立して価値がある必要がありますか？
まったく新しいシステムのユーザーストーリーを分割しようとしています。このシステムは、シリアルポートに接続された天びんの重量測定値を記録します。
規制データの整合性要件により、データはそれを作成したユーザーに帰属する必要があります。企業は、この要件を満たさずにソフトウェアを使用することはできません。
これらの要件を満たすために、最初にログインとデータ記録の両方をカバーする1つのストーリーを書きましたが、これは少し大きいように見えたので、次のように分割してみました。
1) As a lab technician, I would like to be able to record weights electronically without transcription so that I do not make mistakes when recording data.
2) As a QA officer, I need data recorded by users to be attributed to them via their windows credentials so that we can comply with <relevant data integrity guidance>.
これらの新しいストーリーにINVESTを適用すると、いくつかの問題が発生します。これらのストーリーは、個別に実装にすることもできますが、相互に関連する場合のみ貴重になります。
- justストーリー1を構築する場合、ビジネスはデータ整合性の規制に適合せずにシステムを受け入れることができないため、ユーザーはシステムから価値を得ることができないため、価値がないようです。
- justストーリー2（ログイン関数）を構築する場合、ログインして何も実行できないシステムは価値がありません。
これは分割の有効な方法ですか、それともストーリーは独立して価値がある必要がありますか？
各ストーリーは個別に価値がある必要があります。しかし、それに夢中になりすぎないでください。
アイデアは、部分的な機能を回避することです。つまり、年齢を費やして何かをしていて、プロジェクトの目標に向けた進展を示すことができません。
たとえば、ログインストーリーと購入ストーリーを含むeコマースサイトプロジェクトがあるとします。明らかに、機能するeコマースサイトを作成するには、両方が必要です。しかし、別のストーリーとしてLoginを実行すると、スプリントの最後にそれをデモすることができ、そのタスクはリストから削除されました。わーい！ログインページが必要だったのはわかっていて、これで機能することがわかります。進行状況を見てください！
反例は、「データベースサーバーのインストール」です。顧客/製品の所有者/利害関係者が気にかけるデータベースを持つことには何もありません。確かに必要ですが、それは他のストーリーの実装の詳細としてのみです。ブー！私は「データベース」ではなくウェブサイトが欲しいと言っていました！あなたが終わるまでどのくらいの時間？！？！
あなたの場合、私は監査要件を2つの部分で指定します。
監査データを確認する必要がある人のためのスタンドアロンストーリーとして：
「私は監査人として、「規制」を満たすために「もの」の監査証跡を読み取り、ダウンロード、エクスポートできます。」
データを記録する必要がある他のストーリーの非機能要件/ DoDとして
「X YおよびZを「監査システム」に記録する必要がある」
問題の核心は、少なくともこの特定の例では、ストーリーをどのように分解したかにあると思います。私にとって、QA担当者がデータを記録する必要があるという話は、話ではありません。 QA担当者がデータを照会、表示、およびエクスポートする方法に関するストーリーがあるかもしれません。しかし、データが記録されるという事実は、データが作成、更新、変更、または削除されるストーリーに適しているように見えます（そして規制された環境では、「削除」はおそらくソフト削除であり、ハード削除ではありません）。
ストーリーに分割するのではなく、このような受け入れ基準を使用することで、各ストーリー（およびそれに関連する受け入れ基準）が貴重であり、作業の範囲全体がキャプチャされ、チームが1か所で理解できるようになります。