翻訳記事

本記事は、Manage It! の Johanna Rothman さんの「Thinking About “Beating” a Team’s Goal」の日本語翻訳です。翻訳にあたっては、Johanna さんに快諾いただいております。

サイクルタイムとベロシティ

記事「ベロシティではなくサイクルタイムで計測する」(訳注: 翻訳済み)について ショーンからコメントをもらいました。それは、「サイクルタイムとベロシティの両方を計測した方が、チームにとってより良いのではないか」という意見でした。これには2つの理由があります:

  • 前回のスプリントゴールを「達成する」ため
  • 作業がいつ完成するのか、PO が予測する手助けのため

これらの考えについて、検証していきましょう。

ストーリーポイントの明確化

なぜストーリポイントを気にするのでしょうか?

もし、あなたが「Essential XP: Card, Conversation, Confirmation」のような原案を読んだことがないなら、ぜひ読んでみてください。

ストーリーをカードに書くときは、ひょっとしたらフレーズとしてだけ書いているかもしれません。会話はストーリーを肉付けします。また、複雑さを理解するのに役立ちます。それから、ストーリーの受け入れ基準とテストを作ることができるので、ストーリーを理解しているかどうかを確認することができます。これで、ストーリーの意図を理解でき、受け入れ基準をえることができるのです。

チームが、一度に1つのプロジェクトにのみ取り組んでいる頃は、ストーリーポイントで見積もることに意味がありました。なぜストーリーポイントなのでしょうか?

  • ポイントは、ストーリーの複雑さ、すべてのテストがどれくらいの作業量になるか、ストーリーの問題点について、チームメンバーが議論するのに役立つ
  • ポイントは、チームメンバーが大中小のストーリーを区別するのに役立つ
  • ポイントは、1回のイテレーションでどれだけのことができるのかを見積もる方法として用いることができる(イテレーションがチームのために機能する前提)

昨今では、1つのプロダクトのストーリだけではなく、さまざまな仕事に取り組むチームが増えてきています。ストーリーポイントの有用性は低くなってきていると感じています。フィーチャーセットやプロダクトをまたいでストーリーポイントを比較することは難しいわけです。1日かそれ以下のストーリーがない限りは、それらを普段に見かけることはないです。

ポイントはアウトプットであることに注意してください。完成したストーリーはアウトカム(成果)です。

アウトプットよりアウトカム

アウトプット指標は、その場で(その瞬間で)役に立ちます。しかしながら、アウトプットは必ずしも顧客に価値を提供するとは限りません。

例えば、私は、毎日の歩数をアウトプットの指標として使っています。これはとても役に立ちますが、健康であるために必要なのはこれだけではありません。

ストーリーポイント対フィーチャーコンプリート

上図では、2つの指標のバーンアップチャートを示しています。

  • 累積ストーリーポイント(赤色): 6
  • 完成したストーリー数(青色): 2

ポイントは興味深いですが、十分ではありません。なぜこのチームは2つしかストーリーを完成できなかったのでしょう。また、イテレーションの終盤にしか完成しないのでしょうか。これはとても興味深いです。

完成したストーリーは、アウトカムです。完成したストーリーは、誰かに価値を提供しています。

もし、イテレーションにおけるストーリーポイントの数を増やしたいならば、そのイテレーションでのストーリーの数も増やして欲しいものです。そうでなければ、アジャイルスケジュールゲーム(agile schedule game)をしていることになります。「ベロシティを倍にする」、「みんなでそれぞれのストーリに取り掛かる」、「もっともっとできるはず」といったことが起こりえます。

確かに、より多くのポイントをこなしていくことはできます。ポイントはアウトプットです。より完成した価値を提供できていますか?完成したストーリーは、アウトカムになっていますか?

ストーリーポイントを用いて予測できるか?

ぜひ、「Estimation and Forecasting」を読んでみてください。私のお気に入りのポイントのスケールは、以下です。

  • 1
  • 大きすぎる (too large)
  • わからない (no clue)

