User Story

Why this matters

ทีมพัฒนาสมัยใหม่ส่วนใหญ่ทำงานกันด้วย user story — มันคือหน่วยความต้องการขนาดพอดีคำ ที่ผูก “ทำอะไร” เข้ากับ “ทำไปทำไม” เสมอ

รูปแบบพื้นฐาน

As a [user]
I want [goal]
So that [value]

Example from Automotive QA

As a QA Support user,
I want to search previous complaints using a defect description,
so that I can quickly find similar historical cases.

สามบรรทัดนี้ตอบครบ: ใคร (QA Support), อยากทำอะไร (ค้น complaint เก่าด้วยคำอธิบาย defect), เพื่ออะไร (เจอเคสคล้ายกันเร็วขึ้น)

จุดที่คนพลาดบ่อย

• เขียน solution แทน goal — “I want a dropdown with defect types” เป็นการออกแบบหน้าจอ ไม่ใช่ความต้องการ ให้เขียนว่าอยากทำอะไรสำเร็จ แล้วปล่อยให้ทีมออกแบบวิธี
• So that ที่ไม่มีความหมาย — “so that I can search” เป็นการวนคำ ถ้าเขียน value จริงไม่ได้ แปลว่ายังไม่เข้าใจว่า story นี้มีไปทำไม
• ตัวละครกว้างเกินไป — “As a user” เฉย ๆ บอกอะไรไม่ได้ ระบุ role ให้ชัด: QA Support, QA Engineer, Manager

What a BA needs to know

User story ไม่ใช่เอกสารสมบูรณ์ในตัวมันเอง — มันคือ ตั๋วสำหรับเปิดบทสนทนา กับทีมพัฒนา รายละเอียดที่ตรวจรับได้จะตามมาในรูป acceptance criteria ซึ่งเป็นเนื้อหาของบทถัดไป