発見の推定にアジャイルスプレッドシートを使用する

この記事には、アジャイルディスカバリーの見積もりを作成するのに役立つフォーマット済みのスプレッドシートが含まれています。 また、注目の例とともに従うのに役立つ情報も含まれています。 ここのテンプレートから編集可能なコピーを作成できます（[ファイル]>[コピーを作成]または[ファイル]>[ダウンロード]）。

私がチームを配置する前、またはMVP要件を知る前に、クライアントからアジャイル見積もりを提供するように求められることがよくあります。 この初期段階では、速度、スプリントの数、チームのコストなど、これらの見積もりを計算するための従来の指標にアクセスできません。 しかし、クライアントは答えを求めています。 彼らは2か月または6か月で架空の製品を発売できますか？ 彼らの（通常は低い）予算で実現可能でしょうか？

アジャイルスプレッドシートを入力します。

スプレッドシートは、アジャイルの考え方にふさわしい、しかし見過ごされがちな選択です。 これらは、コラボレーションを促進するローテクでハイタッチなツールです。 とはいえ、製品のコストと品質が要件を満たしている限り、顧客はおそらくツールが「アジャイル承認」されているかどうかを気にしません。 スプレッドシートの真の価値は、すべての経験レベルのプロジェクトマネージャーと利害関係者へのアクセス可能性にあります。

多くの特殊なプロジェクト管理ツールには、動きの速いプロジェクトの経験の浅いユーザーには急すぎる学習曲線があります。 したがって、クライアント、製品所有者、および開発者が要件と人件費を更新するのが簡単であるほど、現実的な見積もりに早く到達します。 事前にフォーマットされたスプレッドシートを使用すると、プロジェクトマネージャーは値とパラメーターを調整して、変動する各リソースやシフトするタイムラインの影響を示すことができます。

スプレッドシートは、同僚と知識を共有するための優れた方法でもあります。 私が使用しているスプレッドシートは、Toptalの同僚が作成したものであり、それ以来、コピーを作成して、ニーズに合わせて変更しています。 私もそうすることをお勧めします。

この記事では、クライアントと利害関係者がプロジェクトの目標に沿って開発を進めることができるように、成功した発見の見積もりを提供する方法を示します。 空白を埋めて、後ろに立つことができる初期段階の見積もりを提供する方法は次のとおりです。

最初に製品ビジョンとロードマップに取り組む

クライアントが固定予算で出会い系サイトを開発したいとしているが、製品の詳細があいまいであるとします。 チームのコストと速度を知らなくても、製品ビジョンは、利害関係者が設計目標について合意し、チーム全体の透明性を促進する必要があるため、開始するのに最適な場所です。

直感的なナラティブスタイルのScrum.org製品ビジョンフォーマットが好きです。 外観は次のとおりです。

製品のビジョンが設定されたら、新しいスプレッドシートタブに製品ロードマップを追加して、クライアントに長期的なプロジェクトスケジュールの感覚を与えることができます。 ロードマップには、各製品ロードマップバージョンの目標、主な機能、および期限を記載する必要があります。

ロードマップバージョンは、市場の軌道を導く製品の計画された、消費者向けまたはクライアント向けのエディションです。 最初のロードマップバージョンは、市場でデビューできる製品です。 後続のロードマップバージョンは、製品ビジョンに沿った魅力的な新機能を備えた市場リリースを表しています。

例としてMicrosoftを使用するには：Windows8はおそらくロードマップバージョンでした。 Windows 10は、多くの新しい望ましい機能を備えたもう1つのロードマップバージョンでした。

製品のビジョンとロードマップが完成したら、クライアントにMVPにコミットするように依頼します。

トリプルコンストレイントチャートを使用してMVP機能をネゴシエートする

これは、トリプルコンストレイントチャートを使用して、時間と費用に関するクライアントの期待を形作る瞬間です。

ウォーターフォールアプローチでは、固定機能が時間とコストを決定し、詳細なプロジェクト計画に従って開発が進行します。 逆に、アジャイルの固定費とスケジュールによって製品の機能が決まり、これらの機能は、より柔軟なプロジェクトビジョンに基づいて常に優先順位が付け直されます。

