プロジェクトのストーリー ポイントを見積もるにはどうすればよいですか?

アジャイル プロジェクトに取り組む場合、チームはストーリーを作成して今後のスプリントの作業を計画します。ストーリーは、説明と受け入れ基準を備えた単一の機能をカプセル化したアクティビティを定義します。

通常、スプリントは 2 ～ 4 週間続きます。その時間内で、チームは、指定されたスプリント時間内に完了できるように、1 つのスプリントにどれだけのコンテンツを含めることができるかを理解する必要があります。

非アジャイル プロジェクトの場合、作業は通常人日で見積もられます。つまり、この活動を完了するにはフルタイムの従業員が何人必要になるでしょうか?その場合、必ず日数や人数を考えて見積もりを作成します。

アジャイルプロジェクトでは事情が異なります。最終的な見積もりを計算するために日数や人数をカウントする必要はなくなりました。実際、人日などの労力を計算することさえ禁止します。代わりに、全体の見積もりを表す、ストーリーの一般的に受け入れられている 1 つの値にチームが変換できるようにします。

さて、値が正確に何であるかについては、それほど重要ではありません。確かに、ストーリー推定の最も一般的な代表はストーリー ポイントです。これらは基本的に、0、1、2、3、5、8、13、21 などから始まるフィボナッチ数です。次の値は前の 2 つの数値の合計です。次に高い数値は前の数値よりも大幅に大きくなるため、これはストーリー全体の複雑さを区別するのに役立ちます。

ただし、ストーリーのポイントに固執する必要はありません。 T シャツのサイズの目安 (XXS、XS、S、M、L、XL、XXL) になります。本当に創造力を発揮したい場合は、ZOO の動物を紹介し、大きさの推定に使用することができます。

いずれにしても、どの数字 (または動物) がこの特定のストーリー全体の複雑さを最もよく表しているかについては、チーム全体の感情がより重要になります。それは決して時間の表現に関するものではありません。最終的に、チームはスプリントに取り込まれた各ストーリーをそのスプリント内で完了する必要があります。したがって、時間は最初にすでに与えられており、定数です。

ストーリー ポイントの見積もりの​​構成要素

ストーリー ポイントの見積もりは、特定のストーリーがどれだけ複雑/困難であるかだけを考慮するものではありません。ストーリーを見積もるとき、チームはいくつかの側面を考慮し、それらを最終的な見積値に反映する必要があります。

最終的な推定値は、すべての側面を組み合わせて 1 つの数値にまとめられた値になります。そのような推定には次のようなものが含まれます。

#1. 技術的な難しさ

開発チームのストーリーを見積もっていると仮定すると、ストーリーの技術的な難しさは、デフォルトでチームが最初に集中する領域の 1 つになります。

そして、これは間違いなく正しいアプローチです。技術専門家で構成されたチームは、ストーリーのそのような領域を評価する方法を最もよく知っているはずです。ここでチームは、次のようなさまざまなアプローチやヒントを検討できます。

• 技術的な複雑さの観点から、このストーリーをすでに提供されている他のストーリーと比較するとどうなるでしょうか?
• ストーリーを完了するために、チームはいくつのコード ファイルを作成/更新する必要がありますか?
• このストーリーにより、周囲のシステム プロセスにさらにコード変更がいくつ発生するでしょうか?
• 実装するアルゴリズムまたはプロセス ロジックはどれくらい複雑になりますか?

#2. 外部依存性とリスク

驚く人もいるでしょうが、多くの場合、チームのスプリント内のストーリーの成功は、他のチームやチーム自体の外部からの貢献に依存しています。

チームが単独ですべてを達成できるストーリーは、見積もりが最も簡単です。チームがストーリーを作成するために外部の助けが必要な場合、事態は複雑になります。チーム外の人々にとって、この活動は当然のことながら優先事項ではありません。チームはその要因を考慮し、見積もりの​​範囲内で考慮する必要があります。

この要因によって合計推定値がどの程度増加するかは、主にチームのこれまでの経験と「外部性のレベル」に依存します。通常、一部のスプリントでは、外部の人々への依存がストーリーの正常な完了をどの程度複雑にするかについて、チームは自然な統一感を確立します。

#3. 再利用性の要素

次に考慮すべき領域は、ストーリーを完了するためにチームが既存のコンテンツをどれだけ再利用できるかということです。明らかに、一部のパーツが何らかの形ですでに存在している場合、それを最初から構築する必要はありません。むしろ、チームは一度作成したソリューションを再利用して、より迅速に新しいソリューションを構築できます。

