作成と編集は2つの個別のユーザーストーリーにする必要がありますか？
アクションの作成と編集が非常に似ている状況に出くわしますが、それらはまったく同じ話ではありません。それで、それらは別々のユーザーストーリーとして扱われるべきですか？たとえば、次のようにすることができます。
オプションA：
S A1：システム管理者として、ユーザーがアクセスできるサービスとユーザーがシステムにアクセスできるサービスを指定できるように、新しいユーザーアカウントを作成します。
S A2：システム管理者として、ユーザーがアクセスできるサービスを変更したり、パスワードをリセットしたりできるように、ユーザーアカウントを管理したいと考えています。
対
オプションB：
S B1：システム管理者として、ユーザーがアクセスできるサービスを指定し、ユーザーがシステムを利用できるように、ユーザーアカウントを作成および管理したいと考えています。
アプローチAまたはBは正しいですか、それとも単に作成機能と編集機能の複雑さに応じて、個人的な好みまたは実用主義の問題ですか？
ここで考慮すべき重要なことは、ストーリーが管理可能な作業の塊かどうかです。
管理可能であるためには、次の条件を満たす必要があります。
- 明確に定義されている
- 見積もりがかなり簡単
- スプリント内で完了可能
したがって、2つのストーリーをマージすると、上記のポイントのいずれかが何らかの形で損なわれることがわかった場合は、それを行わないでください。
個人的には、smallのストーリーを扱う方が、その方法で推定する方が簡単だと思うので、好みます。トレードオフは、スプリント内の関連するストーリーまたは依存するストーリーの順序に注意する必要があることです（かなり簡単なタスク）。
別のユーザーストーリーを持つオプションAが望ましいと思います。
ユーザーストーリーは要件です。 良い要件の特性のセット がよく受け入れられる傾向があります。オプションAは、ユーザーストーリーがまとまりがあり（1つだけ対処）、アトミック（接続詞を含まない）、オプションBよりも簡単に検証できることを保証します。
見積もりの観点からすると、ワークフローとユースケースを確認することで、それぞれを個別に見積もる方がおそらく簡単です。おそらくそれらの間の共通点や依存関係が表示されます（たとえば、編集する前に作成する必要があります）が、それらを細かく分割すると、より現実的な見積もりを出すことができます。
ただし、実装の観点から見ると、リリースを実際にエンドユーザーに役立つようにするには、両方の機能を一緒に提供する必要があります。ただし、これは反復計画で管理できます。リリースサイクルによっては、リリースがすべてのイテレーション後に発生しない場合、それらは1つのリリースになりますが、イテレーションが異なる場合があります。それはすべて計画と管理次第です。
TL; DRそれらは2つの別個の、しかし関連する要件であるべきです。
それらを個別の要件として実行する場合のリスクは、関連するUIと基になるサービスのコードが重複することです。ただし、これらを1つの要件として組み合わせる場合のリスクは、編集パスの設定が少し異なることです。
createパスは次のようになります。
- 許可ユーザー（AU）がシステムにログインし、
create userパネルを開きます - AUが入力し、新しいユーザーの詳細を確認します
- AUが作成要求をシステムに送信する
- システムは、ユーザーアカウントに関するビジネスルールが満たされていることを検証します
- システムはユーザーアカウントを格納します（おそらく挿入ステートメント）
editパスは次のようになります。
- 許可ユーザー（AU）がシステムにログインし、
edit userパネルを開きます - AUは、ユーザーの詳細の取得を要求します
- システムはユーザーの詳細を取得し、AUに情報を提示します
- AUは新しいユーザーの詳細を調整します
- AUがシステムに編集リクエストを送信
- システムは、ユーザーアカウントに関するビジネスルールが満たされていることを検証します
- システムはユーザーアカウントを格納します（更新ステートメントのようです）。
ユーザーパネルの作成と編集には明らかな再利用がいくつかあります。同様に、ユーザーアカウントに対してビジネスルールをチェックする同じルーチンを再利用できます。
ただし、作成パスで既存のユーザーの詳細を取得する必要はありません。また、パスワードのセットアップなど、作成パスでプロンプトが若干異なる可能性があります。
どのパスをたどるかの最終的な決定は、開発チームがどのように機能するかによって異なります。私の経験から、2つの個別のユーザーストーリーを持つことは、プロジェクト管理に関連するワークロードを表すのにより優れた仕事をします。また、通常、2つのタスクは同じ人に割り当てられるため、要件に取り組みながら追加のコミュニケーション/調整の必要性を減らすことができます。
密接に関連するユーザーストーリーがある場合、より広い視野を見ると、少し時間をとって、各ストーリーに何が関係しているかを簡単にスケッチする必要があります。ストーリー間に大きな違いがある場合は、個別のストーリーを使用した方がよいと思います。これは、重要な違いが結合されたストーリー内に埋め込まれていないことを確認するのに役立ちます。
ストーリー自体に大きく依存すると思いますが、2つのタスクのプロセスまたは管理を区別しますか？
新しいレコードを作成するかどうかに関係なく、実際に違いがないシナリオを想像できます。これは、単一のストーリーとして行うことができます。
特定の管理者のみがアカウントを作成できるシナリオを想定することもできますが、アプリケーションまたはサービス管理者のより大きなグループがユーザーアカウントの一部を更新できる可能性があります。これは2つ（またはそれ以上）のユーザーストーリーのように聞こえます。