いつ終わるんだ？ しばしばこの質問が経営幹部の口に上りますが、それは当然のことです。 経営幹部は、会社レベルでの優先順位付けについて情報に基づいた意思決定を行い、会社のビジョンを達成するために、タイムラインを知る必要があります。 従来のウォーターフォールプロジェクトであろうとアジャイルな製品開発作業であろうと、作業ステータスを知ることは不可欠であり、スクラムチームは戦術的なステータスレポートでそれに答えることができなければなりません。
スクラムチームは、スプリントまたはリリースの目標達成に向けて、どのように進んでいるかを知る必要があります。 実際、彼らはそれに取りつかれています。 スプリント目標を達成するということは、顧客が必要とする時間枠で、顧客の問題解決をしようとしていることを意味します。
経験的プロセス
アジャイル・ステータスレポートが従来のウォーターフォール・ステータスレポートと異なるのは、その基礎が経験的な工程管理であるということです。 スクラムチームは 、ベロシティを未来予測のデータポイントとして使用し、過去の開発速度を現実的な予測に変換します。
経験主義により、チームは継続的に検査と適応を行っています。 彼らは、開発の後期であっても変化を歓迎し（アジャイルの原則２）、ガントチャートやプロジェクト計画ではなく、動くソフトウェアが前進における主要な尺度であることを理解しています（アジャイルの原則７）。
顧客のニーズを早期かつ頻繁に満たすことを計画していますが（アジャイルの原則１および３）、計画に従うことよりも変更に適応することを重視しています （アジャイル価値４）。 ステータスは、チームが学習した内容に応じて、毎日、さらには一日を通して変化する可能性があります。 スクラムチームは、ストーリーポイントやタスク時間のバーンダウンなどの透明な情報を使用して検査し、適応します。
スクラムのような経験的な工程管理の変動性を予測するのは難しいように思えるかもしれませんが、この記事では、スクラムチームがステータスを理解するために必要なものと不要なものについて説明します。 また、チームが目標達成に向けてどのように進んでいるかなど、戦術的なステータスレポートを毎日１分以内に完了する方法についても説明します。
スプリント計画
スクラムチームが戦術的なステータスレポートをどのように使用しているかを理解するには、まずスクラムチームがどのように作業を計画しているかを調べる必要があります。 スクラムチームは戦略的に安定しているため、戦術的に柔軟に対応できます。 チームが安定しているのは、明確なプロダクトビジョンとロードマップ、リリース目標、プロダクトバックログ、そして長期にわたる永続的なチームの基盤があるためです。 彼らは、作業を、スプリントと呼ばれる短いフィードバックサイクルの中で段階的に精緻化していくため、柔軟性（適応性）があります。 各スプリントは、製品のビジョンをサポートするリリース目標の達成に重点を置いています。
「常設チーム」というフレーズに関する注意点ですが、 「常設」とは、チームメンバーに転職の機会を求めてほしくない、という意味ではありません。 または、一度結成したチームを決して変えてはいけないということでもありません。 「常設チーム」とは、一時的なチームという意識ではなく、可能な限り、より永続的なものにしたいという意識でいてほしいということです。 長く続くチームは、予測可能なベロシティ、チームメイトとの結束、顧客の理解、および製品に関する知識により、組織にとってより価値のあるものになります。 長く続くチームは、多くのスプリントで得た信頼の上に構築されます。 この信頼は、常にローテーションするチームメンバーでは達成が困難です。
スプリント計画パート１
スプリント計画のパート 1 では、まず顧客中心のスプリント目標を定義します。 次に、チームはバックログから、それを達成するのに役立つ項目をピックアップします。 各項目の作業レベルは、項目の受け入れ基準とチームの 完了の定義に基づいて推定されています。
計画には、ある程度の見積もりが不可欠です。 各ストーリーが、顧客価値の「潜在的に出荷可能な」インクリメントを作ります。 スプリントで提供されるすべての価値を合計すると、チームのベロシティまたは開発ペースをつかむことができ、経験的データとして使用して、将来のスプリントで実行できる残りのバックログの量を計画できます。 同じメンバー（常設チーム）が各スプリントで同じ種類の作業を行っているため、チームは以前のスプリントの現実に基づいて、スプリントで実行できる作業量を決定できます。 これで、チームはパート２に進むことができます。
スプリント計画パート２
次のステップは、時間の見積もりを利用してタスクを定義することによって、スプリント目標に到達する方法を理解することです。 チームは、スプリント計画のセッションを通じて、自信と、過去のベロシティ傾向との比較、利用可能な時間と計画された時間との比較に基づいて、スプリントバックログと目標を調整します。
時間と計画
時間もまた計画の重要な要素です。 計画した合計時間が容量を超えた場合、プロダクトオーナーはスプリントバックログからバックログ項目を１つか２つ削除します。 計画された合計時間がキャパシティよりも少ない場合、チームは自信を高めます。 これは、緩やかな構築と呼ばれ、スプリント中に発生するとは予想できないことに対応する余地を与えてくれます。 必要に応じて調整することもできます。 計画中は、タスクを人に割り振らないでおきます。 チームは、各タスクにかかる時間の見積もりに同意します。
ステータスを理解するために、どのようにタスク時間とストーリーポイント を利用するのか
スクラムチームは、スプリント全体を通して、タスク ボードにスプリントバックログとスプリントバーンダウン チャートを表示し、スプリント目標に向けた進行状況を把握します。 タスク ボードは、残っている作業と完了した作業のバランスを確認するのに役立ちます。 付せんや電子カードがタスクボード上を移動させ、すべてのタスクとバックログ項目の状態を把握します。 残りの作業が終了すれば、目標に到達したということになります。 シンプルな話です。
タスクボード、またはスプリントバックログの例。
バーンダウンチャートとタスクボード
長期計画のプロダクトバックログ項目を見積もる一般的な方法の１つは、フィボナッチ数列に基づく相対推定手法 であるストーリー ポイントを使用することです。 バーンダウンチャートには、残りのストーリーポイントとタスク時間を、残り時間と比較してプロットします。 チームは毎日ストーリーポイントとタスクを完了させ、両軸のラインを燃やし尽くして（バーンダウン）いきます。 いくつかの簡単な計算をするだけで、チームとステークホルダーは、そのチームが目標に到達できるかどうかを確認できます。
たとえば、４日目には、チームがほぼ順調に進んでいるものの、ストーリーポイントが計画したラインを上回っているため、調整が必要になるかもしれない、ということが分かります。 時間がラインを下回っているため、プロダクトオーナーが完了したバックログ項目を承認できない原因になっている障害があるかもしれません。 バーンダウンチャートを検査することで、チームは質問をしたり、話し合いをしたりして、発見したことに適応して対処することができます。
スプリントバーンダウンチャートの例
バーンダウンチャートとタスク ボードを役立てるには、チームがその２つを更新し続ける必要があります。 これには、完了したタスクとバックログ項目を「完了」に移動したり、その日に発生した新しいタスクを追加したりすることが含まれます。 タスクボードは流動的で、チームの作業合意にならい、正確です。 彼らは毎朝、 毎日のスクラム を利用して検査をし、毎日、計画を適応さていきます。
完了したバックログ項目のスプリント後のスプリントは、このリリース・バーンダウン チャートの例に示すように、チームがリリース目標に向けた進行状況を予測するのに役立ちます。 プロダクトオーナーが完了したバックログ項目を承認すると、バーンダウンに新しい価値のあるインクリメントが反映されます。 多忙な経営幹部も、これを見ればチームに助けが必要かどうかを確認できるため、このチャートを役立てることができます。
リリース・バーンダウン チャートの例
更新にかかる時間が１分かからないのはなぜ？
チームがスプリントバックログを正確かつ毎日管理している場合は、次のことを行うだけです。
- タスクを正しいステータスに移動。
- 「進行中」タスクの残り時間を更新。
- 「To Do」タスクの残り時間を修正（タスクについて何か新しい気づきがあった場合）。
完了です！ これらの手順を踏むのに１日あたり１分以上はかかりません。 シンプルなバーンダウンチャートは、タスクの残り時間で更新できます（またはツールなら自動的に更新します）。
元の時間と完了した時間を把握する必要性があるかどうか
ありません。 どちらもチームの役に立ちません。 チームは、残りの作業を完了することのみを気にすればいいのです。 タスクを完了するのにかかった時間は、目標を達成できるかどうかを教えてはくれません。 それを教えてくれるのは、残りの作業量です。 アジャイルの原則 10「シンプルさーしなくて良い作業を最小限にするーが重要である」。これは、戦術的ステータスレポートにおいても同じことです。
代わりに、顧客が驚くような素晴らしい製品の構築に集中してください！
検査と適応に不可欠なのは透明性である
透明性のある見積りは、検査と適応に不可欠です。 すべてのスクラムアーティファクトと同様に、意思決定のための話し合いをする時にも役立ちます。 ステータスに関係なく、本当に重要なのは、チームと組織が製品を適応させ、よりよいものをリリースすることで顧客に奉仕することであり、それこそが多忙な経営幹部が重要視することです。
チームは、各メンバーがタスクを更新し、タスクボードを管理している限り、毎日１分以下で戦術的なステータスレポートを完了できます。 元の見積りと実際の完了時間を把握する必要はありません。 さらに重要なことは、製品開発の真のステータスを認識するには、スプリントレビューの会話を振り返ることです。
「動くソフトウェアは 進歩についての主要な尺度です」とアジャイルの原則７にあります。製品のインクリメントやその他のスクラムアーティファクトの検査は、ステータスの意思決定を助けます。
ステータスの透明性の確保と実用的なヒントが必要ですか？ スクラムの専門家がお手伝いします。詳細については、 今すぐお問い合わせください 。
