その欠陥がリンクされるように、振り返ってストーリーを作成しますか?
はい。また、誰もがその話に同意していることを確認するためにも、レビューする価値があります.
バグがなくても煩わしいインターフェイスである場合は、実際にワークフローを変更していることになり、適切なストーリーとして記念する必要があります。
関連するバグがある場合は、バグを検出する必要がある (しかし検出しなかった) 単体テストがあります。これはあなたの状況ではないようですが、不完全な単体テストでバグが見つからないのはよくあることです。(ストーリーを修正した後に) 単体テストを拡張することも非常に重要です。
欠陥をストーリーとして再ラベル付けし、ストーリーのように見えるようにフォーマットを変更しますか?
あまり。ストーリーがあるかどうかに関係なく、欠陥は単なる欠陥です。
欠陥はなくなります。ストーリーはそうではありません。
ストーリーを作成した場合、(ストーリーのポイントを介して) 欠陥を修正するためのポイントを獲得できますか?
なぜだめですか？
編集します。ストーリーポイントの問題は難しいです。理想的には、ポイントは完了した作業と作成された価値を追跡します。ストーリー==努力==ポイント。しかし、再利用、リリース、および手直しを処理する際に問題が発生します。
努力、品質、価値など、いくつかの無関係な問題があります。ポイントはそれらの 1 つを追跡できます。他のいずれも追跡できません。
ベロシティが努力を反映するべきだと考える場合、バグや要件の変更によって減点することはできません。作成された価値を追跡しないため、そのために使用することはできません。
速度が値を追跡する必要があると考える場合は、ポイントを取り除く必要があります。作業は完了したため、作業は追跡されませんが、その功績は削除されます。
やり直しは大変です。バグと要件の変更は同じものであり、作り直しです。あなたは候補者の全範囲を持っています。
実装が間違っている「単純な」バグですが、ストーリーは「正しい」です。理想的には、これは速度にカウントされません。右？
「不完全なストーリー」バグ。実装は正しいが、ストーリーでは重要な (および技術的な) 詳細が省略されています。うーん。誰のせい？これにより、誰の速度測定が罰せられるべきですか?
何を測定していますか？努力？作業は完了しました。価値？価値が生まれませんでした。
実装は正しいが、ストーリーは最初から悪い考えであり、誰もそれを理解していない「間違ったストーリー」バグ。これを「嘘つきユーザーシナリオ」と呼べる。それは起こります。理想的には、これは速度にカウントされます。ユーザーは嘘をつきました。しかし、これを他のリワークとどのように区別できますか? 「ルール」とは？
実装が正しく、ストーリーが正しかった「ストーリーの変更」バグ。しかし、全体的な文脈が変わったので、ストーリーを変える必要があります。これは単なる「強化」または「適応」であり、新作のようなものです。もちろん、全力でやるわけじゃないですよね？これは既存のコードの微調整にすぎない可能性があるため、作成された完全な価値でこれに過剰な報酬を与えたくありません。
何を測定していますか？努力？一部は行われましたが、多くはありませんでした。価値？価値が生まれました。
ボトムライン。ポイントは政治的な武器であり、あまり測定されません。努力か価値のどちらかですが、両方ではありません。そしてよくない。