これは、Pawel Brodzinski が開発したスケールです。

紹介した記事の中では、Larry Maccherone は、「ストーリーを数えることは、ストーリーポイントと同じように効果的である」と述べています。私の経験では、(訳注: ストーリポイントより、ストーリーを)数えることの方がより効果的です。サイクルタイムの計測もそうです。

どのような見積もりが必要なのかも聞いてみたいところです。でもそれは、全く別の議論です。

以前に、「Create Your Successful Agile Project」にて、サイクルタイムとストーリーのカウントによる見積もり方法について書きました。また、「Predicting the Unpredictable」では、全般的な見積もりについて書きました。

もしかしたら、「ストーリーポイントが予測可能性を高めない」という私の主張を信じられないかもしれません。この場合は、実験を考えてみましょう。

十分なデータがあるという前提で、次の2回のイテレーションのために、以下の項目を追跡します:

  • 1イテレーションでコミットする1ストーリーあたりのストーリーポイント数
  • これらのポイントが示すストーリーの数
  • 1イテレーションで完成するストーリーの数
    上図のようなバーンアップでの追跡を推奨
  • それぞれのストーリーの所要時間(サイクルタイム)
  • イテレーションの終盤にどれくらいの WIP (仕掛かり作業) はあるか
    未完了の作業のことです。ポイントを消化できたことにはなりません。部分的なものは認められません。

上記について十分なデータが集まったら、以下の質問に回答してみてください:

  • チームにとって、ストーリーの数は、ストーリーポイントと同じように役に立ちますか?
  • サイクルタイムに着目したことによって行動変容はありましたか?
  • このデータ収集していることにより、WIP は増えましたか?減りましたか?

私には、あなたの現場で何が気づきになるかはわかりません。だからこそ実験なのです。

以前のデータを達成する気持ちよさとは?

私は達成感についてわすれているわけではありません。ポイントは、アウトプットなので、チームには、ベロシティではなく、WIP とサイクルタイムの追跡に移行することをお勧めします。

When Teams Don’t Finish Work in a Sprint: 3 Tips to Seeing and Finishing Work」では、累積フローチャートについて解説しています。

私が(あらゆるレベル感で)コーチをするときには、チームが望むアウトカム(成果)に集中してもらうようにお願いしています。そして、これらのアウトカムを達成するために必要なサイクルタイムにも集中してもらうようお願いしています。だっからこそ、マネージャーには、意思決定期間について尋ねます。意思決定の課題 – マネージャーの意思決定により、他の人のアウトカムが達成できることになります。

チームのサイクルタイムを短縮することができればするほど、チームは自分たちに達成感や自信が持てます。アウトカム(成果)を生み出すためにチームはより速く行動するようになります。

重要な指標はどれか?

ストーリーポイントでいうところのベロシティは、アウトプットの指標です。もちろん、それはチームがトラブルを抱えていたり、チームが協働して何かに取り組んでいたり、ビルドやテストの自動化するためのチームの努力が報われたりを示す良い兆候になるかもしれません。

ベロシティは、アウトカムではありません。

あなたのチームにとって重要なアウトカム(成果)は何でしょうか?それらを計測する方法を見つけ出しましょう。そしてそれらのアウトカムをより速く達成できるかどうかを確認しましょう。それが、チームの目標を達成する方法です。

ショーンさんのとてもよい質問に感謝します。

(昼食後に追記)
言い忘れていました。ストーリーポイントは期間の代用であり、日付の代用にはなりません。もし日付が欲しいのならば、サイクルタイムを使ってみてください。期間を予測したいのならば、私はやはり、サイクルタイムの方がより価値のある道具であると考えています。

本記事の翻訳者:

長沢智治

長沢 智治 – アジャイルストラテジスト

サーバントワークス株式会社 代表取締役。Helpfeel Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。

DASAプロダクトマネジメント認定トレーナー
DASA DevOpsファンダメンタル認定トレーナー

『More Effective Agile』、『Adaptive Code』、『今すぐ実践!カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。

Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。

プロフィール