「完了」に到達していませんか? スプリントでの成功を定義する方法

現在のバージョンのスクラムガイドでは、「完了」について29回言及されており、スクラムガイドの最後のセクションは「完了」の定義についてです。「完了」とはどういう意味ですか? これは、潜在的に出荷可能、またはスクラムガイドによれば、「使用可能で、潜在的にリリース可能」を意味します。スクラムは、やり遂げることがすべてです。部分的なクレジットはありません。出荷可能な作業は完了するか、完了しないかのどちらかです。

とはいえ、スプリントの目標が達成されれば、スプリント自体は成功したと見なされます。スプリントの目標を達成するために必要な何かがスプリントの終了前に「完了」しなかった場合、スプリントは成功しませんでした。これは通常、スプリントの最後に未完了 (または未開始) のスプリントバックログ項目が残っていたことを意味します。しかし、それは常に悪いことですか? すべてのスプリントバックログ項目を完了しないことは、スプリントの目標を達成しないことと同義ですか?

スプリントが成功した (スプリントの目標が達成された) ことと、すべてのスプリントバックログ項目が完了したスプリントの違いを理解することが重要です。スクラムチームは、すべてのバックログ項目が完了するスプリントを目指していますが、この 100% の時間を達成しているチームは、おそらくストレッチや成長を行っていません。彼らは自分の能力の限界を押し広げ、そこから得られる改善を得ていません。

また、スプリントが成功したと見なすためにスプリントバックログのすべての項目を完了する必要がある場合は、失敗に備えている可能性があります。

スクラムチームは、開発において目的主導型である必要があります。スプリント中に完了する項目の数に焦点を当てるのではなく、顧客に価値を提供するための包括的なビジネス目標を達成することに焦点を当てる必要があります。つまり、スプリントの目標はスプリントの戦略的な目的を提供しますが、その目標を達成するための戦術は柔軟です。

スプリントを成功させるには?

では、スプリントを成功させるとはどういう意味ですか? スクラムチームはスプリントで成功するためにどのように計画しますか? スプリント終了時の未完成の作業の実際の影響は、大小を問わず何ですか? 各スクラムイベントがスクラムチームの成功にどのように貢献しているかを見てみましょう。

スプリント計画

スクラムチームは、計画方法が原因でスプリントに失敗することがよくあります。スプリントに過剰な負荷がかかるか、スプリントの目標が完了するすべてのスプリントバックログ項目に依存するようにします。より良いアプローチは、スクラムチームがスプリントのバックログ項目の80%によってスプリントの目標を骨格的に達成できるように計画することです。バックログ項目の残りの 20% は潜在的に改善する可能性がありますが、物事が計画どおりに進まない場合でも、スプリントの目標を達成するためにスクラムチームに余裕を与えます。

もう 1 つの問題は、過去のスプリントで達成できたことに関するチームの実証済みの経験的データを無視することです (1 つの例は、速度 (スプリントで完了した推定作業量) です)。多くの場合、スクラムチームは数学を微調整してスプリントに過負荷をかけます。これらのフレーズのいずれかがおなじみのように聞こえるかどうかを確認してください。

「まあ、これらの3つのアイテムは本当にライトファイブであり、ヘビーファイブではないので、スプリントにさらにいくつかのアイテムを追加します。」
「そのバックログ項目はすでに開始されていたので、5ではなく3であると仮定します。」
「私たちはスプリントごとに40ポイントを提供してきましたが、一生懸命努力すれば、60ポイントを実行できると確信しています。」
「まあ、私たちは私たちの能力を発揮していますが、ジョンは何の関係もありません。」

上記のフレーズはすべて、数値を微調整し、実証された速度を無視する試みです。計算を微調整すると、サイロ化や配信ではなく使用率に焦点を当てるなど、チームに他の問題が追加される傾向があります。数字が合わないと、チームがスプリントに失敗する可能性が劇的に高まります。

デイリースクラム

