No Estimateをやって、開発に集中できました。

What is "No Estimate"

見積もりしないこと、なんの話でしょうか？

Estimate

ScrumとAgileで、Sprint Point(SP)でストリーの難度さを見積もることは多いです。SPをもとに、チームのVelocity (スピード、ある意味で作業の量)が確認されます。
No Estimateとは、SP、Velocityを使わないことです。SPを見積もらないです。当然にSPをもとにするベロシティーを確認しないです。

No Estimate

単純に、見積もらないことですが、何よりも、見積もりが時間を取りたくない概念になります。

SPとVelocityって、Scrumの基本ではなかったっけ？

確実に、SPとは、全く基本ではない

Agile Manifestoでそういう話は全くないです。
Agile AllianceとScrum Allianceを設立したKen SchwaberのScrum Guideに、Sprint point、Velocityの話は一切ないです。
Poker planning, story points, focus factor, dirty hours and mandaysに関して、Scrum Guideが参考になりません。

SPとは、元々Extreme Programing (XP)の概念です。Scrumのpracticeに導入され、XPのSPの概念(時間の見積もり)から離れてきました。
XPを設立したRon Jeffriesがあの概念を定義したかもしれませんが、後悔していると発信しました。下記の理由で：

• SPはちゃんと使用されていない
• いつ終わるかに答える手段として弱い
• 見積もり通りかどうかの確認は無駄時間
• Managementのプレッシャになる
• チームなどをSPで比較ですることは悪い
• 元々の目標を解決しないことだけで、解決しようとしていない目標でしようされてしまう話です。

ただ、SPをもとに評価したり、プレッシャをかけたり、チームを比較したるすることは、何よりも最悪で、やめようとした大きい原因です。
PF部で、(DMMでは？)、そんな面倒くさいことをやっていないと思います。実は、正直に他チームのSPの基準と数字などあまり分からないです！Scientificの結果として認められていないです。
XPとScrumの面で、SPは絶対だめだと言い切れないと思いますので、個人的にNo Estimateをやるしかないというスタンドはないです。

元々、XPで理想の1日間で見積もっていました。マネージャーから、なんで理想できていないと言われて、抽象的なSPに変更しました。まだ時間の見積もりでした。
Scrumで、概念がまた変わって、難度さでSPを見積もるはずです。実際に時間を意識することは多いです。

SP、ベロシティーって間違いだったと反省した人

ベロシティーは無駄時間であったり、間違いだったと思うAgileの偉い人は少なくはないです。

• XPを設立した人
  • Ron Jefferies
• Agileを設立したメンバー
  • Martin Fowler
  • Alistair Cockburn
  • Jim Highsmith

Source : Agile waste : Stop using Story Point

Why

なんでSP、見積もりがないほうがよいと考えられますか？

Sprint PointとVelocity、なんの価値

チームのストリーを相対的な難度さを確認して、ストリーのレビューを行い、チームのSPの相対値が定義されます。
チームは、わからないほどストリーが大きいこと、早く終わらせるかを判断することができます。

Sprintが終わるときに、チームがどのぐらいできたを確認し、見積もりが正しかったかを確認します。
チームのベロシティー（なんのスピードでチームが動く）が分かってきます。
ストリーのSP、チームのVelocityがわかることで、Sprintの単位でどのぐらいできるかわかりそうです。レビューでSprintが遅かったかわかりそうです。

見積もりの理想と現状

下記の実績は本当に多いですか？

「プロジェクトやストリーを見積もって、部長にスケジュールを発表しました。最初決定したスコープを、見積もり通り、超残業せずに、オンスケ、サービスインします。Happy End!」

みずほ銀行やIBM多分色々真剣に見積もりましたが、日本のサグラダファミリアを作ってしまいました。本が書けるほどの失敗がやっと完了されてから、障害祭りになりました。
個人的な経験では、オンスケのリリースは実際に多くありました。ただ、見積もり良かったということより、残業を多くしたり、品質が低くなったり、人々をやしたりしたケースはほとんどです。

プロジェクトがいつ終わりますか？
「Gmailって20年間やっているけど、いつ終わりますか？」という質問は意味がありますか？
20年間UI、UX、機能、非機能、ブランディング、マネタイズが継続的によくなって、優れたプロダクトになったことは一番大事ではないですか？
メールアプリのLotus Noteがオンスケリリースされていたか分からないですけど、使いたくないし、返却されました。
どっちものプロダクトは、Agile、Scrum、Waterfallとか、どう開発したか分からないです。ただ、いつ終わるかという観点だけで考えるのは、浅い気がします。

いつ終わるかということより、最初のバージョンをできる小さくて、「終わり」ではなくて、「初版」をできるだけ早く出して、継続的によくしようと考えたほうが良いではないですか？

## No Estimate

No estimateとは、名前通りに、Sprint Pointをつけないことです。ベロシティーを確認しません。
そもそも、見積もりとはScrumの後付の手段だけです。

メリット

