読んでますけど、めちゃわかりやすい。

スケジュール通りにいかないのが当たり前なんだ！

134ページ

それに、真剣に相対サイズでの見積りに取り組んでいれば、単位が何なのかなんて気にならない。大事なのは見積もったストーリー同士のサイズを、それぞれのあいだできちんと相対的な大きさとして表現できているかどうかなんだから。見積りが相対サイズになっていれば、ストーリーのひとつひとつには過大見積もりや過小見積りがあったとしても、全体としての辻褄は合うはずなんだ。
見積もりの単位にポイントを採用することには、次のようなメリットがある。
・見積もりとは当てずっぽうであることを肝に銘じることができる。
・見積もりとは純粋に大きさを測るものだと考えることができる（そのほうが見積り結果の賞味期限が長い）
・手早く、気軽に、シンプルに見積もれる。
さまざまな調査結果からも、このやり方ならうまくいくことがわかっている。

127ページ

私たちには、次の3つの条件を満たすような見積もり手法が必要だ。
・今後の計画を立てられる
・見積もりは当てずっぽうだという前提を踏まえている
・ソフトウェア開発の複雑さを認めている

120ページ

フローチャートと、それに対応するざっくりしたペーパープロトタイプがあれば、アプリケーションの中核をなすユーザーストーリーのほとんどを導き出せると思う。ユーザーストーリーの抽出にあたっては、小さくて、具体的な、エンド・ツー・エンドの機能にすることを心がけよう（1日から5日で実装できるサイズを目安にしよう）。もちろん、なかにはもっと大きなストーリーもあるだろう。目安としては、実装に数週間かかりそうな大きさであれば、エピックとして扱う。
エピックはざっくりとした計画を立てるときには扱いやすい。また、大きなストーリーで、多分やらないといけないんだろうけども、本当に必要なのかはまだ確信が持てないものを括り出しておくにも便利だ。もし主要な機能がエピックになっていたとしても、他のストーリーと同じように扱おう。もちろん、そのエピックを実際に開発することになれば、そのときには複数のストーリーに分割しなきゃ実装はできないだろう。
ストーリー収集ワークショップでは、一日かけて開催した場合で、ざっくりとしたストーリーを10~40ぐらい書きだせば十分だろう。これぐらいあれば、向こう3ヶ月から6ヶ月ぐらいの計画を立てられる。書きだしたストーリーが数百もあるのだとしたら、それは半年以上先の遠くまで計画を立てようとしているか、詳細に立ち入りすぎているかのどちらかだ。今の時点で優先すべきは幅だ（深さじゃない）。深みにはまって身動きが取れなくなっちゃいけない。

95ページ

進軍指令が誰から来ているのかがわからない状況ほど現場を混乱させるものはない。＜中略＞チームの向かう先や、仕事の優先度、次のやるべきことについて、異なった思惑を持ったステークホルダーが何人もいて、それぞれがチームに言い寄ってくる状況だとしたら、それはまずい。バスの運転手は誰なのか？そのことをあらかじめはっきりさせておこう。ただしこれは、運転手以外のステークホルダーに発言権が一切ないという意味じゃない。むしろそんなことはあっちゃいけない。ただ、開発チームに語りかける声は一つにしておきたいというだけの話しだ。プロジェクトの今の段階で、誰が決断を下すのかということを確認しておけば、後で起きることになるであろう様々な混乱を防ぐことができる。高くつく手戻りや再調整も避けられるはずだ。