バグチケット
バグチケットなるものがあります。実装したプロダクトに不具合があった際に作成されるもので、通常のストーリーやタスクチケットとは別の"色"で管理されたりします。僕の所属するチームでも絶賛運用中で、JIRAのチケットタイプを使い分けてます。
スプリント中にバグチケットなんてない
この記事の結論（極論）はこれです。僕自身はバグチケットの存在に否定的です。
バグチケットとは、プロダクトの不具合をトリガーに起票されます。 一方、スクラム（アジャイル開発全般）においては、DoD（完成の定義）と受入基準を満たしていないチケットはDoneステータスになりません。 さてこのとき、どんな理由で不具合が発生するのでしょうか？
受入基準を満たしていない
まず考えられるのは受入基準を満たしていない状態です。それはまだDoneにはできないチケットです。Doingに戻して受入基準を満たすようにしましょう（もちろん受入基準の見直しをプロダクトオーナーとするのも手段です）。
受入基準にない
リファインメントや受入基準の明文化で共通認識ができていなかったものは、実装されないのでバグチケットになりそうです。 でも本当にバグチケットって"色"が正しいのでしょうか？
その受入基準がなかったということは、プランニング時点ではその価値を見出せていなかったということです。であればしっかり価値を見定めてやるやらを決め、他のチケットと比較して優先順位をつけて、時が来たらやる、というスタンスは他のストーリーやタスクのチケットと変わらないのではないでしょうか？
ということで、バグチケットではなく、ストーリーやタスクチケットとして作成するのがよいと思っています。
リリース後の不具合は？
リリース後の不具合は、チームとしてリリース可能なプロダクトだと自信を持ってリリースしたプロダクトに関する、「受入基準を満たしていない」or「受入基準になかった」挙動と捉えることができます。 なので、スプリントでのスタンスと同様です。ただし、「受入基準を満たしていない」場合は、もうリリースされちゃってるので最優先で解消すべきチケットになるでしょう。
なんでそんなこと気にするの？
別にチケットの種別が違うだけのことだから、細かく気にする必要はあまりありません。 ただ、このバグチケットというプラクティスがチームのマインドセットを阻害していることもあります。 例えば、バグチケットのプラクティスがあることで次のようなことがチームに起こる危険性があります。
- 受入基準を満たしていないチケットが、満たしていない部分だけバグチケット起票され、元のチケットは完了になっている（=リリース可能なプロダクトの状態を壊している）
- 結果、実際の価値提供よりもベロシティが大きく安定して見える
- QAエンジニアのテストでなんとかするマインドセットができあがり、リファインメントが疎かになる
- バグチケットは優先対応になってしまい、適切な優先順位付けができなくなる
- 結果、POがプロダクトバックログのオーナーシップを持てなくなる
- バグチケット数などを指標にし始めると、シフトレフトが進まない（シフトレフトの脳みそになりにくい）ことがある
リファインメントで受入基準を明確にできなければ、実装で受入基準を満たせなければ、それは価値提供の足枷になるんだということがバーンダウンチャートやベロシティから見えなくなってしまいます。あー怖い。
まとめ
そうはいっても…なとこはいっぱいある極論だよなと思いつつ、文字起こししてみました。
- バグチケットは使わない
- なぜならそれはUndoneのチケットか新しいストーリー／タスクチケットだから
- バグチケットの弊害も考えてみよう
ということで、お読みいただきありがとうございます！