このように、この知識により、通常 (この再利用性がなければ) 定義されたコンテンツに基づいてストーリーがより複雑になる場合でも、合計の見積もりを下げることができます。

#4. 自チームへの理解

工数ベースの見積もりでは決して考慮できない注目すべき要素の 1 つは、チームの年功と能力についての自己認識です。

チームが協力して複数のスプリントを実行すると、チーム内の人々がお互いのことを知るようになります。彼らは、誰が何を知っているか、そしてその分野でどれほど優れているかを理解し始めるでしょう。そして、全員がチームの残りの部分を把握したら、見積もりの​​際にチームとして一緒にこれを検討することができます。

ストーリーが何らかの具体的な技術スキルに重点を置いており、そのスキルがチーム内に非常に強く存在している場合、ストーリーの実現はそれほど困難ではないことは明らかです。逆に、必要なスキルがチーム全体に不足している場合、チームはそのトピックに入るまでに大幅に時間がかかることになり、それを見積もりに反映する必要があります。

ストーリーの推定

各ストーリーの見積もりはチームで行う必要があります。単一の声によってストーリーの複雑さが事前に定義されるべきではありません。最終的な目標は、最終的な見積もりを表す 1 つの値にメンバー全員が同意するまで、チームで見積もりについて話し合うことです。

チームは、スプリント改良ディスカッション (チーム間でストーリーについて話し合って明確にする会議) 中に直接見積もりを行うことも、そのための専用時間を確保することもできます。

見積りの流れの例

1. チームが使用する推定ツール ( プランニング ポーカー 、ミロ ボードなど) を選択します。
2. ボードにストーリーを置きます。チームでストーリーに関する最終的な考えや質問について話し合いましょう。チーム全体がストーリーを十分に認識し、見積もりの​​準備ができていることを確認してください。
3. 見積もりを開始します。各チーム メンバーは、フィボナッチ スケールから数値を選択するように求められます。
4. すべての推定が完了したら、結果を一緒に確認します。ディスカッションを開始します。通常、チームは 2 ～ 3 つの番号の間で区切ります。下位の人々に、見積もりがこれほど低くなければならない理由を説明してもらいます。次に、相手側の担当者に、最終的な見積もりがなぜこれほど高くなければならないのかについて詳しく説明してもらいます。目標は、すべての議論、考慮事項、事実をテーブルに並べて、チーム全体がこのストーリーの内容を理解する上で同じ認識を持つようにすることです。
5. 話し合いが終わったら、チームに再度見積もりを出してもらいます。ほとんどの場合、チームは 1 つまたは 2 つの異なる番号に変換します。もう一度議論を繰り返します。具体的なケースに応じて、チームが 2 つの選択肢から最終的な数値に同意するか、別の見積もりラウンドを決定することになります。
6. チームメンバー全員が最終見積もりに完全に同意した場合にのみ、見積もりは終了します。それは一部の個人だけではなく、チーム全体の合意である必要があります。潜在的には、すべてのストーリーを後でチームの誰かに割り当てることができます。だからこそ、物語がどれほど複雑であるかについて全員が同意することが重要です。

スプリント計画のコミットメント

チームには現在、推定セッションをすでに経たストーリーのバックログが残っています。理想的には、ストーリーには (最終的な推定値とは別に) 優先順位も割り当てられているため、チームはどのストーリーが次のスプリントに次に入るのかがわかります。

ここで計画セッションが始まり、チームは次のスプリント用のストーリーをいくつか選択します。どのストーリーを選択するかは、次のことに基づいて決定する必要があります。

✅ チームが最初に考慮する優先度の高いストーリー。

✅ チームがスプリント内にいくつのストーリー ポイントを完了できるかという経験。この知識はチームの時間と経験によってのみ得られます。この機能を微調整して適切に理解するには、複数のスプリントが必要です。

✅ ストーリーの総ポイント数と優先順位だけを考慮すべきではありません。もう 1 つの考慮事項は、チーム内のスキルが選択したストーリー全体にどのように広がるかです。たとえば、チームにフロントエンド開発者が 2 人しかいない場合、フロントエンド開発のみで構成されるストーリーのみを選択することはできない可能性があります。そうなると、チームの残りのメンバーがそれほど活用されない一方で、2人を過剰に活用することになるだろう。したがって、チームの知識は、スプリント コンテンツ作成の有効性と密接に関係しています。

速度係数