Triple Constraintチャートは、最初のリリースに必要なすべての機能を含めると、開発時間とバルーンコストが増加することをクライアントに示しています。 代わりに、クライアントと協力して、MVPの「必須」機能のみを選択し、将来のリリースのために残りの機能を表にします。

スプレッドシートを使用すると、クライアントの変化するニーズに基づいて、機能をグループ化し、さまざまなバージョン、リリース、および優先順位に簡単に再割り当てでき、これらの変更のコストが即座に表示されます。

MVP機能を特定している間、対象分野の専門家（SME）に、彼らが取り組んだ同様のプロジェクトに基づいてプロジェクトのステップをリストするための支援を求めてください。 これらの手順を使用して、後でエピックを作成します。 これらの入力の準備ができたら、見積もりの​​作成を開始できます。

Tシャツのサイジングから始めましょう

最初のバックログを開始するには、製品の所有者に製品の機能の詳細な説明を依頼し、難易度に基づいて各機能にTシャツのサイズを割り当てます。

Tシャツのサイズは、絶対値を取得する前の各開発タスクの相対的な複雑さと期間を示します。 プロジェクト計画をさらに進めていくと、これらの相対的なサイズをストーリーポイントと作業時間に変換します。

たとえば、クライアントが出会い系サイトで一連のポップアップを作成することを望んでいる場合、それは時間がかかりますが簡単です。 そのタスクの複雑さを「小」と見なすかもしれませんが、その努力は「中」になります。 これを「SM」と略すことができます。 一方、新しいAPIのバックエンド接続の開発は、必要なすべてのドキュメントとテストがあるため、より複雑なタスクになります。 これに必要なスキルと注意は、努力とスキルレベルの両方で「大」になる可能性があります：「LL」。

Tシャツのサイズ設定が完了すると、将来の各チームメンバーの相対的な作業負荷とスキル要件を把握できます。 次に、開発チームの技術専門家が、Tシャツのサイズを時間の範囲やストーリーポイントに関連付けるのを支援します。

パラメータを設定する

これで、スプレッドシートを機能させて見積もりを計算する準備が整いました。 [パラメータ]タブを作成することから始めます。 これは計算のキーとして機能し、ここに入力した値は、[バックログ/ユーザーストーリー]および[リリースごとの見積もりの​​概要]タブで使用される式に入力されます。

[パラメータ]タブに必要なものはすべて次のとおりです。

通貨。 ここに通貨換算を入力します。 たとえば、クライアントの予算がブラジルレアルの場合、現在の換算レートをドルまたはユーロで入力できます。

開始日。 開発開始予定日は、プロジェクトのタイムラインを作成するために使用されます。 それぞれの例で、開始日は10月25日です。

初期予算。 予算は、すべてのMVP機能が予算内に収まるかどうかを示す制約を提供します。

Tシャツのサイジング。 Tシャツのサイズを表として入力し、各サイズの組み合わせにストーリーポイントと時間の範囲を割り当てます。 この例では、SSに1〜2時間、LLに33〜48時間を使用します。

スプリントの期間によって、Tシャツの最大サイズの時間が制限されることに注意してください。 スプリントが1週間しかない場合、最大サイズは40時間を超えることはできません。 これが、Tシャツのサイズをタスクに割り当てるときにSMEに相談することが非常に重要である理由です。

時間あたりの料金。 この表を使用して、各役割の支払い率を文書化します。 バックエンド開発者のレートが異なる場合は、2つの平均を使用してください。

オーバーヘッド。 プロジェクト全体の作業の一部を、ステータス会議、フィードバックセッション、プロジェクトの改訂などの管理タスクに割り当てます。 10パーセント（または各参加者の1週間の労働時間の4時間）から始めるのが適切ですが、より複雑なプロジェクトではオーバーヘッドが高くなる可能性があります。

不測の事態。 これは、見積もりの​​潜在的な差異を示しています。 偶発事象が0％の場合から、スプレッドシートに入力した値を考慮して、最良の（つまり、ありそうもない）予算とタイムラインが表示されます。 この例の後半では、偶発事象を50％の大まかな桁数（ROM）の変動に増やして、潜在的な上限のコストとプロジェクト期間を示します。 より正確な数値を取得すると、不測の事態は縮小します。

エピックで各リリースのサイズを設定する

