เรื่องราวของผู้ใช้งาน (user story) เป็นรูปแบบที่ใช้ในการบันทึก backlog ที่ช่วยให้ผู้ใช้งานและทีมพัฒนาได้หารือกันเพื่อรวบรวมความต้องการได้แม่นยำมากขึ้นและถูกใช้มากในวิธีการแบบ agile เพื่อให้สามารถระบุได้ว่าใครเป็นผู้ใช้งาน คาดหวังการใช้งานไว้อย่างไร ต้องใช้องค์ประกอบอะไรบ้าง ต้องใช้งบประมาณเท่าไร และใช้เวลาในการพัฒนานานแค่ไหน ซึ่งจะช่วยให้เราพิจารณาว่าควรพัฒนาหรือไม่ควรพัฒนา เรื่องราวของผู้ใช้งานประกอบด้วย 5 ส่วนใหญ่ๆคือ (1) พิจารณาบทบาท เป้าหมาย และประโยชน์ที่ได้ (role-goal-benefit) ซึ่งผู้ใช้งานต้องพิจารณาว่า ใคร ทำอะไร และจะได้ประโยชน์อย่างไรจากสิ่งที่จะทำ ซึ่งใครที่ว่าอาจจะหมายถึงระบบงานอื่นก็ได้ รวมถึงพิจารณาเป้าหมายจริงๆที่ต้องการว่าคืออะไรและทำไมถึงต้องบรรลุเป้าหมายนั้น โดยต้องอธิบายได้อย่างชัดเจน ซึ่งการพิจารณานี้ช่วยให้เราตัดสินใจได้ว่าสิ่งที่จะทำมันคุ้มค่าและสร้างมูลค่าได้จริงๆ (2) พิจารณาขอบเขตและข้อจำกัด (limitation) ของสิ่งที่ต้องการเพื่อที่จะไม่ต้องพัฒนาอะไรที่เกินจำเป็น (3) ระบุความคาดหวัง (validation) ที่ต้องการอย่างชัดเจนซึ่งนำไปสู่วิธีการตรวจวัดและทดสอบ (4) พิจารณาว่าแต่ละฟังก์ชั่นทำงานร่วมกันอย่างไรทั้งในระบบงานเดียวกันและต่างระบบงาน (engineering note) (5) ประเมินทรัพยากร เวลา และงบประมาณ (cost) ที่ต้องใช้ในการพัฒนาเทียบกับประโยชน์ที่จะได้ ซึ่งนอกจากจะช่วยคัดแยกว่าอะไรควรพัฒนาหรือไม่ควรพัฒนา ยังจะช่วยให้เราจัดลำดับความสำคัญของสิ่งที่ต้องการพัฒนาได้ด้วย การประเมินเหล่านี้จะถูกทำสำหรับแต่ละวงรอบของการพัฒนาทั้งนี้เพื่อให้สามารถกลับไปทบทวนกับลูกค้าได้รวดเร็ว