Scrum Guide | 21. ความผิดพลาดของ User Story

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

ข้อผิดพลาดเกี่ยวกับ User Story ที่พบบ่อยที่สุด – สารบัญ:

1. บทนำ
2. ปัญหาเกี่ยวกับ 3W
3. ปัญหาเกี่ยวกับ 3C
4. ความผิดพลาดของ User Story – Summary

บทนำ

User Story สามารถเป็นเครื่องมือที่ยอดเยี่ยมในการจูงใจทีมให้เสนอวิธีแก้ไขปัญหาใหม่ที่นำเสนอจากมุมมองของผู้ใช้ เราเขียนเกี่ยวกับ User Story ในรายการแยกต่างหาก และในบทความนี้ เราได้แนะนำ INVEST ซึ่งเป็นวิธีการเขียน User Stories ที่ดีที่เป็นที่นิยม วันนี้เราจะ มาพูดถึงความผิดพลาดของ User Story

ปัญหาเกี่ยวกับ 3W

User Story ที่เหมาะสมจะตอบคำถาม:

• ใคร? (ใครคือผู้ใช้เป้าหมายของผลิตภัณฑ์)
• อะไร (ความสามารถอะไรของผลิตภัณฑ์ และทำอะไรได้บ้าง)
• ทำไม (มีไว้เพื่ออะไร?)

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

ใคร – ตัวตนของผู้ใช้

หนึ่งในข้อผิดพลาดที่พบบ่อยที่สุดเมื่อสร้าง User Stories ไม่ได้ตอบคำถามได้อย่างแม่นยำเพียงพอ: เพื่อใคร กล่าวอีกนัยหนึ่ง ใครคือผู้ใช้ที่ต้องการเปลี่ยนแปลงตามแผน

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

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

ทำไม – เป้าหมายที่กำหนดไว้ไม่ดี

บางครั้งส่วนสุดท้ายของ User Story ก็กลายเป็นต้นตอของปัญหา ควรระบุ มูลค่าทางธุรกิจของการเปลี่ยนแปลงที่ เกิดขึ้นระหว่างการดำเนินการ User Story ดูตัวอย่างข้อผิดพลาด User Story ที่คำอธิบายฟังก์ชันเพิ่มเติมมาแทนที่เป้าหมาย:

ในฐานะลูกค้า ฉันต้องการซื้อไม้กายสิทธิ์ได้ด้วยคลิกเดียว เพราะฉันต้องการซื้อพรมที่บินได้ในสัปดาห์หน้า

แทนที่จะให้เหตุผลในการซื้อไม้กายสิทธิ์ User Story นี้จะเพิ่มรายการอื่นลงในรายการซื้อของของผู้มีโอกาสเป็นลูกค้า ดังนั้น เมื่อเตรียม User Story อย่าลืม เหตุผลในการปรับเปลี่ยนฟังก์ชันการทำงานของผลิตภัณฑ์

ปัญหาเกี่ยวกับ 3C

เราสามารถแบ่งขั้นตอนการทำงานกับ User Stories ออกเป็นสามขั้นตอนที่เรียกว่า 3Cs:

• การ์ด – การ์ดที่บันทึกเรื่องราวของผู้ใช้
• การสนทนา – การสนทนาภายในทีม Scrum เกี่ยวกับการ์ดเรื่องราวของผู้ใช้
• การยืนยัน – กำหนดเกณฑ์การยอมรับเพื่อยืนยันว่างานเสร็จสมบูรณ์

ข้อผิดพลาดอาจเกิดขึ้นกับสิ่งเหล่านี้ ซึ่งเราอธิบายไว้ด้านล่าง

การ์ด

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

เนื่องจากปัญหาของการ์ด User Story มีสองมิติ วิธีหนึ่งคือการกำหนดสูตร: กระชับและมีการแจงนับขั้นต่ำที่จำเป็น ประการที่สองคือ ขนาดจริงของ User Story ประโยคทั่วไปหนึ่งประโยคสามารถแสดงงานจำนวนมากที่ไม่สามารถทำได้ใน Sprint เดียว

การสนทนา

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

การยืนยัน

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

User Story ที่เขียนมาอย่างดีประกอบด้วยคำอธิบายของสถานการณ์ที่มีการใช้งาน การทดสอบคือผู้ใช้ใช้ประโยชน์จากฟังก์ชันใหม่ที่สร้างโดยทีมพัฒนา

เครื่องมือที่มีประโยชน์สำหรับการตรวจสอบ User Story คือการ พัฒนาการทดสอบการยอมรับ ซึ่งมักจะอยู่อีกด้านหนึ่งของการ์ดที่มี User Story

ความผิดพลาดของ User Story – Summary

เมื่อเตรียมและใช้งาน User Stories ควรปฏิบัติตามกฎต่อไปนี้:

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

หากคุณชอบเนื้อหาของเรา เข้าร่วมชุมชนผึ้งที่วุ่นวายบน Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest

คู่มือการต่อสู้:

1. อภิธานศัพท์ของคำศัพท์พื้นฐาน บทบาท และแนวคิด
2. Scrum คืออะไร?
3. ค่าการต่อสู้
4. วิธีใช้งาน Scrum ในบริษัทของคุณ
5. Scrum Team - มันคืออะไรและทำงานอย่างไร?
6. เจ้าของผลิตภัณฑ์คือใคร?
7. ข้อผิดพลาดที่พบบ่อยที่สุดของ Product Owner
8. Scrum Master คือใคร?
9. ลักษณะของ Scrum Master ที่ดี
10. ข้อผิดพลาดที่พบบ่อยที่สุดของ Scrum Master
11. สถิติและตัวชี้วัดใดที่ Scrum Master ควรติดตาม
12. ความร่วมมือระหว่าง Product Owner และ Scrum Master
13. ทีมพัฒนาใน Scrum
14. ข้อผิดพลาดที่พบบ่อยที่สุดของ Developers
15. สิ่งประดิษฐ์การต่อสู้
16. สเกลการต่อสู้
17. Sprint Backlog
18. Backlog สินค้าคืออะไร?
19. เรื่องราวของผู้ใช้คืออะไร?
20. สร้าง User Story ที่ดีที่สุดกับ INVEST
21. ข้อผิดพลาด User Story ที่พบบ่อยที่สุด
22. เกณฑ์การยอมรับเรื่องราวของผู้ใช้
23. การประมาณค่าและจุดเรื่องราวใน Scrum
24. การวางแผนโป๊กเกอร์
25. เกมประเมินทีม
26. กำหนดส่วนเพิ่ม
27. เหตุการณ์การต่อสู้
28. Sprint ใน Scrum คืออะไร?
29. ความมุ่งมั่นของทีม Scrum - เป้าหมายผลิตภัณฑ์ เป้าหมาย Sprint และคำจำกัดความของความสำเร็จ
30. แผนภูมิ Burndown คืออะไร?
31. จะสร้างและตีความแผนภูมิเบิร์นดาวน์ได้อย่างไร?
32. ข้อดีและข้อเสียของแผนภูมิการเบิร์นดาวน์
33. กระดาน Kanban ใน Scrum และ Scruban
34. Velocity in Scrum - ความเร็วของทีมพัฒนา
35. การต่อสู้รายวัน
36. การวางแผนการวิ่ง
37. Sprint Review
38. Sprint Retrospective คืออะไร?
39. ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective
40. บำรุง Backlog สินค้า