構築したばかりの新しいプロジェクトバックログから2つのユーザーストーリーを達成しました（いい言葉ですか？）。これらはユーザー登録とパスワードのリセットで、どちらもメールが必要です。私が最初に選択したもの、および通常は信頼できるものが機能しなかったため、代替メールコンポーネントを実装する必要があります。メールコンポーネントのデバッグではなく、ユーザーストーリーの配信に重点を置いていたため、スプリントの最後に機能するコードを配信するためにそれを交換しました。メーラーの新しいサポート問題をログに記録しますか、それともこれらのストーリーをバックログに「再挿入」しますか？後者を実行する場合、ユーザーストーリーに技術の詳細をあまり紹介していませんか？
回答:
ユーザーストーリーを、doneの定義で定義された標準に実装した場合、それらのユーザーストーリーは完成したので、製品のバックログに戻すべきではありません。
同様の状況で私は新しいユーザーストーリーを挙げましたが、製品のバックログに純粋に技術的なものを置くのではなく、ビジネス上の利点の観点から技術的な変更を加えるための要件を説明しました。どうですか：
「開発者として、私は製品に会社の標準の電子メールコンポーネントを使用して、サポートとメンテナンスを簡素化したいと思っています。」
開発者としてもあなたはアクターであり、システムを使用（サポート/変更）したときにシステムが特定の方法で動作するという要件がある場合があります。ビジネス上の利点の観点からこれらを明確にし、新機能の実装とともに製品所有者に優先順位を付けることが常に可能である必要があります。
ユーザーストーリーの完了の定義がフルファイル（フルフィル、すべてのユーザーが完了したいもの）である場合、ユーザーストアは完全であり、バックログに戻すことはできません。
しかし、あなたはそれを完了するために技術的な負債を引き受けており、後でそれを修正するために他の時間を費やす必要があります。したがって、リファクタリングなどの内部作業には一種のタスクが必要だと私には思えます。
そのため、バックログに新しい問題を追加します。
ストーリーが完了した場合、それはQAに合格し、プロダクトオーナーによって承認されたことを意味します。
実装を「クリーンアップ」または「改善」するために実行する必要がある作業は、技術的負債と見なされ、単に新しいストーリーである必要があります。
そうすることで、他のすべてと同様に、プロダクトオーナーによって追跡され、優先順位が付けられます。
関連するコメント、OPは言います：
私の「回避策」は高品質のソリューションですが、当初想定されていた実装は回避策の改善になるため、新しいストーリーを作成してメール機能を改善できますか？
その場合、元の質問は意味がありません。YAGNIの原則は、ソリューションは、将来の要件を見越してオーバーエンジニアリングされないことが必要です。
ソリューションが現在のスプリントの目標を満たし、設計どおりに機能し、チームの「完了の定義」を満たしている場合、それは完了です。半分は完了しておらず、「計画的なリファクタリングを待って完了」しているわけではありません。
完了マークを付けて次に進みます。
本当に別のストーリーがある、または元のストーリーの実行を妨げない何らかの技術的負債があると本当に思う場合は、製品バックログの別のストーリーを作成する必要があります。
可視性を高めるために、常に新しい作業をプロダクトバックログに配置する必要があります。目に見えない作業はありません。最終的に、提案された改善が製品の目標と一致するかどうかを決定し、ストーリーを追加することを選択した場合は、製品バックログ内の新しいユーザーストーリーに優先順位を付けるのは、製品所有者の仕事です。
あなたの質問と@Kleeの回答への追加コメントによると、問題は少し違うと思います。
ストーリーを完成させました。これは、完了のすべての定義に合格したことを意味します。そうでない場合、ユーザーストーリーは完了したと見なすことができません。しかし、ストーリーを完了し、完了のすべての定義に合格した場合は、現在のソリューションが満足のいくものであることを意味します。それ以外の場合、顧客/製品の所有者は、それが満足できない（あなたではない）理由を上げ、完了を拒否するか、現在のソリューションでは満足できない、doneの新しい定義でこれを拡張する別のユーザーストーリーを定義する必要があります。
現在のソリューションがいくつかの要件または制約を満たさない場合にのみ、技術的負債が発生します。回避策を使用して違反した制約はありますか？はいの場合、ユーザーストーリーをそもそも完了としてマークしないでください。
回避策によって導入されたコードの重複または別の悪い習慣はありますか？次に、技術的負債を作成しました。できるだけ早く解決する必要があります。製品の所有者にとって公平であり、次のスプリント中に技術的な問題を修正するために同じ時間を費やさなければならないため、ユーザーストーリーの計画性が低下することを伝えてください。または、製品所有者との関係があまり良くない場合は、「新しく」発見された複雑さのために、ユーザーストーリーを少なく計画し、技術的負債を修正するだけです。
コードの重複がない場合、またはコードを改善すべき実際の理由がない場合は、触れないでください。本当の理由で、私は顧客/製品所有者が制約を定義していないことを意味します（たとえば、会社のポリシー、パフォーマンス、現在のソリューションでは達成できない新しい電子メールテンプレートを作成するための事前定義された時間など）。コードに技術的な負債はありません。あなたがやろうとしていることは、金メッキと呼ばれています-必要のない機能を提供する=顧客のリソースを浪費しています。
ソリューションが将来のユーザーストーリーを満たさない場合は、リファクタリングとコード改善をそのユーザーストーリーに移動するだけです。完了の現在の定義を通過したので、今解決する必要はありません。新しく実装されたストーリーの完了の定義を渡し、悪い習慣を回避するためにそれらを実行する必要がある場合は、改善に対処します。