🕌

見積もりをしないスクラムを実践して失敗した話

えび

2024/04/01に公開

スクラム

見積もり

idea

TL;DR

スクラムをしているチームで見積もりを辞めてみた
見積もりを辞めたことでチームに変化が起き、これまで意識できていなかった問題が顕在化した
スプリント期間よりも長期の計画の必要性に気付き、実際に長期の計画を立てるためにチームが動き出すようになった

はじめに

レバテックの多くのチームでは、スクラムに取り組んでいます。

今回は、チームのパフォーマンスをより効果的に発揮することを目指し、見積もりをしないでスクラムを回した際のチームの変化についてまとめようと思います。

これまでの見積もり

まず、私の所属するチームでは、ストーリーポイント見積もりと時間見積もりを併用していました。

運用方法はざっくり以下のイメージです。

PBIに対して: ストーリーポイント見積もり
SBIに対して: 時間見積もり

このやり方の最も大きな目的は、
見積もりの工程を通じて「提供価値」・「実作業」の双方に対するチーム内の認識を揃える
ことでした。

この運用では、

チーム内のPBIに対する認識齟齬を少なく抑えられる
実際にそのスプリントで作業可能な時間に対して適切な計画を作ることができる

というメリットがあったものの、

見積もりにかなりの時間を要していました。
（2週間スプリントでリファインメント1h, プランニング2~3hくらい）

見積もりをやめた理由

前述したとおり、見積もりの大きな目的はチーム内の認識合わせでしたが、スプリント期間の再考に合わせて、リファインメントの頻度をあげたことで見積もりをしなくても十分に認識を合わせられる状況を作ることができました。

その結果、見積もりから享受できる旨みが、そのスプリントで作業可能な時間に対して適切な計画を作ることだけになったため、見積もりを止めることにしました。

見積もりをやめて発生した変化

やめてみることで快適さを感じられた！

プランニングや見積もりにかかる時間が減り、非常に快適になりました！

具体的には、週に2h程度かかっていた見積もりが削減され、その分の時間をペアプロでの実装などに当てることができました！
見積もりをやめることでPBIに対する認識齟齬も増えるかな〜と思ってましたが、そんなこともほとんど起きませんでした。

ただ、プランニングで計画している作業量が適正なのかだけはわからず、仮に早くスプリントが完了したら手が空いてしまう状況となります。
そこで、プランニングの段階で、実際に作業できるであろう量よりも多くのタスクをSBLに入れて、早くSBIを消化しても手が空くことがないようにしました。

しばらくして...

複数のPBIが仕掛かり中のままスプリントを跨ぐようになりました。
順調に作業は進んでいるものの、実装中のものが複数存在したり、リリースだけ翌スプリントに持ち越したりするようになりました。

そして、計画された作業は進んでいるのに、スプリント内で思ったように価値提供できてないことから、
今やっていることがあっているのかわからない漠然とした不安感がチームに漂うようになりました。

失敗から見えてきたもの

見積もりをなくしたとしても、スプリントで提供したい価値からスプリントゴールを作り、それを達成するための作業リストとしてSBLを作らないといけない訳ですが、手が空かないようにすることを優先して、スプリントゴールからの逆算でSBLを作れていない状況になっていました。

このような問題が発生したことで、レトロスペクティブにて、
"ロードマップ"や"目標"を設けて、その目標達成に向けてスプリント単位で進捗させていきたい
と話になりました。

これは、プロダクトゴール達成に向けてスプリントゴールを作るというスクラムの当然の活動ではありますが、よく考えると、これまではそういった問題に真剣に向き合う機会がありませんでした。
見積もりをやめたことがきっかけとなり問題が顕在化し、本来進むべき方向が明らかになりました！

おわりに

今回は見積もりをなくして、失敗した話そしてそこから見えてきたことについて話しました。
今回話したことは、

見積もりを辞めるという試みをした結果
これまでスプリント期間より長期の計画をたてることができない状態だったチームが
スプリント期間より長期の計画を自分たちで立てることが必要だと感じ
実際にスプリント期間より長期の計画を立てるために動き出した

ということになりますが、スプリント期間より長期の計画を立てるために動き出すという変化は、
チームが自律的なチームとして機能しようとしているということなのではないかと私は考えております。

もしかしたら、この記事を読んでいただいた方にとってはスクラム開発における初歩的な失敗であるように感じられるかもしれません。ですが、私は「早く失敗すること」がアジャイル開発を成功に導く方法だと考えており、「問題を明らかにすること」がスクラムのフレームワークで実現できることだと思っております。

なので、これからもこんな感じの失敗記事を投稿していきたいと思いますので暖かい目で見守っていただけると嬉しいです！

レバテック開発部

レバテック開発部の公式テックブログです！