เขียน User Story ยังไงให้ถูกใจ Dev Team
User Story หรือ Product Backlog ที่เป็น Artifact (ทรัพย์สิน) ของ Product และเป็นสิ่งที่จะกำหนดว่า product มีคุณสมบัติหรือทำงานอย่างไรเพื่อให้ตรงใจคุณลูกค้าหรือที่เราเรียกว่า User นั่นเอง แต่บ่อยครั้งที่เราสร้าง User story ไม่ถูกใจและไม่คลอบคลุมหรือไม่ตรงใจ Development Team สักที เรามาดูหลักการง่ายๆ ในการเขียนเพื่อให้ Development ประทับใจกันคะ
- เขียนเป้าหมายให้ชัดเจนว่าทำเพื่ออะไร (User statement)
As a <ระบุผู้ใช้>, I want <ต้องการอะไร> so that <เพื่ออะไร>
เช่น ในฐานะ user ฉันต้องการให้มี Login by social เพื่อที่จะฉันจะสามารถ login ด้วย Account social ที่ฉันมีอยู่ได้
ส่วนนี้เป็นส่วนที่จะระบุว่า User นี้ต้องการอะไรกันแน่ และต้องการเห็นอะไรเมื่อทีมส่งงานหลังจบ sprint แต่ไม่จำเป็นต้องใช้รูปแบบที่กล่าวมาตอนต้นนะคะ PO หรือคนที่สร้าง User story สามารถใช้รูปแบบที่ถนัดได้ แต่เน้นว่าทีมต้องเข้าใจในสิ่งที่เขียนเท่านั้นเอง - ระบุรายละเอียดให้ชัดเจน (Acceptance criteria)
หน้าที่ระบุ Acceptance criteria ให้ชัดเจนยังเป็นหน้าที่ของ Product owner หรือผู้ที่สร้าง User story ที่ต้องระบุตัววัดอย่างชัดเจนเพื่อให้ทีมสามารถสร้างงานและทำการเทสต์งานได้ตรงกับสิ่งที่ลูกค้าต้องการ รวมถึงสามารถ estimate time ที่จะทำให้ story นี้สำเร็จได้ เช่น
> เมื่อเข้ามาหน้า Login ต้องแสดง logo Facebook และ Google ใต้ช่องที่ใส่ password ของ login ปกติ
> เมื่อนำเมาส์ไปชี้บน logo อันใดอันนึง จะต้องแสดงข้อความ Log in by Facebook และตัวlogo เปลี่ยนเป็นสีน้ำเงินเข้ม แต่เมื่อนำเมาส์ออกปุ่ม logo เปลี่ยนเป็นสีเดิม - แนบ UX/UI เพื่อความชัดเจน
ถ้า Story ที่สร้างขึ้นมาเกี่ยวข้องกับ UX/UI หรือ User flow ควรแนบสิ่งเหล่านี้มาใน Story เพื่อให้ทีมมีความเข้าใจและ Estimate งานได้ถูกต้องด้วย และที่สำคัญสิ่งนี้เป็นตัวที่ช่วยให้ทีมมองเห็นภาพว่า Story นี้มีขนาดใหญ่จนเกินกว่าจะทำได้ภายใน Sprint หรือเปล่าอีกด้วย - ใช้หลัก Product Dimension Framework
เมื่อเขียน story ออกมาแล้วให้ลอง review ดู User story ที่เขียนขึ้นมาอีกครั้งว่าตรงหลัก Product dimension ไหม
> User: เราระบุ user ที่เกี่ยวข้องกับ Story หมดหรือยัง ถ้ายังต้องระบุด้วยจ๊ะเพราะทีมอาจต้องการข้อมูลนี้ด้วย
> Interface: Story นี้มีมีความเกี่ยวข้องกับข้อมูลภายนอกระบบหรือเปล่า ถ้า PO ไม่สามารถระบุเรื่องนีได้ ไม่ต้องกลัวคะ แนะนำให้สอบถาม Developer ได้ เพราะเราคือทีมเดียวกัน
> Action: User มี action หรือวิถีทางในการใช้ feature ใน storyอย่างไรบ้าง PO ควรระบุเป็น use cases scenarioให้ชัดเจน
> Data: ข้อมูลอะไรที่ต้องใช้เพิ่มเติมในการสนับสนุน action ของ User
> Control: มีอะไรที่เป็นตัวแปรที่ทำให้ User ไม่สามารถใช้ feature ได้บ้าง เช่น Firewall , Network configuration
> Environment: Platforms (Hardware, software) อะไรบ้างที่ทีมต้องสร้างให้ Support productนี้
> Quality Attribute: ความคาดหวังของลูกค้าต่อเวลาในการตอบกลับ และตัววัดคุณภาพของ Product - ใช้หลัก INVEST
> Independent — แต่ละ Story ต้องเป็นอิสระจากกันและกัน
> Negotiable — แต่ละ Story สามารถเจรจาต่อรองกันได้ (ระหว่างทีมและผู้ใช้)
> Value — แต่ละ Story ต้องมีคุณค่าต่อผู้ใช้
> Estimable — แต่ละ Storyต้องสามารถประเมินขนาดได้ด้วย Development Team
> Small — แต่ละ Story ต้องมีขนาดเล็กและจบได้ภายใน Sprint (ถ้าใหญ่ไปจง slice ให้เล็ก)
> Testable — แต่ละ Story ต้องสามารถทดสอบได้
ข้อมูลเพิ่มเติมสำหรับการสร้าง Product backlogs หรือว่า User story
> User Story ต้องมี Value กับลูกค้า ถ้าไม่มี Value กับลูกค้าไม่ใช่ Story
> ถ้า Story เกี่ยวกับ Technical ให้สร้างเป็น Technical story แล้วอธิบายที่ story นั่น
> Defect ถือว่าเป็น Product Backlog ด้วยเช่นกัน
> ถ้าพบว่ามีบางส่วนที่ต้องการพัฒนาใน product (Improvement) ก็สามารถนำมาสร้างเป็น Product backlog ได้เช่นกัน
สุดท้ายนี้การเขียน User Story เป็นเรื่องของเทคนิคของแต่ละคน การเขียนบทความนี้ขึ้นมาไม่ได้หมายความว่าทุกคนต้องยึดปฏิบัติตามนี้ แต่ผู้เขียนหวังว่าบทความนี้จะทำให้หลายคนเห็นภาพการเขียน User story ที่ชัดเจนมากขึ้นและถูกใจ Development Team ที่รักทุกคนคะ
Reference:
1. https://medium.com/@anca_51481/how-to-write-user-stories-that-deliver-value-to-the-customer-47c8d2241a30
2. https://blog.maqe.com/how-to-write-a-good-user-stories-686f936a5149
3. https://medium.com/@lmueller_mobile/how-to-write-a-great-user-story-b10ac8820384
4. https://tanjai.me/user-story-ac199d775bd3
