Scrum Guide | 22. เกณฑ์การยอมรับเรื่องราวของผู้ใช้

เผยแพร่แล้ว: 2022-05-25

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

เกณฑ์การยอมรับเรื่องราวของผู้ใช้ – สารบัญ:

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

บทนำ

เราได้กล่าวถึงเรื่องราวของผู้ใช้และประเด็นต่างๆ ที่ต้องจัดการเมื่อสร้างมันขึ้นมาในบทความก่อนหน้านี้ อย่างไรก็ตาม วันนี้เราจะเน้นที่เกณฑ์การยอมรับเรื่องราวของผู้ใช้

เกณฑ์การยอมรับควรเป็นไปตามหลักเกณฑ์เหล่านี้:

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

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

จะกำหนดเกณฑ์การยอมรับเรื่องราวของผู้ใช้ได้อย่างไร

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

ความชัดเจนและการเข้าถึงเกณฑ์การยอมรับ

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

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

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

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

การทดสอบการยอมรับ

หากคุณตัดสินใจที่จะพัฒนาการทดสอบการยอมรับ วางมันลงบนอีกด้านหนึ่งของการ์ดที่มี User Story ต่อมาทีม Scrum หรือทีม QA ภายนอกก็สามารถดำเนินการได้

การทดสอบต้องมี ข้อความชัดเจน ว่าผลิตภัณฑ์ไม่ผ่านหรือผ่านการทดสอบก่อน ไม่สามารถมีข้อความแสดงเปอร์เซ็นต์หรือการประเมินขั้นกลางได้

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

เกณฑ์การยอมรับเรื่องราวของผู้ใช้เทียบกับคำจำกัดความของเสร็จสิ้น

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

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

ตัวอย่างเช่น ใช้ User Story นี้กับเนื้อหา:

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

คำจำกัดความของความสมบูรณ์สำหรับเรื่องราวของผู้ใช้ข้างต้นอาจรวมถึงสิ่งต่อไปนี้:

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

ในทางกลับกัน คุณสมบัติเกณฑ์การยอมรับของลูกค้า:

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

สรุป

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

เกณฑ์การยอมรับที่มีการกำหนดอย่างดี เช่น ในรูปแบบของการทดสอบการยอมรับ ยังช่วยให้เรา ตรวจสอบระหว่าง Sprint ว่าฟังก์ชันที่สร้างขึ้นนั้นช่วยปรับปรุงการตอบสนองความต้องการของลูกค้าได้หรือไม่

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

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

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

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

อภิธานศัพท์ของคำศัพท์พื้นฐาน บทบาท และแนวคิด
Scrum คืออะไร?
ค่าการต่อสู้
วิธีใช้งาน Scrum ในบริษัทของคุณ
Scrum Team - มันคืออะไรและทำงานอย่างไร?
เจ้าของผลิตภัณฑ์คือใคร?
ข้อผิดพลาดที่พบบ่อยที่สุดของ Product Owner
Scrum Master คือใคร?
ลักษณะของ Scrum Master ที่ดี
ข้อผิดพลาดที่พบบ่อยที่สุดของ Scrum Master
สถิติและตัวชี้วัดใดที่ Scrum Master ควรติดตาม
ความร่วมมือระหว่าง Product Owner และ Scrum Master
ทีมพัฒนาใน Scrum
ข้อผิดพลาดที่พบบ่อยที่สุดของ Developers
สิ่งประดิษฐ์การต่อสู้
สเกลการต่อสู้
Sprint Backlog
Backlog สินค้าคืออะไร?
เรื่องราวของผู้ใช้คืออะไร?
สร้าง User Story ที่ดีที่สุดกับ INVEST
ข้อผิดพลาด User Story ที่พบบ่อยที่สุด
เกณฑ์การยอมรับเรื่องราวของผู้ใช้
การประมาณค่าและจุดเรื่องราวใน Scrum
การวางแผนโป๊กเกอร์
เกมประเมินทีม
กำหนดส่วนเพิ่ม
เหตุการณ์การต่อสู้
Sprint ใน Scrum คืออะไร?
ความมุ่งมั่นของทีม Scrum - เป้าหมายผลิตภัณฑ์ เป้าหมาย Sprint และคำจำกัดความของความสำเร็จ
แผนภูมิ Burndown คืออะไร?
จะสร้างและตีความแผนภูมิเบิร์นดาวน์ได้อย่างไร?
ข้อดีและข้อเสียของแผนภูมิการเบิร์นดาวน์
กระดาน Kanban ใน Scrum และ Scruban
Velocity in Scrum - ความเร็วของทีมพัฒนา
การต่อสู้รายวัน
การวางแผนการวิ่ง
Sprint Review
Sprint Retrospective คืออะไร?
ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective
บำรุง Backlog สินค้า