はじめに

クリスマスイブ、ということは今年もあと少しとなります。
本業では大規模開発のマネージメントをしています。サブシステムやチーム単位では厳密にスクラムではないものの、イテレーティブな開発を試していく動きも(少しずつではありますが)あったりします。そこで良いプロダクトバックログとはなんだろうかと少し考えてみました。

TL;DR

プロダクトバックログは永遠にβ版

重複を気にしないで書く

たとえばあなたがプロダクトオーナーになったとしましょう。まっさらな状態からプロダクトバックログを作っていきます。きっと周囲の人の頭が良ければ良いほど、MECE(もれなく、だぶりなく)であることを求めてくるかもしれません。
しかし、はじめから「もれなく、だぶりなく」というのは、なかなか難しいものです。重要なのは「もれなく」です。はじめのうちは重複はおそれず、必要だと認識したものを次々と書いていきましょう。

形容詞、形容動詞は使わない

抽象的なアイディアが思いつくこと自体はよくあることです。
しかし、実際に開発していくチームのメンバーと認識がずれやすい表現は避けたほうが賢明です。
キレイな~ など形容詞、形容動詞を使うのはなるべく控えるべきでしょう。
要求事項が不明瞭になり、エンジニアとのハレーションも増えてしまうかもしれません。

必ず受け入れ条件を書く

これも前項と似ている話です。スクラムに詳しい方ならAcceptance Criteria というと伝わるでしょうか。受け入れる人によって基準が変わっては困ってしまいます。エンジニアはAcceptance Criteriaを目指して実装していきます。基準が明確ならば、ストレスもきっと少ないでしょう。

INVESTで整形する

ある程度量がたまってきて、展望が見えてきたら書いたものは放置せず、整えていくことが大事です。その際には「INVEST」というものを意識するとうまくいくかもしれません。
Indecent --- 依存しない(少ない)
Negosietable ---　交渉可能
Valuable --- 価値がある
Estimate --- 見積もり可能
Size -- 手頃なサイズ
Test --- 検証可能

サイズと依存は対立しますが、迷った時はサイズを小さくする方を選ぶのがセオリーのようです。見通しが立てやすいためです。

プロダクトバックログは比較で見積もる

さあ、実際に開発していくとして、当然あなたはどれくらいかかるものかが気になります。
大事なことは何のために見積もるのかです。事前に一つ一つのアイテムについてエンジニアが勘と経験でxxx時間かかると見積もったものがどこまで正しいのか、正直あなたにはわかりません。
それよりもベロシティを計測しましょう。開発チームの生産量を見える化したほうが効率的で正確かもしれません。比較で見積もるというのは、たとえば一番小さなアイテムを1としてそれ以外がいくらくらいになるか、で見積もっていきます。スプリント x ベロシティで生産量を出していけば、リソース計画も立てることは可能です。

Undoneもきちんと積む

いざ実際に開発を始めるとリリースの際に完了(Done)できなかったものも出てくるでしょう。
そういう時は無理せず、焦らずきちんと積み残し(Undone)としてのせることが肝心です。
たとえば、成果物定義の中で作らなければならないドキュメントがあったとして、様々な都合上該当スプリントのリリースから外した場合、きちんとバックログに積んでいかないと、どんどん形骸化してしまいます。イテレーティブな開発 = 早くリリースできるではありません。チームのベロシティを可視化しながら、ゴールを目指すことが目的なはずです。Undoneは保守的に消化しましょう。

プロダクトバックログは永遠にβ版

イテレーティブな開発をしているということはマーケットの中でいろいろな挑戦を繰り返しているということだと思います。マーケットへの提供価値もプロダクトの機能も試行錯誤の中で変わっていくとすればプロダクトバックログもまた永遠にβ版として、定期的Refinementすることが大事になっていくでしょう。

プロダクトバックログにはあなたのプロダクトオーナーとしてのスタンスが表現されていると言えるかもしれません。

最後に

つらつらと書いてしまいましたが、メリークリスマス！