何よりも重要なのは、(今後のスプリントに向けた) チームの速度です。この数値はストーリー ポイントの総量とはまったく関係ありません。ただし、これはチームが今後のスプリントの作業にどれだけ対応できるかを示します。

スプリントのコンテンツを正確に計画できるようにするために、両方の側面をまとめます。

1. チームのベロシティ – 日数で測定されます。チームの 1 人のメンバーが丸 1 日参加できるのは、チームのベロシティの 1 に相当します。たとえば、2 週間続くスプリントに完全に対応できる 10 人のチームは、チームのキャパシティ 100 に相当します。
2. スプリント内で完了する通常のストーリー ポイントの量 – ストーリー ポイントで測定されます。この数値はこれまでの経験から得られたもので、チームのベロシティと密接に関係しています。

スイートスポットを見つけるには時間と練習が必要です。

利点とよくある間違い

アジャイルなチームへの変革の過程で、チームが自分たちでプロセスをどれほど複雑化しようとしているかには驚くべきことです。そのモードで作業を開始する前に、文字通り「理解する」必要があるように感じます。

残念ながら、この最初のステップは最も難しいステップでもあります。場合によっては、特に厳格に保守的な企業環境では、時間だけが時間に追われてしまい、数年かかることもあります。

とにかく、チームが「理解」すると、次のことが起こります。

• 何かがいつ完了するかを知るために人や日数を計算する必要はもうありません。
• チームは、スプリント内に収まるようにできるだけ複雑なストーリーを作成する方法を学びます。ストーリーがより複雑な場合、自動的にさらに多くのストーリーに分割されます。
• チームは各作業について適切な見積もりを持っており、スプリントに向けて計画を立てれば、その期限が正確にわかります。
• チームの信頼性と予測可能性が高まります。
• チーム内の全員が「同じ周波数」になります。彼らは物語を見て、同じようなことを理解するでしょう。おそらく、しばらくすると、彼らは見積りすらしなくなるでしょう。彼らは頭の中で数字を認識しており、全員が同じ数字を認識しているため、この明示的な見積もりがなくても、スプリントでストーリーにコミットできます。

そして、チームがまだプロセスや作業方法を理解できない場合、通常、次のようなことが起こります。

• 彼らはどういうわけか、依然として昔ながらの工数見積もりに固執しています。すべてを日数や関係者に換算します。ストーリー ポイントまたはフィボナッチ数は、さまざまな変換を介して直接的または間接的に日数を意味します。
• リーダーシップは、各スプリントで提供されたストーリー ポイントの数に基づいてチームを比較します。これは考えられる限り間違いです。この場合、重要な事実は理解されていません。各チームがストーリーのポイントを異なる方法で推定しているということです。 2 つのチームを同期させて、それぞれのストーリーを「同じ方法」で推定する努力をする理由はまったくありません。
  • あるチームのストーリー ポイントは円を描くことを意味しますが、別のチームにとっては、平らな屋根、4 つの窓、2 つのドアを持つ家を描くことを意味する場合があります。そしてそれは全く問題ありません。
• 場合によっては、チームは 2 ～ 4 つの異なる数値の間でほとんどすべてを推定する傾向があります。おそらく、物語に 123 という数字が含まれることを恐れているため、誰かがそれが日数に関係があると考えるでしょう。しかし実際には、フィボナッチスケールには無限の数があります。推定値を 3、5、または 8 に限定する必要はありません。確かにそれは可能です (おそらく、そのような複雑になることを念頭に置いてストーリーを作成しているかもしれません。その場合はそれで問題ありません)。絶対にその必要はありません。
• 見積もりは、グループ全体の期待を事前に定義する上級者によって推進されます。チーム メンバーの 1 人が見積もりに影響を与えることは決して許すべきではありません。誰もが自分の意見を表明し、耳を傾けてもらう平等な権利を持っています。

最後の言葉

従来のアプローチからアジャイル推定に切り替えることは必ずしも簡単ではなく、チームとその上のリーダーの両方にとって適応が必要です。それを機能させるには、双方がプロセスを理解する必要があります。どちらかが理解できなければ、移行期は矛盾した期待に満ちた困難な道となります。

しかし、すべてが変化すると、いくつかの魔法のようなことが起こり始めます。チームは作業をより適切に見積もり、計画できるようになり、リーダーはより予測可能なリリースとロードマップを信頼できるようになります。

次に、スプ​​リントを台無しにする可能性がある不健全なプロセスを確認します。