User Story คือคำอธิบายสั้นๆ เกี่ยวกับความต้องการที่เขียนจากมุมมองของผู้ที่จะได้รับประโยชน์จากความต้องการนั้น โดยทั่วไปจะเขียนในรูปแบบของบทบาท ความสามารถที่ต้องการ และเหตุผลที่ต้องการ User Story เกิดขึ้นจากแนวทางการเขียนโปรแกรมแบบ Extreme Programming และกลายเป็นรูปแบบหลักในการแสดงผลงานในการพัฒนาแบบวนซ้ำ
จุดประสงค์ของมันมักถูกเข้าใจผิด เรื่องราวนี้ไม่ใช่ข้อกำหนด แต่เป็นการเตือนให้มีการสนทนาเกิดขึ้น แนวคิดดั้งเดิมอธิบายว่าเรื่องราวเป็นเพียงตัวแทนสำหรับการสนทนาระหว่างผู้ที่ต้องการความสามารถและผู้ที่จะสร้างมันขึ้นมา และข้อความที่เขียนไว้มีไว้เพื่อให้แน่ใจว่าการสนทนาเกิดขึ้น ไม่ใช่เพื่อทดแทนการสนทนา ทีมที่มองว่าการ์ดนี้เป็นข้อกำหนดที่สมบูรณ์ได้นำรูปแบบนี้มาใช้และละทิ้งกลไกไปแล้ว
ส่วนเหตุผลเป็นองค์ประกอบที่มีค่ามากที่สุดและมักถูกเขียนอย่างไม่รอบคอบที่สุด การระบุว่าทำไมจึงต้องการความสามารถนั้น ช่วยให้ทีมสามารถเสนอวิธีแก้ปัญหาที่แตกต่างและมักจะดีกว่าสำหรับความต้องการเดียวกัน และยังช่วยให้สามารถลดลำดับความสำคัญของงานได้อย่างตรงไปตรงมาเมื่อเหตุผลที่แท้จริงนั้นอ่อนแอ เรื่องราวที่มีส่วนเหตุผลเพียงแค่กล่าวซ้ำความสามารถ เช่น ต้องการปุ่มเพื่อกดนั้น ไม่ได้สื่อสารอะไรเลยและตัดโอกาสในการสนทนาในเรื่องนั้นออกไป
ขนาดมีความสำคัญ เพราะเรื่องราวควรจะสามารถเสร็จสมบูรณ์ได้ภายในรอบการทำงานเดียว และส่งมอบสิ่งที่ผู้ใช้สามารถสัมผัสได้จริง เรื่องราวที่ใหญ่เกินไปจะไม่สามารถทำให้เสร็จสมบูรณ์หรือประเมินผลได้ ในขณะที่เรื่องราวที่ถูกแบ่งย่อยออกเป็นชั้นทางเทคนิค เช่น การสร้างตารางฐานข้อมูลหรือส่วนประกอบอินเทอร์เฟซแยกกัน จะไม่ให้ผลลัพธ์ที่สังเกตได้เป็นรายชิ้น การแบ่งส่วนในแนวตั้ง ซึ่งแต่ละเรื่องราวจะตัดผ่านทุกชั้นเพื่อสร้างความสามารถที่บางแต่สมบูรณ์ จะช่วยรักษาความสามารถในการสาธิตและการเรียนรู้ไว้ได้
รูปแบบดังกล่าวเป็นเพียงข้อตกลงมากกว่าข้อบังคับ และการยึดติดอย่างเคร่งครัดจะทำให้เกิดความไม่สมเหตุสมผล งานทางเทคนิคที่ไม่มีผู้ใช้งานโดยตรง เช่น การอัปเกรดส่วนประกอบหรือการปรับปรุงการตรวจสอบ ไม่เข้ากับแม่แบบ และการบังคับใช้จะทำให้เกิดผู้ใช้งานที่ไม่จริงใจที่ต้องการให้ไลบรารีได้รับการอัปเดต การบันทึกงานดังกล่าวอย่างตรงไปตรงมา พร้อมระบุเหตุผล จะมีความซื่อสัตย์และมีประโยชน์มากกว่าการบิดเบือนเพื่อให้ตรงตามรูปแบบ
เกณฑ์การยอมรับเป็นสิ่งที่ทำให้เรื่องราวสามารถทดสอบได้ และเป็นส่วนหนึ่งของเรื่องราวอย่างแท้จริง ไม่ใช่สิ่งที่แยกต่างหาก เกณฑ์เหล่านี้ระบุเงื่อนไขที่เรื่องราวจะถือว่าสมบูรณ์ รวมถึงกรณีพิเศษและเส้นทางข้อผิดพลาดที่รูปแบบการเล่าเรื่องไม่ได้กล่าวถึง หากไม่มีเกณฑ์เหล่านี้ ความสมบูรณ์ก็จะกลายเป็นเรื่องของความคิดเห็น และความขัดแย้งมักจะปรากฏขึ้นในขั้นตอนการตรวจสอบ ซึ่งเป็นช่วงเวลาที่เสียค่าใช้จ่ายในการแก้ไขมากที่สุด
เรื่องราวต่างๆ สะสมจนกลายเป็นรายการค้างที่จัดการได้ยากหากไม่ได้รับการแก้ไข รายการที่เขียนไว้เมื่อหลายเดือนก่อนอธิบายถึงผลิตภัณฑ์และตลาดที่เปลี่ยนแปลงไปแล้ว และรายการค้างที่มีเรื่องราวนับร้อยเรื่องก็เป็นเพียงเอกสารที่ไม่มีใครอ่านมากกว่าจะเป็นแผนงาน การลบเรื่องราวที่ไม่สามารถสร้างได้จริงเป็นระยะๆ นั้นเป็นเรื่องที่น่าอึดอัดใจ แต่มีประโยชน์มากกว่าการเก็บรักษาไว้ตลอดไป
เนื่องจากคุณค่าขึ้นอยู่กับการสนทนามากกว่าตัวชิ้นงาน ประสิทธิภาพจึงถูกตัดสินจากว่ามีผู้เข้าร่วมที่เหมาะสมหรือไม่ ในทางปฏิบัติ รูปแบบนี้ถูกนำไปใช้ภายใน การพัฒนาผลิตภัณฑ์ โดยมีความต้องการพื้นฐานที่ปรากฏให้เห็นได้ผ่านทาง การวิจัยผู้ใช้ แทนที่จะเป็นการสันนิษฐาน และองค์กรที่สร้างความสามารถนี้ขึ้นภายในมักจะจัดตั้งแนวทางการเขียนและการปรับปรุงแก้ไขไว้ภายในองค์กรเอง แผนกผลิตภัณฑ์ เพื่อให้เรื่องราวต่างๆ เกิดขึ้นจากปัญหาที่ได้รับการยืนยันแล้ว