システム開発(アジャイル・スクラム)とか色々

スクラムについてのアウトプットだったり、時々お気に入りのものなど。

スクラムにおける2つの遅延

はじめに

こんにちは、内製開発の推進とか色々やっている@daimyo404です。 社内向け勉強会という名の好き勝手喋る会をするのでそれに向けてのメモです。

今回はスクラムにおける2つの遅延について考えてみました。

ひとつ目の遅延 - 決定の遅延 -

バックログの受入れ基準

開発チームが着手する前にバックログはReadyである必要があるという話があります。 ちなみにDoRみたいな考え方もあります。

www.infoq.com

ここで言うReadyとはビジネス要求が明確になっていることとか色々ありますが、そのなかに明確にモレなくダブりなく受入れ基準が記載されてたりする必要があるんかなーとイメージをする方もいるかもしれません。

決定を遅延すること

リーンでの考え方ですが、決定を遅らせるというものがあります。

不確実性が高い状態で決めるよりも、あとでより明確になってからの方が精度上がるよねってものです。

これプロダクトバックログの受入れ基準に当て嵌めてみると、必ずしもみっちりびっちり書かれているものが必ずしも良いとは言えないと考えています。(また会話のための道具という側面から考えても)

プランニングの段階でもまだリスクが残っているものとか、 実際に着手して作りつつこうした方が良いかもねってものもあるかもしれません。要は日々のデイリーで検査・適応ができる訳ですね。

他にもエンジニア側の裁量が大きいので自己決定感が高まり自己組織化が促進されたりするかなあと。 あとはプランニングの決めなきゃいけないことが減るので時間短縮になるメリットとかもあるかもしれません。

ふたつ目の遅延 - 遅延コスト -

遅延コスト(Cost of Delay)

以下の数式で成り立ち、 PBIの優先順位付けのアルゴリズムとして使われる場合があります。

CoD = ビジネス価値 + 時間価値 + リスク低減・機会創出

結構イメージ湧きやすいと思いますが、 例えば遅れれば遅れるほど利益が失われる(機会損失)があると高くなったりします。

体力かかるので実際にやったことはないですが、 PBIの優先順位ってビジネス価値やリスクを鑑みて決めなくてはないので、 それが明確に説明できるという点ではステークホルダーマネジメントの観点では良いかもしれません。

参考文献

意思決定の正しいタイミング

アジャイル開発は決定を先延ばしする – プロダクト・マネジメントの要諦 The Rules of the Game of Product Management

遅延コスト回避中心のPBIライフサイクルマネジメント - mtx2s’s blog