毎日のスクラムは、スプリント目標に向けた進捗状況を確認して再コミットし、その日のスプリント目標の達成に近づくために必要な計画を調整する機会です。これは、責任をシフトすることを意味する場合があります。これは、他の誰かの仕事を助けることを意味するかもしれません。しかし、重要なことは、すべての行動が目標達成に向けたチームの進歩を促進することです。

スプリント中は、スプリントバックログ項目の開始よりも終了に重点を置く必要があります。これをスウォーミングと呼びます(チームのすべての開発者は、新しいストーリーを開始する前に、完了するまで同じユーザーストーリーで作業します)。たとえば、通常の速度が 25 ポイントのスクラムチームがあるとします。彼らは5つのバックログ項目にコミットし、それぞれが5ポイントの価値があります。チームメンバーが病気になり、スプリントの推定容量が 25 人未満になります。すべての項目を開始して 2 つ以上の項目を開始して未完了にするよりも、4 つのバックログ項目が完了して 1 つの未開始でスプリントを終了する方が適切です。バックログ項目の終了に重点を置くと 4 つの項目が配信され、複数の項目を一度に開始することに焦点を当てると、最大 3 つ (場合によっては 0 つ) が提供されます。

このようにスプリントバックログ項目の完了に重点を置くということは、チームメンバーがタスクを完了するたびに、新しいユーザーストーリーに移り、進行中の作業を増やす前に、次の 2 つの質問を自問する必要があることを意味します。

ペアリングすることで、他の人のタスクを手伝うことはできますか?
チームメンバーには、チームのスプリント目標を達成するために協力する責任があります。
私が助けることができるものがない場合、誰かをシャドウイングして追加のスキルを学ぶことはできますか?
チームメンバーが他の誰かを助けてもスプリントの目標に貢献できない場合は、チームの他のメンバーとクロストレーニングして、チームが現在のスキルセットから同様に偏っている別のスプリント目標を持っている場合に将来貢献できるようにすることが重要になります。

上記の質問のいずれかに対する答えは、ほとんどの場合「はい」です。

スプリントレビュー

スプリントレビューはスプリントの終了時 (すべての作業がスクラムチームの完了の定義を満たした後) ですが、次のスプリントの計画に役立つ重要なフィードバックを提供します。これは、利害関係者と優先順位について話し合い、次のスプリントの適切なスプリント目標を理解する機会でもあります。

スプリントレビューは、一方的なショーアンドテル以上のものです。これは、製品の現在の状態と将来の方向性に関するチームと利害関係者の間のコラボレーションです。これは、利害関係者がレビューしているものが実際に出荷可能である場合にのみ有用な会話になります—利害関係者が対話し、次に何が起こるべきかについての具体的なコンテキストを提供できるもの。次のスプリントの目標を明確にすることは、プロダクトオーナーがスクラムチームに戦略的で明確な方向性を提供する方法です。

スプリントの振り返り

スプリントの振り返り中に何をするかは、スプリントの目標完了率によって異なります。開発チームがスプリントの大部分でスプリントのすべてのバックログ項目をまだ完了している場合、トーンは、スプリント内のすべての項目を完了することよりも、失敗からどのような学習が得られるかに関するものです。チームは、次のような質問と改善アクション項目について話し合うことができます。

すべての項目を完了するのを妨げる外的要因が発生しましたか? これらは軽減または防止できますか?
たとえば、データベースインスタンスのメモリが不足し、停止が発生してチームがスプリント作業から撤退した可能性があります。学習は、データベースがメモリ不足になった場合に鳴るアラートを作成して、停止する前にチームが対処できるようにすることです。失敗したスプリントは、チームがより堅牢なシステムを作成するのに役立ちました。
作業やプロセスでどのようなボトルネックを発見しましたか? どうすればそれらに対処できますか?
たとえば、開発者はコードレビューを待つのに多くの時間を費やしたと感じています。チームは、コードレビューを 1 時間以上待機する項目はないことに同意し、各チェックインが待機する必要があった時間を追跡します。チームは自分自身をプッシュすることで、自分自身を伸ばさなければ見つけられなかったボトルネックを特定するのに役立ちました。
私たちが試したことはありましたか? 私たちが知っておく必要のある学習の領域はありますか?
たとえば、チームは新しいフレームワークを使用していて、学習曲線のために一部の項目が未完成であると感じていました。チームは、次のスプリントのタイムボックスを作成して、新しいフレームワークに関するいくつかのチュートリアルを実行します。

