建立絕佳的產品待處理項目
您的小組會建立產品待處理項目 (通常會包含使用者本文) 來代表其客戶所需要和重視的項目。 在專案進行期間，您的小組會將詳細資訊加入至使用者本文、將它們細分為更小的本文、排定其優先權並加以估計，最後實作它們並將結果交付給客戶。 藉由撰寫大型使用者本文並持續更新產品待處理項目，您的小組將可以更有效率地提供客戶所需要的價值。
Bill Wake 使用 INVEST 縮略字 (獨立、可交涉、重要、可估計、小型和可測試) 來摘要說明了良好使用者本文的構成要件。 如需詳細資訊，請參閱下列網站：XPlorations (英文)。 Mike Cohn 在他所著的其中一書中討論了如何撰寫使用者本文，而且您可以從下列網站下載相關章節：User Stories Applied for Agile Software Development (英文)。
當您的小組建立使用者本文時，請回答下列問題，確定它代表客戶價值：
使用者是誰
使用者需要做什麼
使用者需要這麼做的原因為何
在大部分情況下，您的小組可以透過建立有效的標題，達到此目的。 Mike Cohn 建議使用下列格式：「身為 <使用者>，我需要 <動作> 以便 <原因>」。 在「身為客戶支援代表，我需要存取客戶資訊，以便更快速地回應客戶問題」範例中，您可以看見這種做法。在許多情況下，原因很明顯。 例如，「身為素食主義者，我可以篩選檢視，以便只看到素食餐點」。
您也應該用某種方式定義使用者本文，讓它們能夠按照任何順序實作。 不過，讓使用者本文完全獨立不一定可行。 Bill Wake 和 Mike Cohn 都描述了當小組讓使用者本文獨立很困難時，可以使用的技巧。
如先前所述，重要和獨立的使用者本文構成了產品待處理項目。 它們會進行估計並排定優先權，然後您的小組再開始處理最高順位的使用者本文。 在您的小組實作使用者本文之前，它必須具備下列清單中的特性。 您的產品擁有者將致力於確定最高順位的使用者本文符合這些準則，然後再將它們帶入期程 (Sprint) 計劃會議中。
夠小，能夠在期程中實作
即將實作的使用者本文必須夠小，能夠在期程中完成。 您的產品擁有者將與小組一起細分太大的使用者本文。 例如，「身為客戶支援代表，我需要存取客戶資訊，以便更快速地回應客戶問題」使用者本文可能太大，無法在期程中完成。 您可以將它細分為其他本文，例如「身為客戶支援代表，我需要使用客戶的電話號碼來存取客戶的名稱以及最近的通話摘要」以及「身為客戶支援代表，我需要存取客戶的完整通話記錄，以便更詳細地研究目前的問題」。
夠詳細，能夠描述和估計實作本文所需的工作
將使用者本文加入至期程之前，您會使用本文點來估計它們。 這些是刻意的概略估計，主要用來管理待處理項目以及協助為期程進行準備。 當期程開始時，您的小組會將使用者本文細分為實作它所需的工作。 在產品待處理項目整備會議中，您的小組將與產品擁有者一起判斷哪些本文需要更多資訊，然後才能細分為工作，以便估計工作時數。 您的產品擁有者可以蒐集這些詳細資料並在使用者本文的描述中記錄它們。
請小心不要將過多非必要的詳細資料加入至使用者本文。 使用者本文應該是與產品擁有者和客戶進行交談和協商的基礎，而且交談和協商會繼續進行，直到已完成和接受使用者本文為止。 太多詳細資料可能會產生不精確的含意，因而妨礙協商進行。
定義的驗收準則
在期程結束時，您的客戶或產品擁有者將接受已完成的使用者本文或拒絕它。 在期程開始之前，應該盡可能清楚地描述客戶驗收的準則。 當然，使用者本文可能會由於非預期的原因而不被接受。 不過，為了協助定義驗收準則，小組與客戶之間的交談將有助於確定小組了解客戶的期望。 驗收準則可以當做接受度測試的基礎使用，讓您能夠更有效地評估是否已完成使用者本文。
史詩和主題
大家都知道，使用者本文應該要很小。 即將實作的使用者本文更是如此。 不過，較低順位的本文可能會比較大。 事實上，讓這些本文較大能夠有效避免產品待處理項目變得太大而無法管理。 當使用者本文接近已排定優先權的產品待處理項目頂端時，您就可以將它們細分為較小的使用者本文。 將大型使用者本文視為史詩和主題會很有用。
史詩是非常大型的使用者本文，代表大量工作。 當您細分史詩時，可能會建立許多主題和其他較小的使用者本文。
主題是相當大的使用者本文，通常比您在期程中實作的使用者本文更大。 在您的小組實作主題之前，它必須細分為較小的使用者本文。
當您排定產品待處理項目的優先權時，請細分頂端附近的史詩和主題，然後排定新且較小使用者本文的優先權。 完成之後，最高優先權的使用者本文應該會夠小，能夠實作。 在已排定優先權的待處理項目底部，大部分使用者本文通常會比較大。
增量
您的小組有時候需要進行間接實作使用者本文的工作。 這種工作稱為增量。 三種常見的增量包括研究、尚未解決的 Bug，以及流程或工程改良。 若要在 Team Foundation 中建立增量，請建立使用者本文工作項目、將類型設定為 [增量]，然後在產品待處理項目中，與其他使用者本文一起排定優先權。
研究
進行研究的時機如下：存在有關使用者本文的未解答問題，而且必須先回答此問題，才能將使用者本文完全細分為工作並進行估計。 例如，小組在期程計劃會議期間遇到「身為飛行常客，我可以訂購優惠行程」本文。 經過討論之後，他們提出更多問題。 小組會建立使用者本文來代表增量。「 「身為小組成員，我可以了解「訂購優惠行程」的意義，以便撰寫要納入未來期程中的本文」。小組會判斷他們願意投入該項研究的時數，並且撰寫該數字當做增量的時間框限。 在增量期間撰寫的本文都無法在該反覆項目期間完成。 您必須使用產品待處理項目，針對未來的反覆項目排程此工作。
尚未解決的 Bug
修正 Bug 的最佳時間就是發現 Bug 的時間。 如果您無法在發現 Bug 的同一天修正 Bug，就應該建立 Bug 工作項目，確保能夠追蹤此 Bug。 請小心避免累積 Bug。 如果您的小組累積了 Bug，請建立使用者本文，並且將這些 Bug 連結至增量，以便與其他使用者本文和增量一起估計和排定優先權。
流程或工程改良
您的小組將進行流程或工程改良，以便協助驅動小組邁向成功。 這些改良通常是在期程追溯性會議和每日 Scrum 會議期間識別的。 例如，您的小組可能需要透過單元測試改善程式碼涵蓋範圍，或是減少連續整合伺服器的建置時間。