ストーリーポイントと見積もり

見積もりが上手であれば、製品所有者は効率と効果を最適化できます。だからとても重要なのです。

無料の Jira スクラム テンプレートを開始する

プロジェクトを合理化して、複数のスプリント全体の作業を簡単に計画、追跡、管理しましょう。このテンプレートには、ボード、バックログ、ロードマップ、レポートなどが含まれています!

重要ポイント

  • ストーリー ポイントは、アジャイルにおける相対的な見積もり方法であり、チームがバックログ アイテムにおける労力、複雑さ、リスクを評価するのに役立ちます。

  • ストーリー ポイントを使用することで、時間単位での管理に比べて、チームのコラボレーションが促進され、感情的な偏りが減少し、予測の精度が向上します。

  • プランニング ポーカーやふりかえりなどの見積もり方法により、チームは時間をかけてプロセスを調整して改善できます。

  • 定期的な見積もりを実施し、過去の見積もりのレビューを行うことで、今後の作業における精度とチームの連携を改善できます。

見積もりは困難です。ソフトウェア開発者にとって見積もりは、さまざまな業務の中で最も困難なものとは言わないまでも、困難であることは確かです。チームやビジネス全体に影響を及ぼす製品所有者の意思決定に役立つ、多数の要因を考慮する必要があります。いずれも見落とせないため、開発者から管理上層部に至るまで、誰もが些細なことで不安を感じても不思議ではありません。しかしそれは間違いです。アジャイル ストーリー ポイントの見積もりは見積もりにすぎません。最終決定ではありません。

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

ストーリー ポイントとは

ストーリー ポイントは、アジャイル見積もりで使用される測定単位であり、ユーザー ストーリーやタスクを完了するのに必要な相対的な工数を表します。ストーリー ポイントでは、具体的な時間や日数ではなく、複雑さ、リスク、作業量を考慮します。

チームは、蓄積された経験と他のストーリーとの比較に基づいてストーリー ポイントを割り当てます。多くの場合、プランニング ポーカーなどの手法を利用します。たとえば、簡単なバグ修正には 1 ポイント、複雑な機能には 8 ポイントを割り当てます。このアプローチにより、チームは作業を一貫して見積もり、スプリントをより効果的に計画できます。

ストーリー ポイントに影響を与える要因

ストーリー ポイントに影響を与える要因には、作業の複雑さ、必要な工数、潜在的なリスク、依存関係や未知の要素などがあります。チームは、類似したタスクを過去に見積もって完了した方法も考慮します。

たとえば、新しい API との統合では、なじみのなさや潜在的な技術的課題のために、ストーリー ポイントの値が高くなる可能性があります。ストーリー ポイントの見積もりを定期的にレビューし、調整することで、チームは一貫性を維持し、時間の経過とともに予測の精度を向上させることができます。

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

アジャイル開発では、プロダクト所有者バックログの優先順位付けを任されています。バックログとは、製品に必要なすべての機能と修正に関する短い説明を含めた順序付きの作業リストです。プロダクト所有者は業務部門から要件を収集しますが、必ずしも実装の詳細を理解しているわけではありません。したがって、優れた見積もりがあれば、プロダクト所有者は各作業項目の労力のレベルについて、新たな洞察を得ることができ、この洞察が各項目の相対的優先度に関する判断に反映されます。

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

アジャイル・ストーリー・ポイントの見積もりはチーム・スポーツです

あらゆる人 (開発者、デザイナー、テスター、デプロイメント担当者など) をチームに参加させることが鍵です。各チームメンバーは、製品に対する様々な観点とユーザーストーリーを実現するために必要な作業を挙げます。たとえば、製品管理チームが新しい Web ブラウザーのサポートのような、単純に見える何かを行いたいと提案した場合、開発および QA チームは、表面に見えるものの陰に怪物が潜んでいる場合があることを経験上知っているため、その議論に加わる必要があります。

同様に、設計変更には、デザインチームの意見だけでなく、開発および QA チームの意見も取り入れる必要があります。広範な製品チームの一部を見積もりプロセスから外してしまうと、低品質の見積もりが作成されることになり、重要な貢献者に当事者意識が生まれないため士気が下がり、ソフトウェアの品質に関して妥協を余儀なくされます。

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

ストーリー ポイントをお試しください。まずは、Jira にサイン アップまたはログインします

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

