駆け出しスクラムチームからよく聞かれる質問への回答。
※スクラムの実務経験がない個人の私見です
質問内容
Problemと妨害リストの違いがわからない。
どう使い分ければ良いか。
前提
- レトロスペクティブで振り返りのフレームワークとしてKPTを使っている
私の回答
妨害リストについて
妨害リストでは、そのスプリントに関わらず、またスプリントゴール達成に関係がなくとも、困っていることを管理します。
外的要因が絡んでくることが多く、また即時解決が難しく長期的に解決を目指していくものも出てきます。
妨害リストの例
- PJ以外の割り込みタスクが多い
- POが多忙で受け入れ確認をスプリント終盤まで進められないことが多い
- スクラムチームのスクラム理解度が浅く、各イベントが効果的に機能しない（タイムボックスが守られなかったり、レトロで改善が出なかったり）
- ステークホルダーの声が強く、POの意見が通らない
- フロントの実装がAさんに依存している
KPTについて
レトロスペクティブでは主にそのスプリントにおいてスプリントゴール達成のための行動の中で、うまくいかなかったこと、改善できそうなことについて振り返ります。
基本、自分達の行動改善だけで解決できるものになってくると思います。
Problemの例
- 進捗が芳しくないことにスプリント終盤で気づいた
- PBIがReadyでなかった（スプリント中にPOやステークホルダーへの確認で待ちになるものが多かった）
- バッファを考慮していたはずが、PBIの完了だけで手一杯だった
- 共有や相談をデイリーまで待つケースが多かった
話がそれますが、KPTでよく見かけるアンチパターンについて。
-
Problemに原因まで記載する
Problemに原因まで書く人が結構いますが、事象までで留めることをお勧めします。最初から原因が書いてあると、その原因の解消のみにフォーカスされがちですが、その事象が起きた原因はそれだけじゃないかも知れず、もしかしたら他の原因の方がクリティカルかも知れません。 -
Tryに行動改善でなくタスクが上がっている
解決策がタスク（〜〜リストを作成する、Wikiに〜〜について記載する、など）であればKPTで管理するのではなく、PBIを作ってしまいましょう。
最後に
Problemや妨害リストの定義を気にしすぎて問題点・課題の検知漏れがあると本末転倒なので、一旦Problemとしてはあまり深く考えず色々上げた上で、適切な管理先（ProblemなのかPBIなのか妨害リストなのか）へ移動させれば良いかと思います。