クライアントの時間やお金を無駄にしないように、製品全体の大まかなサイズ設定から始めます。 サイジングが提案された予算と期限にどれだけ近づいているかに応じて、クライアントはプロジェクトを中止するか、より詳細な見積もりに投資するかを決定する場合があります。 現時点では詳細があまりないため、[バックログ/ユーザーストーリー]タブにエピックとして主な機能を入力します。 次に、各エピックについて、[パラメーター]タブのTシャツのサイズ表に基づいて、SMEと開発リーダーが各開発スタックに対して提案した時間数を入力します。

まず、「EPIC？」列を選択します。 「エピック」のみが選択されていることを確認してください。

次に、壮大な説明を書き、開発スタックの各列の時間数を入力します。 たとえば、壮大な「安全な接続とログイン」には、UI開発に約8時間、バックエンドに40時間かかります。

ほとんどの場合、「ポイント」列のセルには「34*」と表示されていることに注意してください。 [パラメータ]タブに戻ると、34ポイントが33〜48時間の1時間ごとの範囲に対応していることがわかります。 スプリント期間が1週間しかない場合、その時間数は長すぎます。

詳細がわかったら、これらの時間を短縮するか、叙事詩をより管理しやすいストーリーに分割する必要があります。 ただし、時間の都合上、[ポイント]列は無視して、概算を続けます。

次に、[リリースごとの見積もりの​​概要]タブに移動します。 スプレッドシートの上部に、[パラメータ]タブで定義されている[オーバーヘッド]と[偶発性]の値が表示されます。 叙事詩やユーザーストーリーごとに見積もりを表示するために選択できるボタンもあります。

表示するユーザーストーリーはまだないので、「エピックモード」のボタンをチェックしてください。

これで、MVPの大まかなコストとタイムライン、および将来のリリース（R3とR4）での緊急性の低い機能と更新を確認できます。 この例では、顧客がすべてのMVPエピックを最初のバージョンで起動するように要求したため、2番目のリリース（R2）は空です。

これで、最も楽観的な総コストである28,810ドルを確認できます。 この数値は、MVPからR4までの各リリースのコストの合計です。

また、R4開発スタックの最新の完了日に対応する、製品納品の最短タイムラインの見積もりもあります。 プロジェクトマネージャーは、リリース全体の速度を決定するため、これらの遅い開発スタックを「クリティカルパス」と呼びます。

この場合、クリティカルパスはフロントエンド開発であり、完了日は1月31日です。

次に、パラメータを調整して、最悪の場合の予算と最長のタイムラインをシミュレートします。

不測の事態を50％に調整します

製品の労力と専門知識の要件についてはまだほとんどわかっていないため、[パラメーター]タブに50％のROMコンティンジェンシーを追加します。 プロジェクトの詳細を知るにつれて、不測の事態は減少します。

繰り返しになりますが、これが0％の偶発事象でのプロジェクト全体の見積もりです。

そしてここでそれは50％の偶発性にあります。

これは、プロジェクト全体のROM見積もりが28,810ドルから41,860ドルの間であることを意味します。 最良の場合と最悪の場合、クライアントの20,000ドルの予算では、ウィッシュリストにすべての機能を含めるのに十分ではありません。

50％の不測の事態での完全なプロジェクト完了日は、0％の不測の事態の完了日より6週間遅れた3月14日になります。

一方、MVPは1月10日に準備が整います。

クライアントは、プロジェクトを放棄する代わりに、より詳細な見積もりを要求して、より短いタイムラインで目標予算に近づく可能性があるかどうかを確認します。

期限に間に合うように優先順位を付け直す

クライアントが、10月25日のキックオフから2か月後、MVPの目標日を12月25日に設定するとします。

現在の1月10日のMVP完了日を繰り上げるために、クライアントは2つのMVPエピックを次のリリース（R2）まで延期することに同意しました。

スプレッドシートは、この調整のカスケード効果を計算します。 この場合、MVPタイムラインは12月27日に短縮されます。フロントエンドとバックエンドの開発は、完了するまでに最も時間がかかるため、このシミュレーションのクリティカルパスです。

この情報に基づいて、フロントエンドとバックエンドの完了日を他の開発スタックに合わせるために、さらに2人の開発者を追加することを決定する場合があります。 これを行うには、MVPの「週あたりの時間」行の時間を40から80に増やします。

