scrum - スクラム: 時代遅れのバックログ項目と外部障害

Question

スプリントの途中で時代遅れになったり不要になったりするスプリント バックログ項目をどのように処理すればよいですか? それらを解決済みとしてマークしますか?

チームの管理外の外部要因に依存するタスクについてはどうですか?

Answer 1

スプリントバックログ項目とは、タスクとも呼ばれるもの、または計画セッション中にチームによって行われた製品バックログ項目の内訳を意味すると思います。カードを最寄りのごみ箱に捨てるか、コンピューター化されたシステムから削除されたことを示すマークを付けてください。意味がある場合は、それらを解決済みとしてマークすることができます (解決済みとは、行うべき作業が残っていないことを意味する場合)。

これが頻繁に発生する場合、チームはこれをふりかえりで取り上げたいと思うかもしれません。これは、チームが何をする必要があるかについて明確な考えを持っていないことを示しています-計画が不十分であるか、製品のバックログ項目が何であるかについての考えが損なわれているか、または要件が変更されている可能性があります. 後者の場合は、PO と一緒に持ち出すことをお勧めします。

外部要因に依存するタスクに関しては、それに応じて作業を計画する必要があります。リスクの高いコンポーネントをリスクの低いコンポーネントから分離します。既存の (そしてリスクの低い) モジュールを、インターフェイスを介してリスクの高いコンポーネントとやり取りさせ、危険な表面ができるだけ少なくなるように API を設計します。

リスクの低いモジュールをビルドするときは、リスクの高いモジュールをスタブ (モック) する必要があります。依存性注入を使用すると、外部要因が利用可能になったときにスタブを実際のものと簡単に交換できるようになります。外部モジュールがインターフェイスに適合しない場合は、アダプタを作成して、呼び出しを外部モジュールの API に変換します。

ソフトウェアを構築する前に外部要因を利用できる場合でも、上記のことを検討する必要がありますが、スタブの開発は、準備ができていない場合ほど重要ではありません。これを行うことで、外部コンポーネントに対する今後の重大な変更からシステムを保護できます。

いずれにせよ、あなたの計画はこれを考慮に入れるべきであり、PO に問題を伝える必要があります。重要な部分が欠落している PBI をリリースすることはできません。

Answer 2

スクラム ガイドでは、この不測の事態について説明しています。

スプリント中:

• スコープは、より多くのことを学べば、プロダクト オーナーと開発チームの間で明確化され、再交渉される可能性があります。

したがって、スプリント バックログ アイテムを削除することになった場合、最初のアクションはそれらをプロダクト バックログに戻すことです。それらを「完了」とマークしないのは、そうでないためです。そうすると、ベロシティに誤って反映されます。

スプリント バックログ アイテムを削除したので、開発チームは、他の製品バックログ アイテムをスプリントに持ち込む能力があると感じるかもしれません。それが彼らの呼びかけです。

後で、おそらく製品バックログの改善中に、削除された製品バックログ項目が役に立たなくなったと判断する場合があります。その後、製品バックログからそれらを削除して、それらの項目を含んでいた製品ロードマップまたはリリース バーンダウンを更新できます。