従来のソフトウェア チームは、日数、週数、月数という時間表記で見積もりを提供します。しかし、多くのアジャイル チームはストーリー ポイントに移行しています。ストーリー ポイントは、プロダクト バックログ項目またはその他の作業を完全に実装するために必要な労力全体の見積もりを示す測定単位です。チームは、作業の複雑性、作業量、リスクまたは不確実性に関連するストーリー ポイントを割り当てます。値は、より効果的に小さなサイズに分割するよう割り当てられるため、チームは不確実性に対処できます。これにより、時間とともに、チームが一定の期間で達成できる量を把握し、ソリューションへの合意とコミットメントを形成できます。直感的に分かるものではないように聞こえるかもしれませんが、この要旨によってチームが作業の難しさを基準にして厳しい決断を下すようになるため、実際に役立ちます。以下に、ストーリー ポイントを使用する理由をいくつか示します。

  • 日付は、日常で必然的に生じるプロジェクト関連外作業を考慮に入れていません。このような作業には、E メール、ミーティング、面接などがあり、チームメンバーが関わっている場合があります。

  • 日付で見積もると日付に執着してしまいます。相対的見積もりは、この執着を取り除きます。

  • 各チームは作業を微妙に異なった規模で見積もります。つまり、速度 (ポイントで測定される) が必然的に異なってきます。このため、速度を武器として使用して策を弄することは不可能になります。

  • 各ストーリーポイント値の相対的労力について合意したら、議論を重ねることなくポイントをすばやく割り当てることができます。

  • ストーリーポイントでは、問題解決の所要時間ではなく、難易度に基づいてチームメンバーを評価します。これにより、チームメンバーは時間をかけることではなく価値を生み出すことに集中できます。

残念ながら、多くの場合、ストーリー ポイントは誤用されています。人の評価、詳細なタイムラインやリソースの割り当てにストーリー ポイントを使用したり、ストーリー ポイントを生産性の測定単位と誤解したりすると、うまくいきません。代わりに、チームは作業のサイズや作業の優先順位を把握するためにストーリー ポイントを使用する必要があります。ストーリー ポイントと見積もりの実践に関する詳細な説明については、こちらの業界のエキスパートとの円卓会議をご覧いただき、アジャイルな見積もりの詳細なヒントをご確認ください。

時間ではなく、ストーリー ポイントを使用する理由

ストーリー ポイントは作業の相対的な規模と複雑さに重点を置いているため、正確な時間の見積もりに関する議論を減らし、不確実性を考慮します。そのため、時間ではなく、ストーリー ポイントを使用します。この手法により、チームは期間だけでなく、工数とリスクについても考えるようになります。

ストーリー ポイントを使用すると、チームはより適切にスキル レベルの違いに対応し、過小評価や過度な負担を負ってしまう潜在的な落とし穴を回避できます。たとえば、2 人の開発者が同じストーリーを異なる時間で完了する場合でも、ストーリー ポイントの値は一貫しているため、スプリント計画が予測しやすくなります。

ストーリーポイントとプランニングポーカー

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

お試しの準備はできましたか? 

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

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

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

過去の見積もりから学ぶ

ふりかえりはチームが過去のイテレーションから知見を得る時間です。これには、チームの見積もりの精度も含まれます。多くのアジャイル ツール (Jira など) は、ストーリー ポイントを追跡します。このため、見積もりの熟考と再調整が非常に容易になります。たとえば、チームがストーリー ポイント値 8 で実現した直近の 5 つのユーザー ストーリーを取り上げて、それぞれの作業項目の労力は同じようなレベルだったかどうかを話し合います。違っていた場合は、その理由について話し合います。そこで得た知見を今後の見積もりの議論に活用します。

アジャイルにおけるあらゆる事柄と同様に、見積もりは実践です。回数を重ねるごとに上達します。

推奨

テンプレート

すぐに使える Jira テンプレート

さまざまなチーム、部門、ワークフロー向けのカスタム Jira テンプレートのライブラリをご覧ください。

製品ガイド

Jira の包括的な概要

この段階的なガイドで重要な機能やベスト プラクティスを確認し、生産性を最大化しましょう。

Git ガイド

Git の基本を理解する

初心者から上級者まで、この Git ガイドを活用して、役立つチュートリアルやヒントで基本を学ぶことができます。