使用者故事(User Stories)
前面談完Product Backlog，可是我們並沒有說明要如何撰寫Product Backlog。在Agile中我們通常是以一個叫User Story的東西，來描述Product Backlog的內容。
這也就是說，你是可以以別種方式來描述Product Backlog的內容，例如use case或是傳統的需求規格書。Agile並沒有做限制。
可是你會什麼問那我們為什麼要用User Story？為什麼要多學一個新的東西呢？那什麼又是User Story呢？接下來就讓我一一道來。
什麼是使用者故事
在wiki中的定義大致如下：
# 它是軟體系統的需求
# 由一句或是數句敘述所組成，並且是使用使用者的語言來描述
# 使用者故事被使用在Agile軟體開發方法中，用來輔助需求規格和驗收測試
# 使用者故事通常是寫在便利貼的小紙片上，並且是由顧客來撰寫。
來源：http://en.wikipedia.org/wiki/User_story
通常大家在寫User Story時，常常會犯一個錯誤，那就是每次都只有一個user。所以常常你找出來的User Story 都很狹隘，因為你沒有從不同使用者的角度來看事情，你只從你認為的使用者角度來看事情。
比較好的作法是從使用者的角色來看User Story，不同的角色會有不同的考量重點，自然對系統要求的功能便大不相同。你可以去思考不同角色的所處的背景為何，她們要用軟體來解決什麼問題，她們會怎麼用等等。所以是以用法為導向來思考User Story。
另外有一類的user大家比較容易忽略的，就是非使用者的角色，像是系統和程式設計師。他們也會和要開發的系統有互動的關係，也要記得考慮進去。以下是它們的範例：
Ex 1: As the payment verification system, I want all transactions to be well-formed XML
Ex 2: As a programmer, I want an API for deleting widgets from the database
留言列表
