User Story的細節呢?
很多人會說這樣的一句話，怎麼足夠表現出需求詳細的內容呢？很多細節我們還是不知道。那到底要怎麼辦呢？
其實User Story的重點是在於溝通。也就是希望程式設計師和顧客好好坐下來，一起談論想要的功能是什麼，想要拿它來解決什麼問題。也就是真正去了解整個來龍去脈，而並不是花時間去把文件寫的盡善盡美。所以這句話只是開頭，接下來的交談才是重點。
當然User Story並不是這麼不負責任，讓我們來看可以怎麼做。
User Story通常是寫在小卡片或是便利貼上面，因此在正面寫完User Story的描述後，在背面我們可以再增加一些資訊來說明的更清楚。
那要增加什麼資訊呢？User Story的作法是把客戶會滿意的條件加進去，也就是考量哪些事情是顧客所顧慮的，把它們都一一列到卡片的後面。這不但可以讓你知道這需求更詳細的內容，也知道哪些是它們要的優先順序，最後還可以把它們視為驗收測試的標準。但是不要忘記這些都是溝通後所得到的結果。
使用者故事(User Stories)
前面談完Product Backlog，可是我們並沒有說明要如何撰寫Product Backlog。在Agile中我們通常是以一個叫User Story的東西，來描述Product Backlog的內容。
這也就是說，你是可以以別種方式來描述Product Backlog的內容，例如use case或是傳統的需求規格書。Agile並沒有做限制。
可是你會什麼問那我們為什麼要用User Story？為什麼要多學一個新的東西呢？那什麼又是User Story呢？接下來就讓我一一道來。
什麼是使用者故事
在wiki中的定義大致如下：
Product Backlog所面臨的問題
1. Product Backlog的來源有很多個
一般來說，資料的來源有以下幾類：
(1) 產品功能：在這一次版本中需要實作的功能。
Product Backlog
在專案一開始時，需要有一份要處理的工作項目。在傳統專案中，我們會使用需求規格書，或是者是使用個案。可是在Scrum的軟體開發中，我們使用的是Product backlog這個東西。你會問說這又是什麼新的名詞呢？讓我們來看看大家怎麼定義它：
A. Wiki上的定義
- 對於整個專案來說，它是一個較高層次(high-level)的文件。
- 包含了所有想要功能的描述，或者是wish-list等等。
- 是根據商業價值來排定優先順序
功能, 時程, 和成本
在專案管理中, 功能, 時程, 和成本, 一直是最重要的三個要素, 也是不容易取得平衡的三個要素. 因此你可以看到你的專案經理, 常常痛苦掙扎要如何在三者間取捨, 到底要犧牲那幾個, 保留哪幾個.
傳統的一種作法(waterfall)是將要交付的功能固定, 然後在成本和時程間做調整. 主要是以計劃導向(plan-driven), 來導出時程和成本的規劃.
不過這種作法, 往往犧牲的是成本. 因為通常時程無法做大幅變動, 因此只好在成本上考量. 這時候你會做的一件事情, 就是犧牲品質這項成本. 少點測試, 沒有檢視, 或是一寫完就交付.
可是這樣的東西會真的是你要的嗎? 這樣不好的循環, 真的無法打破嗎?
在agile中, 它試著改變這樣的假設, 認為交付功能是可以變動的. 因為功能這種東西不見是越多越好, 適用最重要.
