วิธีเขียน User Stories (พร้อมตัวอย่างและ Acceptance Criteria)

user story คือคำอธิบายสั้น ๆ ของฟีเจอร์จากมุมมองของผู้ใช้: “ในฐานะ [ประเภทของผู้ใช้] ฉันต้องการ [เป้าหมาย] เพื่อให้ [เหตุผล]” ใต้ story คุณเขียน acceptance criteria ซึ่งเป็นเงื่อนไขเฉพาะไม่กี่ข้อที่ต้องเป็นจริงเพื่อให้ story ถือว่าเสร็จ ทำให้แต่ละ story เล็กพอที่จะสร้างและทดสอบได้ในครั้งเดียว และเขียนเกณฑ์ให้ใครก็ตรวจได้

ทีมพัฒนาแบบ agile ทำให้ user stories เป็นที่รู้จัก แต่มันมีประโยชน์พอ ๆ กันเมื่อคุณสร้างเองด้วย AI app builder story ที่ดีคือพรอมต์ที่ดี

รูปแบบ

user story มีสามส่วน:

ในฐานะ [ใคร] ฉันต้องการ [อะไร] เพื่อให้ [ทำไม]

• ใคร คือผู้ใช้ประเภทเฉพาะ เช่น ผู้เยี่ยมชมครั้งแรก สมาชิกที่จ่ายเงิน พนักงานต้อนรับของคลินิก ผู้ดูแลระบบ ไม่ใช่ “ผู้ใช้”
• อะไร คือสิ่งที่เขาอยากทำ ด้วยคำพูดของเขาเอง ไม่ใช่วิธีที่หน้าจอทำงาน
• ทำไม คือผลลัพธ์ที่เขาใส่ใจ เป็นส่วนที่คนมักข้าม และเป็นส่วนที่หยุดคุณไม่ให้สร้างสิ่งที่ผิด

ตัวอย่าง:

ในฐานะสมาชิกยิม ฉันต้องการยกเลิกการจองคลาสจากโทรศัพท์ เพื่อให้คนในรายการรอสามารถรับที่ของฉันได้ และฉันไม่ต้องเสียค่าไม่มาเข้าร่วม

“ทำไม” บอกสองสิ่งที่ “อะไร” ไม่ได้บอก: มันต้องทำงานบนมือถือ และเกี่ยวข้องกับรายการรอและกฎค่าปรับ

acceptance criteria

story บอกสิ่งที่ต้องการ acceptance criteria บอกว่าเมื่อใดถือว่าเสร็จ ควรเฉพาะเจาะจงพอที่คนสองคนจะเห็นตรงกันว่าแต่ละข้อผ่านหรือไม่

วิธีเขียนที่นิยมคือ Given / When / Then:

• Given สถานการณ์เริ่มต้น
• When ผู้ใช้ทำบางอย่าง
• Then นี่คือผลลัพธ์

สำหรับ story การจองยิม:

1. Given ฉันมีการจองที่อยู่อีกมากกว่า 12 ชั่วโมง when ฉันแตะ Cancel และยืนยัน then การจองจะถูกลบ และฉันเห็น “ยกเลิกการจองแล้ว”
2. Given ฉันยกเลิกการจองและคลาสนั้นมีรายการรอ when การยกเลิกถูกบันทึก then คนแรกในรายการรอจะได้ที่นั่งและได้รับอีเมล
3. Given การจองที่อยู่น้อยกว่า 12 ชั่วโมง when ฉันแตะ Cancel then ฉันเห็นว่ามีค่าปรับการยกเลิกช้าก่อนยืนยัน
4. Given ฉันอยู่บนหน้าจอความกว้างมือถือ then ปุ่ม Cancel มองเห็นได้โดยไม่ต้องเลื่อนไปด้านข้าง

เช็กลิสต์ธรรมดาก็ใช้ได้ ตราบใดที่แต่ละข้อทดสอบได้ “การยกเลิกทำได้ง่าย” ทดสอบไม่ได้ แต่ “การยกเลิกทำได้มากที่สุดสองแตะจากรายการการจอง” ทดสอบได้

ทีละขั้นตอน: เขียน story ที่ดี

ขั้นที่ 1: เริ่มจากผู้ใช้จริงและปัญหาจริง

