The secrets behind story points and agile estimation

見積もりが上手であれば、プロダクトオーナーは効率と効果を最適化できます。だからとても重要なのです。 

Dan Radigan Dan Radigan

Estimation is hard. For software developers, it's among the most difficult–if not the most difficult–aspects of the job. It must take into account a slew of factors that help product owners make decisions that affect the entire team–and the business. With all that at stake, it's no wonder everyone from developers to upper management is prone to getting their undies in a bunch about it. But that's a mistake. Estimation is just that: an estimate. Not a blood-oath. 

作業工程の過小評価を埋め合わせるために週末に仕事をすることは、前提条件ではありません。そのためにも、見積もりを可能な限り正確に行う方法をいくつか検討してみましょう。  

プロダクトオーナーとのコラボレーション

In agile development, the product owner is tasked with prioritizing the backlog–the ordered list of work that contains short descriptions of all desired features and fixes for a product. Product owners capture requirements from the business, but they don’t always understand the details of implementation. So good estimation can give the product owner new insight into the level of effort for each work item, which then feeds back into their assessment of each item's relative priority.

通常、エンジニアリングチームが見積もりを開始すると、要件とユーザーストーリーに関する問題が生じます。これは良いことです。こうした問題は、チーム全体が作業をより完全に理解するのに役立つからです。特に、プロダクトオーナーの場合、作業項目の細分化と見積もりによって、作業の全ての領域 (潜在的に隠れているものも含めて) の優先順位を付けることができます。開発チームの見積もりが出てしまえば、プロダクトオーナーにとってバックログでの項目の並べ替えは珍しいことはではありません。 

アジャイル見積もりはチームスポーツ

あらゆる人 (開発者、デザイナー、テスター、デプロイメント担当者など) をチームに参加させることが鍵です。各チームメンバーは、製品に対する様々な観点とユーザーストーリーを実現するために必要な作業を挙げます。たとえば、製品管理チームが新しい Web ブラウザーのサポートのような、単純に見える何かを行いたいと提案した場合、開発および QA チームは、表面に見えるものの陰に怪物が潜んでいる場合があることを経験上知っているため、その議論に加わる必要があります。同様に、設計変更には、デザインチームの意見だけでなく、開発および QA チームの意見も取り入れる必要があります。広範な製品チームの一部を見積もりプロセスから外してしまうと、低品質の見積もりが作成されることになり、重要な貢献者に当事者意識が生まれないため士気が下がり、ソフトウェアの品質に関して妥協を余儀なくされます。

チームとは無関係に作成される見積もりによってチームに犠牲を強いてはいけません。そのような見積もりは失敗への近道です。 

ストーリーポイント VS 時間

従来のソフトウェアチームは、日数、週数、月数という時間数で見積もりを提供します。しかし、多くのアジャイルチームはストーリーポイントへ移行しています。ストーリーポイントは、 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 のように、フィボナッチ数列に似た形式で作業の相対的労力を評価します。直感的にわかるものではないように聞こえるかもしれませんが、この抽象化は、作業の難しさを中心にしてチームに厳しい決断を下すよう促すので、実際に役立ちます。以下に、ストリーポイントを使用する理由をいくつか示します。

  • 日付は、日常で必然的に生じるプロジェクト関連外作業を考慮に入れていません。このような作業には、E メール、ミーティング、面接などがあり、チームメンバーが関わっている場合があります。
  • 日付で見積もると日付に執着してしまいます。相対的見積もりは、この執着を取り除きます。
  • 各チームは作業を微妙に異なった規模で見積もります。つまり、速度 (ポイントで測定される) が必然的に異なってきます。このため、速度を武器として使用して策を弄することは不可能になります。

ストーリーポイントから開始するチームは、プランニングポーカーという方法を使用します。Atlassian では、プランニングポーカーは全社的によく行われています。チームはバックログから項目を取り上げて少しの間話し合い、各メンバーは心の中で見積もりを立てます。次に、メンバーは一斉に数字が書かれたカードを上げて、各自の見積もりを示します。全員が一致していれば申し分ありません。一致しない場合、しばらくの間 (といっても、長すぎてはいけません。数分です)、様々な見積もりの根拠について話し合います。ただし、見積もりはハイレベルのアクティビティであることを忘れないでください。チームが枝葉末節にとらわれすぎていたら、深呼吸をして、概要レベルの議論に戻します。

見積もりがスマートになるほど楽になる

個々のタスクは、作業が 16 時間を超えないようにしてください。(ストーリーポイントを使用している場合、たとえば、上限を 20 ポイントとします。) これより規模が大きいと、高い信頼度で個々の作業項目を見積もることが非常に困難になるだけです。その信頼性がバックログの最優先項目では特に重要です。チームの 16 時間 (または 20 ポイント) の閾値を超える見積もりがある場合、それをさらに細分化して見積もりをやり直す必要があることを示しています。

バックログ内のより深いレベルにある項目については、大まかな見積もりをします。そのような項目は、作業を実際に開始する頃には要件が変化している場合があり、アプリケーションは確実に変わってしまいます。したがって、事前見積もりでは正確さを求めすぎないようにします。変化する可能性のある作業の見積もりで時間を無駄にしてはいけません。プロダクトオーナーが製品ロードマップの優先順位付けを適切に行うために使用できる程度の概算見積もりを提供してください。

過去の見積もりから学ぶ

Retrospectives are a time for the team to incorporate insights from past iterations–including the accuracy of their estimates. Many agile tools (like Jira Software) track story points, which makes reflecting on and re-calibrating estimates a lot easier. Try, for example, pulling up the last 5 user stories the team delivered with the story point value 8. Discuss whether each of those work items had a similar level of effort. If not, discuss why. Use that insight in future estimation discussions.

アジャイルにおけるあらゆる事柄と同様に、見積もりは訓練です。実践を重ねることによって上達します。 

Up Next
指標