ユーザーストーリーの新しい変更リクエストは別のユーザーストーリーですか
スプリントのユーザーストーリーが完成しました。スプリントの終わり近くに、同じユーザーストーリーに対して新しい機能の追加が要求されました。
ここでは、ユーザーストーリーは同じままです。つまり、<user> したい <> そのため <>は同じままです。唯一の違いは、実行される新しい付加価値があることです。
それで、これは次のスプリントの新しいユーザーストーリーと見なす必要がありますか、それともバックログと見なす必要がありますか？
ユーザーストーリーの定義が完了しました。この新機能は、ユーザーストーリーの定義に変更を加えない新しい要件です。
より明確にするために例を追加します。
機能は、ユーザーが自分の名前、住所、電話番号、写真などを更新できるという点で、プロファイルの作成と言います。お客様がFacebookへのリンクを希望する場合、または電話番号に国コードを追加する場合、その変更要求は新しいユーザーストーリーですか？
新しい要件に合わせて新しいストーリーを作成するだけです。
タイトルの質問には一般的な答えがないかもしれませんが、あなたの例を考えてみましょう：
As a user I want to maintain a user profile
自宅の住所、電話番号などを編集して保存する機能など、このストーリーの完了の定義があるとします。プロダクトオーナーは同意し、ストーリーは推定され、スプリントに組み込まれました。後でそれは完了としてマークされ、ストーリーポイントが獲得されました。
このストーリーを変更すると、元のストーリーのスコープが変更されます。それはあなたがそれを取り上げる前に合意されたようにあなたが高品質の仕事を提供したとしても、あなたのバーンダウンの低下を示します。 この関連する質問 を参照してください。新しいストーリーを作り、それが小さなものであることを受け入れ、スプリントを小さなもので満たす必要があるときにそれを引き出します。
これから学んで、そして 終了するたびに完了の定義を調整してください 終わりの前に1回だけ含まれるようにして、手遅れになる前のささいな追加を防ぎます。
スプリントでストーリーがコミットされると、そのストーリーは変更できなくなります。
ここで、ユーザーがスプリントの途中でそのスプリントのストーリーの1つに影響を与える新しいアイデアを思いついた場合、それを処理する方法はいくつかあります。
- スプリントを中止するそして、新しいスプリントの計画を開始します。これは大きな影響があり、通常は最後の手段のオプションになります。これは主に、クライアントの新しいアイデアが現在行われている作業を完全に無効にする場合に役立ちます。
- 影響を受けるストーリーをスプリントから削除。いくつかのストーリーがこれらの新しいアイデアによって無効にされ、ゼロ（またはマイナス）の価値があると見なされる場合、クライアントと協力して、それらのストーリーを現在のスプリントから削除することを決定できます。結果として生じる作業のギャップは、製品バックログからの作業で埋められる可能性があります。
- 新しいアイデアをストーリーとして追加。これは最も一般的なオプションです。元のストーリーにまだ価値がある場合は、予定どおりに完成させ、新しいアイデアを追加のストーリーとして製品バックログに追加します。
- 変更が非常にマイナー（<1ストーリーポイントのストーリーになる）で、ストーリーがまだ完了していない場合は、オリジナルと一緒に変更を適用することもできますストーリーの実装。この選択はまれです。
「プロファイルの作成」ストーリーの例では、追加のストーリーは、ユーザーがFacebookリンクをプロファイル内の他の情報と一緒に保存したい場合です。
変更が変更リクエスト（通常は個別に請求される）であるか、通常の作業に該当するかは、クライアントとの契約によって異なり、アカウントマネージャーの問題です。
私はスクラムのエキスパートではありません（anyの意味で）が、これは新しいユーザーストーリーである必要があります。
このストーリーでは、すでに受け入れ基準を満たしています。
この変更を行うと、その成果が危険にさらされる可能性があります。 （おそらくこれにはトレンディで新しい名前が付けられていますが、私たちはsedを「スコープクリープ」と呼んでいますが、決して良いことではありませんでした）。新しいデータフィールドを追加すると、基になるデータストアが変更される可能性があります。
これは「迅速な」仕事かもしれませんし、そうでないかもしれませんが、再びあなたのポイントを危険にさらしています。他のすべてのように、それを新しいストーリーにして、バックログに入れます。
確かに、それが出てくると良いアイデアのように見えます（そして本当に重要です）が、すべての現実に直面するとelse必要な場合、それは[比較的]になる可能性がありますそれほど重要ではありません。これは：
「ユーザーストーリーの定義を変更しない新しい要件」
変更であるがこれストーリーの定義を変更していない場合、これストーリーの一部としてどのように実行できますか？確かに、その定義はストーリーの[一部]でなければなりませんする変更しますか？
ドキュメントと厳密なスクラムフレームワークでの変更の処理に関しては、新しいユーザーストーリーとして処理する必要があり、既存のイテレーションでは許可されませんが...
実用的で、不必要なオーバーヘッドを作らないようにしましょう...それはアジャイルではありません。コーディング/テストの複雑さ/労力が非常に少ないため、既存のストーリーの下で変更して完了するのではなく、新しいストーリーの作成、優先順位付け、および管理に時間がかかる場合は、無駄のないルートで既存のストーリーを更新します。
拡張機能をバンプした後、変更を行う前に、開発者がコードに再びウォームアップする必要がある場合があります。オンザフライで変更を加えて、既存のストーリーに対する変更を追跡するだけの方が効率的な場合があります。