เลือกผู้ใช้หนึ่งประเภทและสิ่งที่พวกเขาลำบากอยู่ในปัจจุบัน ถ้าคุณเคยสัมภาษณ์ลูกค้า ให้ใช้คำพูดของพวกเขา “ฉันมักลืมยกเลิกแล้วโดนเก็บเงิน” เป็นจุดเริ่มต้นที่ดีกว่า “เพิ่มฟีเจอร์ยกเลิก”

ขั้นที่ 2: เขียน story หนึ่งบรรทัด

กรอกเทมเพลต หากคุณเขียน “เพื่อให้” ที่น่าเชื่อถือไม่ได้ ให้ถามว่าฟีเจอร์นี้จำเป็นจริงหรือไม่

ขั้นที่ 3: เพิ่ม acceptance criteria สามถึงหกข้อ

ครอบคลุมกรณีสำเร็จหลักก่อน แล้วค่อยเป็นความแตกต่างที่สำคัญ: บทบาทอื่น สถานะว่าง ขีดจำกัด ข้อผิดพลาด หากคุณเขียนเกินหกข้อ story นั้นน่าจะใหญ่เกินไป

ขั้นที่ 4: ระบุสิ่งที่อยู่นอกขอบเขต

หนึ่งบรรทัดช่วยประหยัดการไปมาได้มาก: “นอกขอบเขต: การคืนเงินสำหรับคลาสที่จ่ายแล้ว และผู้ดูแลยกเลิกแทนสมาชิก” ป้องกันไม่ให้ story ขยายตัวระหว่างการสร้าง

ขั้นที่ 5: ตรวจกับ INVEST

INVEST คือเช็กลิสต์ที่นิยมสำหรับ story ที่ดี story ควร:

คุณไม่จำเป็นต้องให้คะแนนทุก story มันมีประโยชน์ที่สุดเมื่อ story รู้สึกไม่ถูกต้องและคุณอยากรู้ว่าเพราะอะไร

ตัวอย่างที่ดีและไม่ดี

วิธีแบ่ง story ที่ใหญ่เกินไป

story ใหญ่คือจุดที่โปรเจกต์มักชะงัก วิธีแบ่งที่พบบ่อย:

• ตามบทบาทของผู้ใช้ สมาชิกยกเลิกการจองของตัวเอง เจ้าหน้าที่ยกเลิกของใครก็ได้
• ตามขั้นตอนในโฟลว์ เรียกดูคลาส จองคลาส รับการแจ้งเตือน
• กรณีง่ายก่อน ยกเลิกคลาสฟรีตอนนี้ จัดการค่าธรรมเนียมและการคืนเงินใน story ถัดไป
• ตามความแตกต่างของข้อมูล รองรับหนึ่งสาขาก่อน หลายสาขาทีหลัง
• เส้นทางสำเร็จก่อน แล้วค่อยเป็นข้อผิดพลาด สร้างให้ทำงานได้ก่อน แล้วค่อยเพิ่มการจัดการกรณีคลาสเต็ม พาสที่หมดอายุ และอื่น ๆ

แต่ละชิ้นควรยังเป็นสิ่งที่ผู้ใช้ใช้ได้และสังเกตเห็นได้

ใช้ user stories เป็นพรอมต์

user story ที่มี acceptance criteria ใกล้เคียงกับพรอมต์ที่ดีสำหรับ AI app builder มาก มันให้ AI รู้ว่าใคร ต้องการอะไร ทำไม และนิยามของความเสร็จ ส่ง story หนึ่งข้อต่อหนึ่งข้อความ:

ในฐานะสมาชิกยิม ฉันต้องการยกเลิกการจองคลาสจากโทรศัพท์ เพื่อให้คนในรายการรอรับที่ของฉันได้ Acceptance criteria:

1. มีปุ่มยกเลิกในแต่ละการจองใน My Bookings พร้อมขั้นตอนยืนยัน
2. ยกเลิกก่อนคลาสเกิน 12 ชั่วโมง ให้ลบการจองอย่างเดียว
3. น้อยกว่า 12 ชั่วโมงก่อนเริ่ม ให้แสดง “มีค่าปรับการยกเลิกช้า 5 ดอลลาร์” ก่อนยืนยัน และบันทึกค่าปรับในการจอง
4. ถ้าคลาสมีรายการรอ คนแรกจะได้ที่และได้รับอีเมล
5. ใช้งานได้บนหน้าจอความกว้างมือถือ นอกขอบเขต: การคืนเงิน เจ้าหน้าที่ยกเลิกแทนสมาชิก สร้างฟีเจอร์นี้ แล้วตรวจแต่ละเกณฑ์ในพรีวิว และบอกฉันว่าข้อไหนผ่าน

