用戶故事是從用戶的角度對系統功能的描述，通過與用戶一起探討而得出，事實上XP的實踐應由用戶親手撰寫用戶故事，但對很多用戶來說並不容易，所以很多的實踐過程中是開發人員和用戶一起撰寫。
開發人員依照用戶故事中的描述估測完成每個任務需要的時間，並從項目經理處認領自己負責的任務，通常鼓勵開發人員每次認領不同類型的任務，以提升對整個項目的認識及對不同類型技術的掌握。此處估測的時間在項目初期可能和實際完成時間有較大差距，但通過一段時間的實施之後，故測的時間也能八九不離十了。
領得自己負責的任務後，開發人員尋找結隊夥伴，並開始實施過程。兩者在邊討論邊設計的過程中產生軟件設計，並付諸測試和代碼，此處產生的成果只有單元測試和代碼而已，至於設計可以全部置於草稿紙上，一旦測試和代碼完成便沒有任何意義。若討論過程中有明顯的分歧，應該以任務負責人的想法爲先。應該注意的是，這裏爲每個任務都分配了“負責人”，但XP的思想是整個開發團隊對代碼負責，而不是個人，因爲事實上即使是單個任務也是由多個開發人員共同完成的。XP鼓勵要經常更換結隊夥伴，即使只是在一個任務中。
以下是一個用戶故事的樣例：
故事2運行處理退款請求故事（優先級：高 技術風險：低）
估算：開發時間 2周
2.1 獲得某時間段銀行的退款明細 0.5天
2.2 分頁顯示某時間段銀行的退款明細列表，提供選擇退款記錄 2.5天
2.3 運行處理退款 2天
2.4 （約束）2.3可以補充退款信息卡號、姓名信息，如果要求輸入卡號要輸入2遍複覈
2.5 （約束）2.4輸入卡號提供3個4位輸入第4個不限位數的分割輸入，利於校對
2.6 （約束）2.4卡號欄目後面要留輸入標註（本）（異）來區分本地卡和異地卡的空間
2.7 （約束）2.3可以選擇部分或全部明細進行退款處理
2.8 （約束）2.3處理後退款明細記錄狀態要變更爲運行已處理狀態，並置運行處理日期
2.9 （約束）2.3按確認後要一個確認對話框，防止誤操作
2.10 可以按條件獲得退款明細列表 1天
2.11 （約束）2.10條件可以爲：銀行&退款處理狀態&退款請求日期段
2.12 （約束）2.10條件可以爲：商戶&退款處理狀態&退款請求日期段
2.13 （約束）不需要查詢還在申請狀態的退款
2.14 分頁顯示按條件獲得運行已處理的退款明細列表 1.5天
2.15 （約束）2.14表頭裏須含查詢條件信息及總筆數與金額信息
2.16 可以下載退款明細列表 2.5天
2.17 （約束）2.16數據組織成execl表格格式
2.18 （約束）2.16表可以按每個支付網關生成一份
2.19 （約束）2.16表可以按每個商戶生成一份
2.20 （約束）2.16表中，部分支付網關除基本欄目外，一些欄目可以配置打印與否。
2.21 可以把運行已經處理過的退款交易回退給運行部門重新處理。
2.22 （約束）2.21可回退的退款交易必需是還沒有被財務退過款的。