Scrumやってて良いなぁと感じること

現在、担当しているプロジェクトをScrumによって管理しているのですが、Scrum良いなぁ！と実感できているポイントをいくつかメモっておきます。

短期的なゴールが明確になる

Scrumではタスクベースではなく機能ベースでスケジュールを組みます。そしてその機能は顧客にとって価値のあるものでないといけません。（ちなみに私はここを説明するとき、「実装後に顧客にテストプレイしてもらって、おっ、いいじゃん！て思ってもらえる単位」として説明しています。）そうすると、イテレーション終了時のテストプレイで動作していないといけない、という明確な短期的ゴールができるのでチームに緊張感が生まれます。

バーンダウンチャートで危機感が明らかにできる

ちょっと前は、プロダクトオーナー系のタスクをなんでイテレーションのタスクにしてはダメなのか分かってませんでした。しかし、その理由が今ははっきり分かります。Scrumにおいては、イテレーション内で機能を実装しきることに最大限の価値を置くので、それ以外のタスクが混ざっててバーンダウンに入っていると、現在のチーム状況がわかりにくくなってしまうんですね。
例えば、イテレーションで定義した機能を完全に実装し切るまでのタスクが100時間分だったとして、そことは直接関係ない機能のユーザーストーリーの作成に30時間かかると考えているとします。この状況だと、仮にバーンダウンチャート上で理想時間から30時間オーバーしたとしても、その30時間がユーザーストリーの設計分であれば機能の実現には直接関係ないよね、ということになってしまいます。これはバーンダウンチャートが予定線よりも上になっているイコールやばくてなんとかしなくてはいけない、という危機意識を削ぐ結果になります。

機能をストーリーポイントで管理することで、スケジュールにおけるチームの能力とタスクの量の変化を別々にトラッキングしやすい

例えばリリースまでのストーリーポイントの合計が100だったとします。そしてチームの速度が10。これだとリリースまで10イテレーションかかることになります。1イテレーションが2週間だとすると、20週間です。このように管理していれば、例えばチームが新しいツールを採用して速度が15になればストーリーポイント数は変わらないけど、速度が早くなってスケジュールが短期化します。そして機能を20ストーリーポイント分削れば、量を削ってスケジュールが短期化します。
もし見積もりをストーリーポイントではなく、例えば人月で計算していたらどうでしょうか？人月合計が100人月だったとしましょう。そして5名体制の開発だったとすると、20ヶ月かかるという見積です。ここで先ほどと同じようにチームが新しいツールを採用してスピードアップしたとすると、人の数は増えていないので人月見積もりを変える必要があり、例えば80人月になります。次に実装する機能を絞り込んだ場合、これも人月が少なくなります。そのため、当初見積もりよりも変わった理由が見積もりの変化によるのかチームの能力変化によるのかわかりにくくなります。