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](https://rigidity.medium.com/agile-waste-story-points-pt-1-a9df2572d0a3)

# Why

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

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

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

## 見積もりの理想と現状

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

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

みずほ銀行やIBM多分色々真剣に見積もりましたが、[日本のサグラダファミリア](https://gendai.ismedia.jp/articles/-/70793)を作ってしまいました。[本が書けるほどの失敗](https://www.amazon.co.jp/dp/B084QBQDZ3/ref=as_li_ss_tl?_encoding=UTF8&btkr=1&linkCode=sl1&tag=gendai_biz-22&linkId=a2f4126ecd908907fd7bc25fa4e85344&language=ja_JP)がやっと完了されてから、障害祭りになりました。
個人的な経験では、オンスケのリリースは実際に多くありました。ただ、見積もり良かったということより、残業を多くしたり、品質が低くなったり、人々をやしたりしたケースはほとんどです。


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

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

## No Estimate

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

メリット

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

# How

## やりかた

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

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

確認できるIterativeなステップで進むように、小さいストリーが必要になります。
[Getting Small Stories](https://ronjeffries.com/xprog/articles/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プラットフォーム事業本部](https://qiita.com/organizations/dmmcompf)で、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

[いつやるか？ 今でしょ！](https://www.amazon.co.jp/%E3%81%84%E3%81%A4%E3%82%84%E3%82%8B%E3%81%8B-%E4%BB%8A%E3%81%A7%E3%81%97%E3%82%87-%E5%AE%9D%E5%B3%B6SUGOI%E6%96%87%E5%BA%AB-%E6%9E%97-%E4%BF%AE/dp/4800226880/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=%E4%BB%8A%E3%81%A7%E3%81%97%E3%82%87&qid=1633428173&sr=8-1)

# References

<table>
  <tr>
    <th>リンク</th>
    <th>説明</th>
    <th>言語</th>
  </tr>
  <tr>
    <td><a href="https://agilemanifesto.org/iso/ja/manifesto.html">Agile Manifesto</a></td>
    <td>Agileの元</td>
    <td>日本語</td>
  </tr>
  <tr>
    <td><a href="https://www.ryuzee.com/contents/blog/2985">イテレーティヴとインクリメンタルの違い</a></td>
    <td>The waterfall trap for “agile” projectsの日本語の説明</td>
    <td>日本語</td>
  </tr>
  <tr>
    <td>
      <a href="https://ronjeffries.com/articles/019-01ff/story-points/Index.html">Story Points</a><br/>
      <a href="https://ronjeffries.com/xprog/articles/getting-small-stories/">Getting small stories</a>
 <br/></td>
    <td>XPを設立したRon Jeffriesが多分SPを定義しました。後悔している話、そして、小さいストリーを作ることは、どう見積もりと違うかの説明</td>
    <td>英語</td>
  </tr>
  <tr>
    <td>
       <a href="https://neilkillick.medium.com/noestimates-part-1-doing-scrum-without-estimates-b42c4a453dc6">No estimate part 1</a><br/>
       <a href="https://neilkillick.medium.com/noestimates-part-2-contract-negotiation-and-the-old-banger-3f7e61e7ffd7">No estimate part 2</a><br/>
       <a href="https://neilkillick.medium.com/noestimates-part-3-the-palm-off-5bf38a4c0118">No estimate part 3</a><br/>
    </td>
    <td>Scrumを設立したNeil KillickがNo Estimateを推奨していること。</td>
    <td>英語</td>
  </tr>
  <tr>
    <td>
       <a href="https://medium.com/i35-267/agile%E3%81%AE-no-estimates-%E3%82%92%E8%80%83%E3%81%88%E3%82%8B-5f7ef43e32f7">Agileの“No-Estimates”を考える</a>
    </td>
    <td><a href="https://qiita.com/organizations/dmmcompf">プラットフォーム事業本部</a>の<a href="https://qiita.com/i35_267">石垣さん</a></td>
    <td>日本語</td>
  </tr>
</table>

ちなみに、英語は難しかったら、[英語学習に役に立つTips](https://qiita.com/felius-frank/items/01619bea2e5cd51f5237)はおすすめでございます。