Yasuo's Notebook

ソフトウェア開発の話題が中心の備忘録です。

プロダクトバックログ運用例

書籍「アジャイルソフトウェアエンジニアリング」でもプロダクトバックログの運用方法について考え方、ツールでの扱い方が解説されています。
私も書籍に書かれているのとほとんど同じような方法で運用しています。
このエントリではその考え方と方法を紹介したいと思います。

TFSのプロセステンプレート「MSF for Agile Software Development」 では、基本的にPBIをユーザストーリと対応付けています。
ここで紹介する運用もそれに習っています。(アジャイルソフトウェアエンジニアリング P.21、P.25-26、P.54-55、P.69-71辺りに解説あり)
まず、プロダクトバックログの項目(PBI)がどこからやってくるかを整理してみましょう。

(1)事前の分析から
まず、最初のプロダクトバックログを作成するために、事前の分析を行います。ここでは、その時点での全体的な要求を共有します。分析結果を共有するためにドキュメントとして残す場合もありますが、あくまで「その時点で何を考えていたかを共有するため」のドキュメントであるため、様式は気にしませんし、メンテナンスは行いません。プロダクトオーナはここで分析した結果からユーザストーリを適切な粒度(私は長くても数日で終わる粒度にしています)で抽出しPBIとします。
(2)フィードバックから
開発が進みリリースを重ねていくと、リリースしたソフトウェアに対するフィードバックを受けます。
これは新しい機能の追加要望、既存の機能への変更要望となります。
プロダクトオーナはそれらを整理しPBIとして追加します。
(3)チームからの提案
チームからは、抱えている技術的負債を返済したい。もっとユーザビリティを高めたい、テストや解析可能性を高めるための機能を追加したい、などの提案があります。これらについてもプロダクトオーナがチームと話し合い、必要と判断すればPBIに追加します。

プロダクトバックログには、それぞれのPBIに優先順位と見積もりが付与されていることが必要です。
優先順位はプロダクトオーナが利害関係者やチームと話し合い常に状況に合わせて見直します。
見積もりはチームがプランニングポーカーなどの方法で行い、PBIに付与します。

f:id:yasuo99:20120527121152p:plain

既存のユーザストーリへの変更やチームからの改善提案は、一つ一つの規模が小さすぎる場合があります。アジャイルソフトウェアエンジニアリングのP.29にバグに対して粒度が小さいものをまとめてPBIとする工夫について解説されています。私はその方法を参考にして、フィードバックや改善提案でとても粒度が小さいもの同士をまとめて1つのPBIとすることがあります。

ここまで読んで気づいた方もおられるかもしれませんがこの運用方法では、PBIに「ユーザストーリそのもの」「ユーザストーリへの変更」が混在します。
TFS(他のツールでも同じだと思います)では、PBI間に親子関係などの関連付けを行う機能があるのでユーザストーリとして、どのような要素があるかを整理するために活用できると思います。(私はまだやっていません)
ユーザストーリマッピングのようなやり方をTFS上でうまく運用できればいいな、と思っていますので、今後試してみようと思っています。
ここで書いた方法は、一例に過ぎませんので、皆さんのチームにとって良い方法を考えていただければと思います。
アジャイルソフトウェアエンジニアリング」をお読みの方は、今回紹介した部分を是非読んでいただき、プロダクトバックログについて考えたり、周りの方々を話し合っていただけると嬉しいです。

Amazon.co.jp: アジャイルソフトウェアエンジニアリング ~ 基本概念から継続的フィードバックまで (マイクロソフト関連書): Sam Guckenheimer, Neno Loje, 日本マイクロソフト監訳, TFSUG監訳, トップスタジオ: 本