User Story และ Definition of Done

เรากำลังทำอะไร ? เพื่อใคร ? แล้วทำไปทำไม ?

น่าจะเป็นความโชคดีของผม ที่เริ่มทำงานในบริษัท Start Up ขนาดไม่ใหญ่มาก และทีมที่ทำงานก็มี Mindset แบบคนรุ่นใหม่จ๋ากันเลยทีเดียว ผมเข้าทำงานครั้งแรกในตำแหน่งของ UI Designer

เนื่องจากทีมมีขนาดเล็ก ทำให้ทีม Tech และ C Level ทำงานกันใกล้ชิดมาก และทุกครั้งที่เราอยากได้ Feature อะไรนั้น เราจะคุยกันเหมือนกับการเล่าเรื่อง จึงทำให้ทุกคนในบริษัทมองเห็นภาพเดียวกันว่าเรากำลังทำอะไรอยู่ และทำไปเพื่ออะไร

เวลาผ่านไป บริษัทก็เติบโตขึ้นทีม Tech ขยายขึ้น มีทีมจากฝั่ง ฺBusiness มาเสริม ก็เหมือนจะโอเค ทีมโตขึ้น…แต่สิ่งที่เกิดขึ้นคือ Deliver Time ที่เราตั้งกันไว้ มัน Delay ออกไปมากกว่า 50% ทั้ง ๆ ที่มันควรจะเสร็จเร็วขึ้นสิ

หลังจากปิดงานพวกเรามานั่งจับเข่าคุยกันว่ามันเกิดอะไรขึ้น พอคุยกันเสร็จผมจับประเด็นหลัก ๆ ได้ดังนี้

• ทีมตอบได้ว่าทำอะไร แต่ไม่รู้คุณค่าที่แท้จริงของสิ่งที่ทำขึ้นมา
• ทีมไม่รู้ว่างานต้องจบลงที่ตรงไหน แบบไหนที่เรียกว่าเสร็จ

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

เริ่มต้นสร้างเรื่องราว

ย้อนกลับไปสมัยก่อนที่ทีมยังเล็ก ๆ พวกเรามักจะพูด Feature ออกมาในลักษณะของการเล่าเรื่อง จะเรียกว่า User Story ก็ได้ การเล่าเรื่องจะประกอบไปด้วยหลัก ๆ คือ

• ใคร (User)
• อยากทำอะไร (Goal)
• เพื่ออะไร (Value)

ผมจะเขียนเป็น Template เพื่อให้เห็นภาพที่ชัดเจนขึ้น

ในฐานะ…(ผู้ใช้)…ฉันต้องการที่จะ…(เป้าหมาย)…เพื่อ…(คุณค่า)…

ลักษณะของ Story ที่ดีนั้นจะต้องมีความชัดเจน ไม่ใหญ่เกินไป หากใหญ่เกินไปเราจะตอบไม่ได้ว่าคุณค่าที่แท้จริงของมันคืออะไร และสาเหตุที่ทำให้เกิด Pain Point คืออะไร

“ในฐานะผู้ขาย ฉันอยากออกใบแจ้งหนี้ได้สะดวกขึ้น เพื่อประหยัดเวลาในการออกใบแจ้งหนี้”

คำว่า “สะดวกขึ้น” มันกว้างเกินไป มันมีหลายวิธีที่จะออกใบแจ้งหนี้ได้สะดวกขึ้น แต่หากคนอื่นมาอ่านก็จะตีความไม่ถูก หรือตีความออกมาได้ไม่ตรงกันว่าสะดวกคือแบบไหน Story ลักษณะนี้เราจะเรียกมันว่า Epic ซึ่งลักษณะของมันคือสามารถแตกย่อยออกมาเป็น Story เล็ก ๆ ได้อีก ถ้าจะย่อย “ออกใบแจ้งหนี้ได้สะดวก” ออกมาเป็น Story ก็คงจะได้ประมาณนี้

“ในฐานะผู้ขาย ฉันต้องการออกใบแจ้งหนี้โดยเลขที่ไม่ซำ้กัน เพื่อนำใบแจ้งหนี้เหล่านั้นไปบันทึกลงบัญชีได้อย่างถูกต้อง”

จาก Story ดังกล่าวเราใช้คำว่า “ออกใบแจ้งหนี้โดยเลขที่ไม่ซำ้กัน” เพื่อให้ทีมเห็นภาพที่ชัดเจนมากยิ่งขึ้นของคำว่า “สะดวก” และเห็น Pain Point ที่ชัดเจนของผู้ขายที่เกิดขึ้นจากการออกเลขที่ใบแจ้งหนี้ซ้ำ ทีมจะรู้ทันทีว่าเราต้องทำอะไร ให้ใครใช้ เพื่อแก้ปัญหาอะไร ต่อไปก็คงเป็นหน้าที่ของ Designer แล้วว่าจะแก้ปัญหาการออกใบแจ้งหนี้ซ้ำอย่างไร

ใครเป็นคนเขียน Story