คุณยังขอให้ AI ร่าง story จากไอเดียคร่าว ๆ แล้วแก้ไขเองได้:

นี่คือไอเดียแอปของฉัน: [สองหรือสามประโยค] เขียน user stories สำหรับเวอร์ชันแรก จัดกลุ่มตามประเภทผู้ใช้ แต่ละข้อมี acceptance criteria แบบ Given/When/Then สามถึงห้าข้อ ระบุว่าข้อไหนจำเป็นสำหรับการเปิดตัว และข้อไหนรอได้

อ่านและแก้ไขผลลัพธ์เสมอ AI ไม่รู้จักผู้ใช้ของคุณ คุณรู้

acceptance criteria ยังทำหน้าที่เป็นแผนทดสอบของคุณด้วย เมื่อ story ถูกสร้างแล้ว ให้ไล่ตรวจแต่ละเกณฑ์ด้วยตัวเอง คู่มือวิธีทดสอบแอปก่อนเปิดตัว ต่อยอดจากเรื่องนี้

user stories อยู่กับเอกสารอื่นอย่างไร

• เอกสาร product requirements อธิบายผลิตภัณฑ์ทั้งหมด: ปัญหา ผู้ใช้ ขอบเขต user stories คือชิ้นรายละเอียดภายในนั้น ดูวิธีเขียน PRD ด้วย AI
• รายงานบั๊ก อธิบายสิ่งที่พังเทียบกับ story ที่สร้างไปแล้ว ดูวิธีเขียนรายงานบั๊กที่ดี
• MVP คือชุด story ที่เล็กที่สุดที่ส่งมอบคุณค่าหลัก ดูMVP คืออะไร

ความผิดพลาดที่พบบ่อย

• “ในฐานะผู้ใช้…” กว้างเกินไป ระบุประเภทของผู้ใช้จริง
• ข้าม “เพื่อให้” หากไม่มีเหตุผล คุณจะตัดสินใจแลกเปลี่ยนได้ไม่สมเหตุสมผล
• เขียนวิธีแก้แทนความต้องการ “ฉันต้องการ dropdown” ล็อกการออกแบบก่อนที่ใครจะคิดถึงมัน
• เกณฑ์ที่ทดสอบไม่ได้ “ง่าย” “เร็ว” และ “ใช้ง่ายสุด ๆ” เป็นความปรารถนา ไม่ใช่เกณฑ์
• story ที่จริง ๆ แล้วเป็น epic “จัดการบัญชีของฉัน” คือ story สิบข้อ
• เขียนทุก story ล่วงหน้า เขียนไม่กี่ข้อถัดไปอย่างละเอียด และเก็บที่เหลือเป็นบรรทัดเดียวจนกว่าจะถึงเวลา

Stories ใน Mythex

ใน Mythex โหมด Plan เป็นที่ดีในการเปลี่ยนไอเดียเป็น stories เอเจนต์จะพูดคุยเรื่องแนวทางก่อนแก้ไขอะไร เมื่อ story พร้อมแล้ว สลับไปโหมด Build แล้ววางเข้าไป หนึ่ง story ต่อหนึ่งข้อความ หลังแต่ละข้อ /test สามารถคลิกผ่านพรีวิวและตรวจโฟลว์ได้ และคุณย้อนข้อความตอบกลับใดก็ได้ด้วย Revert to this point หากไปผิดทาง ดูพรอมต์ที่ได้ผล ในเอกสาร และคู่มือของเราเรื่องการเขียนพรอมต์สำหรับ AI app builder

เช็กลิสต์ user story

• ระบุประเภทของผู้ใช้เฉพาะเจาะจง
• อธิบายความต้องการ ไม่ใช่การออกแบบ
• มีเหตุผล “เพื่อให้” ที่แท้จริง
• มี acceptance criteria ที่ทดสอบได้สามถึงหกข้อ
• ครอบคลุมกรณีพิเศษหรือข้อผิดพลาดอย่างน้อยหนึ่งกรณี
• ระบุสิ่งที่อยู่นอกขอบเขต
• เล็กพอที่จะสร้างและทดสอบในรอบเดียว
• ตรวจเกณฑ์หลังสร้างเสร็จ ทีละข้อ

คำถาม