ブログ

みなさんこんにちは。@ryuzeeです。

プロダクトオーナーやプロダクトバックログに関してよく頂く質問についてまとめました。 スクラムではフレームワークとして定義されているものをどのように実装するかはスクラムチームに任されているので以下の僕の回答はあくまで僕個人の見解です。

プロダクトバックログにはバグは乗せないのか？

A. スプリントの作業の一環として行ったテストで発覚したバグは載せません。

それは単にスプリント内で解決すべき項目であり、バグが残っている状態ではプロダクトバックログアイテムが完了とならないだけだからです。 既にリリースされているもののバグであればプロダクトバックログに載せて、対応の順位付けをします。 ただしプロダクトバックログに載せるまでもなく、すぐ修正が終わるようなものはとっとと終わらせてムダに追跡をしない方がよい場合も多いでしょう。

スプリントプランニング時にデザインができていないと見積もれないアイテムもある。そしてそのデザインは数日かかるようなものもある。その場合、すぐに見積りができないがどうしたら良いか？

A. スプリントに入るためにはReadyなプロダクトバックログアイテムが用意されていなければいけません。

したがってまだ見積りできないというのはReadyではないので、前のスプリントのうちに画面の遷移を考えたり、受け入れ基準を考えたりといった準備をしてください。 これはプロダクトバックログリファインメントと呼びます。 また実装の方法としてUIとロジックをなるべく分離するようにしておき、デザインは後から考える手もあります。

プロダクトオーナーと開発チームは同時にできる？

A. 可能。

ただしプロダクトオーナーの大事な役割は開発チームの進む先を示したり、製品に関する責任をとったり、利益を最大化するようにすることなので、開発者のロールを兼任することで、その責任が果たせなくなるようであればやってはいけません。 またプロダクトオーナーが開発者を兼任すると、スプリント中に要求変更の割り込みをかけやすくなってしまうので、どの帽子をかぶっているかを常に意識する必要もあります。

狩野モデルの「L･･･Linear(性能) なくても良いが、あればあるほど良い」とは？

A. 狩野モデルはあくまで多くの要求があった場合に、実現するかしないかを考えるためのツールです。 ここで有効なのは、作ってはいけないものがはっきりすること、絶対に必要なものがはっきりすることであって、残りはプロダクトオーナーを中心にして優先順位を決めれば良いでしょう。

スプリントプランニングでスコープを決める際、過不足なくがベストなのは分かるがそれが分からない場合、感覚的に少なめが良い？多めが良い？

A. ベロシティを基準に考えます。

前回のスプリントで20ポイント分できていれば、今回も20ポイントを基準にして計画します。 そのスプリントに入りきらないプロダクトバックログアイテムは分割してベロシティ内に抑えるようにします。 自分たちの能力を超えて多くをやろうとすると、目に見えないところを端折ったり（たとえばリファクタリングとか）テストの量を減らしたりとかしてでも全部を終わらせようという力が働きやすいのでムリのない計画を行います。 早く終わったときのために、その分もスプリントプランニングの中で準備をすることがあります。 はじめてのスプリントの場合は、一般的に多くやりたいと思ってもだいたいできないので、かなり少なめに設定することをお勧めします（ベロシティ0もざらにあります）。

他に質問があれば遠慮なくご連絡ください。

それでは。