PBIのWhyとWhat

おはようございます、こんにちは、こんばんは、tarokenです。

PBIのWhyとWhatの話です。

少し前提のお話しをしようと思いますが、我々のチームでは紆余曲折あり、今リファクタリングのタスクはDeveloperが作成してPBI（SBI）化して、POとスプリントプランニングで技術品質の優先度を話し合いながら進めています。つまりリファクタリングタスクの受け入れ基準はPO（私）ではなく、メンバー（Developer）が作って書いてます。

そんな中、今日チームでとある出来事が起きました。リファクタリングタスクを受け入れしているあるメンバーが「あれ、このリファクタリングの受け入れ基準、”後で”ってなってるんだけど・・・なんで・・・チケット担当者とチームでディスカッションしたときに”入れておいてね”って伝えたのに・・・」

という話になりました。

スクラムをうまく回すために受け入れ基準をきちんと書く - SmartHR Tech Blog

受け入れ基準をなぜ書かなければならないか、体系的にまとまっているのは上の記事なので、私は今日チームで話したことを愚直に書こうと思います。

なぜ「後で」という受け入れ基準になってしまったのか。書いてないのはよくないよね、という話は上の記事にありますが、そうではなくて、チームのメンバーがなぜそういう受け入れ基準を書くに至ってしまったのか、ということを深掘りしました。

その書かれたPBIを見ていたりヒアリングしてみると「HOWは確かにみんなでモブしながら色々試そう、みたいな話ししたから、だから受け入れ基準書かなかったのかな」ということを言っていました。

私はこの発言にピンときました。
（HOWが決まってないから受け入れ基準書かないってどういうことだ？）

私の中では「WhyやWhatに対して受け入れ基準を書く」というイメージをしていました。でなければPOは価値の検証ができないですし、HOWに対して受け入れ基準を書くのはPOはできないからです。

メンバーに対して聞きました。
「リファクタリングタスクをするときに、もし他の人がやったリファクタリングを受け入れるってどういうことかな？」と。

さらに一言「私の理解ではリファクタリングは顧客の価値そのものが変わるわけではないと理解していて、そうなるとPOとしてリファクタリングを仮に受け入れるとしたら対象価値提供している機能がデグレしてないことを確認するかな。」といいました。

PBIにWhatが書かれてなかったかも？という話にもなりましたが、Whatが書かれていないなら透明性が確保されているかどうか怪しいので本来スプリントプランニングで対応すべきではないはずです。（PBIはリファインメントの活動を通じて透明性を獲得し、スプリントプランニングの時にはすでに着手可能な状態になっているべき）

つまり、「書かなかった人が悪い」のではなく、チームとして「PBIにWhatが書かれてないものを着手していた」もしくは「Whatが書かれているのに受け入れ基準を曖昧にした」というのが原因なのかなと思いました。

そしてそれはスクラムマスターとしての私も非常に反省しましたとさ・・・。。。

デグレしたサービスを世に放たないように、今後も気をつけたいと思います。