InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

スプリント計画:ストーリーポイント VS 作業時間

作者 Vikas Hazrati , 翻訳者 吉田 英人 投稿日 2009年9月28日

セクション
プロセス/プラクティス
トピック
Agile ,
アジャイル技術
タグ
プランニング

原文(投稿日:2009/09/22)へのリンク

スプリント計画にストーリーポイントと作業時間のどちらを用いるかについて,決着の付かない議論が長く続いている。どちらの陣営も,自分たちのアプローチが相手より優れているとする根拠をいくつも持っているようなのだ。Mike Cohn 氏が ユーザストーリーをタスクに分割して,それを元に時間見積を行う方法を好んで使用すれば,それに対して Jeff Sutherland 氏が 氏自身が関わった最高のチームでストーリーポイントを使ってバーンダウンを行った例をあげる。他にも多くのアジャイリストたちが,自らの好む方法とその理由について意見を表明している。

Mike Cohn 氏はスプリント計画でストーリーポイントを使用することを好んでいない。ストーリーポイントがどちらかと言えば長期的な測定基準であって,短期作業には向かないと考えているからだ。彼の意見では,

シーズン中盤のバスケットボールチームを想定してみましょう。チームはこれまで41試合で平均98得点をあげています。彼らが「今シーズンの残りゲームでも平均98点は得点できるだろう。」と思うのは適当かも知れません。でもある試合の前に「僕らの平均得点は98点だから,今夜も98点取れるさ。」と考えるのは間違っています。

これが作業速度は長期的な予測因子としては使えるが,短期的な予測には不向きである,と私が考える理由です。

Tara Lee Whitaker 氏はこの意見に反対で,ストーリーポイントを短期的な測定方法であると考えている。彼女によれば,

個々のストーリーが‘正確に’見積するのに十分に小さく,かつテスト確認書を作成できるだけのテスト性を持っているならば,それをより小さな部品にブレークダウンしたり,時間単位で再度見積を行ったりしても,大した利益は得られないでしょう。

しかし,ストーリーを時間で見積ることに関して大きな懸念を持っている点では,意見が一致していて,

時間でバーンダウンするアイデアについて私たちが最初に議論したとき,私が心配に思ったことが主に2つあります。ひとつはバーンダウンが示す早期警告サインを利用できなくなるのではないか,という点,もうひとつは問題に気づくのが遅れたときに,あるストーリーが予想より多く時間を費やしたこと以外何も発見できないのではないか,という点です。

Jim Schiel 氏はストーリーポイントと時間の両方でスプリント計画を行うことは可能かも知れないと考えている。しかし時間単位での見積への投資に対する見返りは,それを重要な実行候補にするほど高くはない。彼の意見では,

2ストーリーポイントからなる PBI(Product Backlog Item) を10個処理する Scrum チームを考えてみましょう。作業がすべて完了すれば,彼らはスプリントあたり 20 ストーリーポイントの作業速度を達成したことになります。彼らは次のスプリントでも 20 ストーリーポイントを目指すでしょう。けれどもそのスプリント中に何かが起きて,多少大きくなったり小さくなったりするかも知れません。このようなことがスプリントごとに繰り返されて,チームの作業速度の平均は18~22あたりになるでしょう。

時間見積でこれと同じことができるでしょうか? 答えはYESです。しかしそれを実現するには相当な費用が必要になるはずです。完成して動作するソフトウェアと非常に正確な見積,あなたならどちらにお金を払いたいと思いますか?

Jack Milunsky 氏もストーリーポイントの重要性を主張して,次のような利点をあげている。

  • 普遍的測定値 – ストーリーポイントはチームを越えた共通の測定値である。経験やスキル,チームの個人によって振れることはない。
  • 安定した状態 – 3つないし4つのスプリントをこなせば,チームは安定した状態になり,プロダクトオーナがバックログに安定した状態のストーリーポイントを詰め込むのも簡単になる。それだけのことだ。
  • ゾーンに入る – チームが一度安定すれば,ビジネスは技術チームを信用する。これがチームを高いモチベーションと自信のゾーンへと押し上げる。

Tomas Björkholm 氏はストーリーポイント方式を推進する理由として次のものをあげた

  • 理由その1,見積はストーリーのサイズを述べるものであって,実装に掛かる時間を表すものではない。
  • 理由その2,人日のサイズはチームのパフォーマンスによって変わるものだ。ストーリーポイントはより一定している。
  • 理由その3,相対的な見積が絶対的なものよりも正確であることは証明されている。人日は時間測定値なので,相対的に使用することが可能ではあっても,絶対的な見積により向いている。

さらに加えて,

Pomodoro Technique に関するスピーチで Staffan Nöteberg 氏は,多くの人々が見積を実時間で算出することを不快に感じていると語っています。私だってそうです。不快な気持ちの人の生産性は低いから,人日での見積もりは非生産的なのです。

Mike Cohn 氏はストーリーポイントと時間数の間に線形相関関係がないことを指摘している。氏によれば,各ストーリーごとに標準偏差の倍数を基本とした分布範囲があるという。

1ポイントは x の平均と標準偏差の倍数の分布に等価です。当然2ポイントのストーリーにもこれが当てはまりますし,それ以降も同じです。

そのために,ストーリーポイントで計測された作業速度が既知であったとしても,チームが仕事を完了する日を特定してステークホルダーに告げることはできない。範囲が必要なのだ。

ここで範囲と呼ぶのは,「プロダクトバックログのすべての項目を完了することができます。ただし完了するのは5月か6月頃でしょう。」というような日付範囲の場合もあれば,「ご希望どおり5月20日に完了します。それまでにプロダクトバックログのここからここまでにあたる,120~140の範囲内のどこかの数のストーリーポイントを獲得できるでしょう。」というスコープ範囲の場合もあります。

Mike Cohn 氏はまた,ある意味リーン主義の一種である comminent-driven sprint planning (責任駆動スプリント計画) とでも呼ぶべき別の手法を提唱もしている。このアプローチでは,チームはストーリーポイントや作業速度については議論しない。彼らは単にバックログタスクから高い優先度の項目を取り出し,彼らの生産能力ごとに時間で見積る。それから自身の責任を果たすのだ。

このようにスプリント計画については,どちらの技法にも賛否両論がある。結局はチームが納得できる方法に落ち着くことになりそうだ。あなたの好みはどちらだろう,そしてその理由は?

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。