フロントエンドとバックエンドの両方の開発スタックが11月に終了し、QAが新しいクリティカルパスになります（完了日は12月20日）。 コストは変わらないことに注意してください。 これは、各スタックの合計作業時間が同じままであるためです。 1人の開発者が2週間（80時間）作業する代わりに、2人の開発者が1週間（80時間）作業します。

スプレッドシートは、フルタイムとパートタイムの仕事の違いも説明しています。 UI開発者がパートタイムで働いているとしましょう。 UIの「1週間あたりの設計時間」を20に変更して、配信の遅延をシミュレートできます。

フルタイムのスケジュールで、UX/UIは11月29日に完了します。

パートタイムのスケジュールで、UX/UIは12月27日に完了します。

繰り返しになりますが、コストは変わりませんが、UX / UIが新しいクリティカルパスになり、MVPのタイムラインが12月27日に延長されます。

リソースとクライアントの期限を考慮して、許容可能なクリティカルパスに到達するまで、この試行錯誤のアプローチを続けることができます。 適切な期限が設定されたら、見積もりの​​微調整を開始します。

ユーザーストーリーで見積もりを調整する

50％の不測の事態の見積もりはクライアントの予算を超えたため、不測の事態を減らしてより現実的な見積もりを取得できるように、変数を調整する価値があります。

これを行うには、開発者やSMEと協力して、エピックを詳細なユーザーストーリーに分割します。 ストーリーは叙事詩よりも明確に定義されているため、より正確にサイズを設定できます。

次に、新しい情報に基づいて[パラメータ]タブの値を調整します。 たとえば、SMEと開発チームは、役割ごとにより正確なレートのセットを持っている場合があり、Tシャツのサイズとポイントの割り当てを調整したい場合もあります。 これらの新しいパラメーターを設定すると、計算の信頼性が高まり、不測の事態を25％に減らすことができます。

叙事詩をより小さく、より詳細なユーザーストーリーに分割した方法を見てみましょう。

各スタックの推定時間を手動で入力する必要があった壮大な見積もりとは異なり、ストーリーの見積もりでは、ショートカットとしてTシャツのサイズを使用します。 ここで、[パラメータ]タブに入力したTシャツのサイズが役立ちます。

[バックログ/ユーザーストーリー]タブの[Tシャツのサイズ設定]で、各ストーリーのスタックに割り当てられた開発者とSMEのサイズの組み合わせを入力します。 そこから、スプレッドシートの数式は、[パラメータ]タブから対応する時間を自動入力します。 最大サイズのLLは、合意したスプリント期間内に完了することができるように、34ポイント未満に維持する必要があることに注意してください。 それでも34ポイント以上のストーリーは、細分化する必要があります。

すべてのストーリーに割り当てられているポイントが34未満であることを確認したら、「ストーリー」のみを表示するには、[リリースごとの見積もりの​​概要]タブの[エピックモード]ボタンをオフにします。

これで、新しい数字のセットが表示されます。

すべてのタスクを詳細に説明し、MVP機能のみに固執した後、タイムラインとコストはクライアントの要件に一致するようになりました。 残高は予算内に十分収まっているため、クライアントはMVPを続行し、追加のリリースをコミットする前にテストすることにします。

それをあなたのものにしてください

スプレッドシートは使い方が簡単で、数式に関する基本的な知識があれば（マクロは不要）、ほとんどすべてのニーズに対応できます。 Excelの知識が錆びている場合は、UdemyとedXのオンラインコースでこれらのスキルを磨くことができます。

この記事では発見の見積もりについて説明しましたが、同じスプレッドシートを使用して、バーンアップ/バーンダウンチャートを作成し、タイムラインを調整し、後の段階で速度とスプリントに基づいて見積もりを計算できます。 カスタマイズしたスプレッドシートを使用して、Jira、Asana、Trelloなどのアプリケーションを補完し、プロジェクト管理キットの強力なツールであると主張しています。 それらがあなたにとって同じように有用で用途が広いことを証明することを願っています。

既製のプロジェクト管理ツールよりもカスタムスプレッドシートを好みますか？ コメントでその理由または理由を教えてください。