• 見積もる時間を取らない
• SPをレビューする時間を取らない
• どうしても見積もりが間違っていることは多いので、余計なことをしない
• ストリーの価値、ストリーの内容に集中できる
• SPのデメリットがあり、SPを使わずに動くソフトウェアを継続的にリリースできたら、SPは要らないですか？

How

やりかた

見積もらないと、大きすぎるストリー、スプリント内で達成できないストリーがでてしまいそうです。
実は、見積もりと関係なく、ストリーの分析が足りないということです。

SPは1、２、３ではなくて、「大きすぎる」、「もっと小さくしても価値がある」という感覚でストリーの内容を確認します。
見積もらないしないことと、ストリーのサイズを気にしないことは違います。

確認できるIterativeなステップで進むように、小さいストリーが必要になります。
Getting Small Storiesを読むと、Extreme Programmingで、90分間のスプリントでリリースすることはあります！(参考)それは、90分間でやることが価値があると思っているわけです。

チームの価値の定義・感覚を見直す必要がある気がします。
例えば、20%コスト削減というストリーは価値があります。ただ、このストリーだけだと、実際にやることは曖昧で、すぐできないです。
すぐできるストリーはビジネスレベルの大きいインパクトを望まずに、適切に小さい一つのストリーの価値を理解する必要があります。

例えば、「このプロジェクトのビルドを見直すことで、デプロイが倍早くなる」、「APIのDesignを決定することで、チームのレビューができる」という単位で価値を感じる必要があると思います。
Rome was not built in a day(ローマは一日にして成らず)という表現あります。石材の作成、石材の発行、一段ごとに何百年間で建築されました。

やってみたけど、うまく行かなかった

すぐできるストリーを定義したと思いましたが、すぐできずに、リリースできなかった場合があるかもしれません。
ゴールとリリースに向かって、作業が進んで、教えになったのに、ストリーの定義がたまに間違うことで、本当に何か困りますか？

Agileで失敗できることは、当然ではないですか？試してみて、結果を見て、完璧や安定を目指さずに、レトロスペクティブで継続的にやり方を見直すことは、一番重要です。
確実に適切なストリーが作らないかもしれませんが、価値に関する希望を見直して、手間のかかる作業を理解したことで、今後のストリーの定義がよくなるかもしれません。

SPの細かい話せずに、なんで大幅のストリーでしたか？という観点で考えてみましょうか？

Who

一般的に

一般的に、Dead lineがあると、いつ終わるか分からないまま進むのはだめです。
その場合、No Estimateが合っていないですが、そもそもScrumとAgileが合っていますか？
Scrumで、マイルストーン、スケジュール感ありますけど、コミットできるリリース日という概念に反対しています。

バランスをとって、Scrumの良いところを使って、Dead lineを守っていきたい気持ちがわかりますけど、どうしてもNo Estimateは無理かもしれません。

現状、DMM.comプラットフォーム事業本部で、3つのチームがNo Estimateを実施しています！良いプロダクトを継続的に作ろうとしているため、やり方としてあっていると思います。
No Estimateをやって、大きすぎて、終わらせないストリーになったことがありました。ユーザーの観点でストリーを作成すると、作業の量が大きすぎる問題だと思います。親のUser Storyでゴールを明確して、ストリーで、もっと良いプロダクトへ進める一歩だけ(DDのアーキテクチャ図、バージョンアップ、ライブラリ導入、構築の変更一点)で価値があるという観点から、適切に小さいストリーを作ろうかと提案します。

IMO No Estimateをやって、改めて開発に集中できました。

No Estimateにて、下記ができました。

• 結局やらないUser Storyの見積もることをやめた。YAGNI
• やってみないと分からないけど無理やりUser Storyを見積もることをやめた
• いくら議論しても、なかなか同意できない見積もりで時間をかけることをやめた
• 簡単に見積もれるUser Storyは、見積もらなくても、困ることはない

正しくうごくプロダクト、プロダクトに関するアイディア、開発に集中をもっとできるようになりました。
やっぱり、3SPか5SPをはっきり理解するように手間をかけることより、CI/CD、コードのリファクタリングなどで開発の効率を高めたいし、設計を考える時間が欲しいです。
No Estimateですごく良かったです！

When

いつやるか？ 今でしょ！

References

リンク	説明	言語
Agile Manifesto	Agileの元	日本語
イテレーティヴとインクリメンタルの違い	The waterfall trap for “agile” projectsの日本語の説明	日本語
Story Points Getting small stories	XPを設立したRon Jeffriesが多分SPを定義しました。後悔している話、そして、小さいストリーを作ることは、どう見積もりと違うかの説明	英語
No estimate part 1 No estimate part 2 No estimate part 3	Scrumを設立したNeil KillickがNo Estimateを推奨していること。	英語
Agileの“No-Estimates”を考える	プラットフォーム事業本部の石垣さん	日本語

ちなみに、英語は難しかったら、英語学習に役に立つTipsはおすすめでございます。