而本篇則是描述這類的測試回報，可以採用 user story 的方式來和工程師溝通。而要怎麼寫，內文有詳細的解釋。
最令曾經擔任過 PM 的編輯感到認同的是，本文作者提到：「規格就算寫再細，工程師解讀時，都還是有可能漏東西的。而用 User Story 來描述，不但容易閱讀，也可以在不需要把所有細節都說完的狀況下讓開發者可以自動補完規格。因為 User Story 闡述的是一個『動機』，只要你明白一個人的動機，就很容易可以預測他的行為。」
Google 前工程總監 David Jeske, 認為，這取決於你產品開發的複雜性，以及客戶對你的互動需求。如果你的開發過程需要客戶參與，也時常面臨客戶臨時提案的變動，或是產品介面擁有大量 customer visible feature，那麼 agile 的「短線思維」就可因應這種需要快速調整的工作狀態。
但 Google 這類公司提供的軟體及雲端服務，需要縝密的設計與規劃，產品必須有一定的成熟度與完整度，才能讓客戶使用，不然產品本身可能根本無法運作。 David Jeske 的回答雖然獲得最多的 upvote，但建議讀者還是可以去看看其他人的回覆：agile 是一種精神原則，還是只是做事方法，又或只是風氣？
原來賈伯斯本人很喜歡腳踏車的類比，甚至想把當時正在開發的「麥金塔」（Macintosh）專案代號改叫「Bicycle」。作者 Steven Sinofsky 從一些過去的影像紀錄、華爾街日報廣告、電視節目片段（當時賈伯斯曾經作為來賓參加新聞台節目），最後再到一篇賈伯斯署名的雜誌文章，你會發現原來賈伯斯早就用過那個很有名的「卡車 vs. 轎車」比喻，當時他把大型主機（mainframe）比喻成火車，個人電腦則是福斯的金龜車。
這篇文章原本是一系列的推文，所以閱讀起來可能會有點不自然，但無損於這篇考據文章的內容。作者 Steven Sinofsky 是前微軟高層，領導過 Office、Windows 7 和 Windows 8 的開發。