ถ้าเป็นในบริษัทผม ก็คงจะเป็นตำแหน่ง Product Owner ที่เป็นคนเขียน Story ขึ้นมา แต่ถ้าเป็นไปได้ ผมคิดว่าทุกคนในทีมควรที่จะเขียน Story ให้เป็น การเขียน Story นั้นมันเหมือนกับคอยย้ำถามตัวเราเองว่า ไอ้ Feature ที่กำลังจะทำเนี่ย มันดีจริง ๆ ไหม มันมีคุณค่ามากน้อยแค่ไหน ไม่งั้นเราจะรู้สึกฝืน ๆ เวลาเขียนในส่วนของ “เพื่ออะไร” ดังนั้นการเขียน Feature ออกมาในแบบของ Story จะช่วยให้คนในทีมเห็นคุณค่าของแต่ละ Feature ได้ชัดเจนยิ่งขึ้น

นิยามของคำว่าเสร็จ (Definition of Done)

หลังจากเขียน Story เสร็จ ผมรู้สึกว่าสิ่งนึงที่ยังขาดไปคือ Feature นี้เสร็จแล้วจะมีลักษณะการทำงานของมันจะเป็นอย่างไร ซึ่งมักจะเป็นคำถามที่เกิดจากฝั่ง Business และ C Level ที่เค้าคาดหวังไว้ว่ามันจะเป็นแบบนั้น แบบนี้ ซึ่งตรงนี้ Story อย่างเดียวจะตอบไม่ได้ ผมขอยกตัวอย่างด้านบนแล้วกัน

“ในฐานะผู้ขาย ฉันต้องการออกใบแจ้งหนี้โดยเลขที่ไม่ซำ้กัน เพื่อนำใบแจ้งหนี้เหล่านั้นไปบันทึกลงบัญชีได้อย่างถูกต้อง”

ทีมเลือก Solution ในการแก้ปัญหานี้ด้วยการให้ระบบออกเลขที่ใบแจ้งหนี้อัตโนมัติ ถ้าหากเราพูดแค่นี้ ทุกคนก็จะมีภาพการทำงานของ Feature นี้ต่างกัน โดยเฉพาะกับทีมที่ไม่ได้ใช้เวลาอยู่กับฝั่งพัฒนามากนัก ดังนั้นการกำหนด Definition of Done ให้กับ Story จะเป็นตัวช่วยที่ทำให้ทุกคนมองเห็นการทำงานของ Feature นี้เหมือนกัน ไม่มากไม่น้อยไปกว่านี้ จากตัวอย่าง Story ข้างบนเราอาจจะเขียนเป็นข้อ ๆ ได้ เช่น

• ระบบจะต้องรันเลขที่ใบแจ้งหนี้ได้
• สามารถตั้งค่า และแก้ไขเลขที่การรันใบแจ้งหนี้ซึ่งประกอบไปด้วยตัวอักษร และตัวเลขได้
• แจ้งเตือนหากมีการออกเลขที่ใบแจ้งหนี้ซ้ำได้

ซึ่งเราควรกำหนดกันตั้งแต่ช่วงที่ได้ Solution ที่จะใช้กับ Story นั้น ๆ ยิ่งมี C Level เป็นคนช่วยกำหนด Definition of Done ได้จะยิ่งดีมาก แต่ต้องระวังเรื่อง Over Expectation จนทำให้ Feature นั้นใหญ่เกิน Story การกำหนดอาจจะทำทั้งทีม หรือเอาแค่เฉพาะบางคนที่มีอำนาจในการตัดสินใจก็ได้ขึ้นอยู่กับขนาดของบริษัท

ในตอน Deliver งานหากมีบางจุดเพิ่มเติมที่อยากทำกับ Feature นั้น ๆ และไม่ได้อยู่ในรายการของ Definition of Done ก็ให้ใส่ลงไปใน Backlog และติด Tag ให้เป็นในลักษณะของการ Enhancement ให้หมด อย่าพยายามยัดเข้ามาเพิ่มเติมเพราะสุดท้ายมันจะบวมขึ้นเรื่อย ๆ และหาจุดสิ้นสุดของการ Deliver ไม่ได้สักที

การทำ Story และ Definition of Done จะช่วยทำให้คนในทีมไม่ว่าจะเป็น Designer หรือ Engineer มองเห็นคุณค่าในสิ่งที่ตัวเองกำลังทำ รู้ว่าทำลงไปเพื่อแก้ปัญหาอะไร และการมีส่วนร่วมในการเขียน Definition of Done จะทำให้ทีมมีความเป็น Ownership เพิ่มขึ้น เพราะทีมจะมองในเรื่องของ Ability และ Quality ของ Feature ที่กำลังจะ Deliver ออกไป ผมเชื่อว่าลึก ๆ แล้วเราทุกคนอยากทำของออกมาให้ดีที่สุด เพียงแต่เรายังไม่รู้คุณค่าที่แท้จริงของสิ่งที่ตัวเองกำลังทำอยู่ ถ้าเรามองเห็นจริง ๆ ว่ากำลังแก้ปัญหาอะไรอยู่ และทำไปเพื่ออะไร เราก็พร้อมที่จะทำมันออกมาให้ดีที่สุด ไม่ใช่เพียงเพราะแค่ให้มันมี ให้มันผ่าน ๆ ไป