スプリントの目標が達成されなかった場合、またはチームがすべてのスプリントバックログ項目を完了できていない場合は、ディスカッションを学習の機会から、次のスプリントの目標を達成する方法に重点を置く必要があります。ディスカッションとアクションアイテムには、次のものが含まれます。

スプリントの目標を逃し、信頼性が低下する原因となる、効果的に行っていないことは何ですか?
たとえば、チームが中断 (ビジネスミーティング、休暇など) を考慮していない場合や、品質の問題や技術的負債によってチームの速度が低下している可能性があります。
スプリントの目標を達成するためにチームが信頼できることがビジネスにとって重要なのはなぜですか?
これは、チームが他のビジネスの必要性を理解し、共感して、組織の他の部分(マーケティングや販売活動など)の動員を同期させて成功できるように、チームの計画と予算を立てる能力に頼ることができます。これは、製品所有者が自分の仕事がチームの一貫性を保つ能力に依存していることを理解するのにも役立ち、製品所有者はチームの焦点を保護するのにも役立ちます。
次のスプリントの目標にコミットし、達成するために何をするつもりですか?
多くの場合、これは次のスプリントを少なくする(つまり、前のスプリントよりも少し余裕を組み込む)ことを意味します。チームと利害関係者の両方に、一貫性が1回限りのハイスコアよりも重要であることを教育することが重要です。

スプリント後

スプリント後に未完了のバックログ項目をどうするかについては、製品バックログに戻り、それに応じて優先順位が再設定されるという答えが 1 つあります。スプリントの目標が達成され、未完了のバックログ項目がある場合 (上記の 80% のガイドラインを思い出してください)、次のスプリントに進むと自動的には想定されません。実際、未完了のバックログ項目は、次のスプリントの目標として機能する製品所有者の次のフォーカスをサポートする他の製品バックログ項目を優先して、製品バックログの下位に移動する可能性が高くなります。

開始されたバックログ項目が次のスプリントで処理されない場合は、その変更をコードからバックアウトし、スプリントの製品インクリメントをクリーンで出荷可能なままにする必要があります (これらは、後で項目が作業されたときに適用できるパッチに保存できます)。

あなたが期待するかもしれない結果

<>各スプリントで目的主導型であり、「完了」することに焦点を当てることで、次のような素晴らしい結果を享受できることを期待できます。

品質保証:実際に完了すると、出荷可能になります。チームが品質 (顧客の意図に応える作業) を提供していない場合、どれだけ提供するかは関係ありません。ここに当てはまる銃器の訓練で使用されるフレーズがあります:あなたは勝つのに十分な速さを逃すことはできません。
品質管理: すべての製品バックログ項目で完了の一貫した定義に開発することで、生産における欠陥の数を大幅に減らすことができます。
一貫性: 分散 = 分散 out。一貫性は計画に役立ちますが、速度を向上させるための前提条件でもあります。スクラムチームはスプリント間で同じ種類の作業を行うため (つまり、すべてのスプリントバックログ項目が同じ完了の定義を満たしている)、各スプリントで達成できる作業量を把握しています。スクラムチームの速度がスプリントごとに一貫していない場合、実験の影響を測定することは困難です。チームが一貫していれば、何か新しいことに挑戦し、それが速度にプラスまたはマイナスの影響を与えるかどうかを確認し、それに応じて調整することができます。

スクラムチームが一貫して成果を上げて作業に取り掛かると、スプリントごとにより多くのビジネス価値を提供するために限界を押し広げる準備が整いますが、これは品質と一貫性が存在し た後に のみ達成できます。

スクラムチームが毎日やり遂げ、スプリントごとに目標を達成するのを支援します。チームでそれを実現したい場合は、お問い合わせください。

[monarch_share center=”true”]