[Review] Fifty Quick Ideas to Improve your User Stories
พอดีในทีมพยายามที่จะเน้นเขียน Story ให้มันเป็น User Story กันมากขึ้น จากเดิมที่แค่รู้ว่าต้องทำอะไร แต่ไม่รู้ว่าต้องทำเพื่อใคร และ ทำไปทำไม ทำให้การตัดสินใจ หรือการหา Solution เป็นไปอย่างคลุมเคลือ ส่งผลให้เกิด Over Engineering ได้ง่ายอีกด้วย ซึ่งพอดีก่อนหน้านี้ซื้อชุด Bundle Fifty Quick Ideas { Test, User Stories, Retro spectives} ไว้ ก็เลยไปลองหยิบขึ้นมาอ่าน เพิ่งอ่านจบเลยลองเอามาเขียนรีวิวทิ้งไว้
ผู้เขียนบอกว่าเล่มนี้ ไม่ได้มาสอนหลักการหรือปูพื้นฐานของของ User Stories ควรไปอ่านจากเล่มอื่นๆพวก User Stories Applied, User Story Mapping ที่เค้าเขียนไว้แล้วจะดีกว่า (ซึ่งเอาจริงๆ ก็ไม่ได้อ่าน เน้นเคยฟัง เคยอ่านตามบล๊อกเอา) โดยเล่มนี้จะเน้นไป Tips หรือวิธีจากที่จะช่วย Improve ให้การเขียน User Story ให้ดีขึ้น มีอธิบายพื้นฐานของ User Story บ้างเล็กน้อยแต่ก็ไม่ได้ลงรายละเอียดเท่าไรนัก ซึ่งแต่ละ Idea เค้าจะเริ่มจาก Intro แล้วพูดถึง Key benefits และ How to make it work
โดยในหนังสือ เค้าพยายามออกเป็นกลุ่มๆ ทั้งนี้
- Creating Stories
- Planning with stories
- Discussing stories
- Splitting stories
- Managing Iterative Delivery
ได้เลือกหยิบแต่ละ Idea เด่นๆที่พอจะจำได้มาเล่าให้ฟัง
Tell stories, don’t write them
เรามักชอบพูดกันว่าเขียน Story Card พอพูดกันว่าเขียนแล้วมันมักจะเป็นหน้าที่ของคนใดคนนึงมากกว่า แต่ความจริง Story ควรเกิดขึ้นจากการพูดคุย และ discuss ซึ่งกันและกัน เพื่อให้เกิดความเข้าใจร่วมกันของทั้งทีม (Shared Understand) ตัว card มีหน้าที่เป็นเพียงแค่หลักฐานให้การตกลงร่วมกัน หรือ แค่ช่วยเตือนความจำได้เท่านั้น
Use low-tech for story conversations
เพื่อทีมเกิดการพูดคุยกันมากขึ้น ควรหลีกเลี่ยงการใช้คอมพิวเตอร์ หรือ Projector หรือแม้กระทั่งมือถือ ซึ่งจะทำให้ทีมสนใจสิ่งอื่นมากกว่า ที่จะ discuss story กัน
Watch out for generic roles, Narrow down the customer segment
เค้าบอกว่าข้อดีที่สุดของการเขียน Uses Story คือ การที่ทีมพยายามมองจากมุมมองของ User แทนที่จะมองในเขียนของ Technical เป็นหลัก แต่การพูดถึง User โดยที่ไม่เจาะจงหน้าที่ หรือ รูปแบบการใช้งาน มักนำมาซึ่งความซับซ้อนที่ไม่จำเป็น หรือ เกิดการ Over Enginnering ได้ง่าย เพื่อโน้น เพื่อนี้ไปซะหมด Story ก็จะบวมๆ และมี Impact น้อย
Put a ‘best before’ date on stories
บาง Stroy ไม่ด่วน และมักถูกเขียนทิ้งไว้ แล้วนำไปเก็บลืมไว้ใน Backlog
รู้ตัวอีกทีว่าต้องใช้งาน ก็สายไปซะแล้ว ลงวันที่ของการ์ดก็ช่วยให้ สามารถ Track และพิจารณาได้ว่า Stroy ไหนเก่าไปควรจะทิ้ง หรือ Stroy ไหนใกล้จะต้องใช้ ได้หยิบเข้ามาใน Sprint ได้ทัน
Imagine the demonstration
บางครั้งเขียน Stroy ไม่ออก หรือ ไม่รู้จะเขียน Acceptance Criteria (A/C) ของการ์ดนั้นยังไง ในเริ่มจินตนการว่าตอนจบ Sprint ในช่วง demo เราจะสามารถสาธิตการใช้งาน หรือ ผลลัพธ์ของ Story นั้นได้ยังไงบ้าง ก็จะช่วยให้เราสามารถมองเห็น Stroy ได้ชัดเจนยิ่งขึ้น
Involve all roles in the discussion, Split business and technical discussions
ทุกตำแหน่ง แต่ไม่จำเป็นต้องทุกคน ควรมีส่วนอื่นๆ ให้การเขียน Story และ Discuss ซึ่งกันและกัน การที่ทุกตำแหน่งมีส่วนร่วม จะได้ช่วยเปิดมองมุม หรือ มองเห็นผลกระทบที่จะเกิดขึ้นได้ตั้งแต่แรกเริ่ม
และไม่ควรที่จะ discss ทั้งเรื่อง business และ technical พร้อมๆ กัน การที่ discuss เรื่อง business ก็จะทำให้ Technical Team เบื่อ รู้สึกเสียเวลา และไม่อยากมีส่วนร่วม และเรื่อง technical เอง ก็เช่นเดียวกัน Bussiness Team ก็จะเบื่อ และเสียเวลา ควรมุงไปที่ user เป็นหลักก่อน หากจำเป็นต้อง discuss กันจริงจิง ให้แยกไปเฉพาะคนที่เกี่ยวข้องให้เรียบร้อยก่อน แล้วค่อยมาเขียน Stroy กันใหม่อีกครั้ง
Start with dummy, then move to dynamic, Pick impacts instead of prioritising stories
Story นึงไม่ควรจะใหญ่จนเกินไป แต่ควรที่จะสร้าง Impact ให้ได้ อาจจะยังใช้งานยาก หรือ มีข้อจำกัดเยอะแยะ แต่หากสร้าง Impact ให้กับ User ได้ก่อน ก็ดีกว่าที่ User จะไม่ได้อะไรเลย อีกทั้งยังช่วยให้ทีมเข้าใน Problem Domain ได้ชัดเจนยิ่งขั้น ได้ validate idea, ได้ feedback จาก user ได้รวดเร็วยิ่งขึ้น แล้วจึงค่อยๆ เพิ่ม Story เพื่อปรับปรุงให้สิ่งๆ นั้นดีขึ้น ใช้งานได้งานยิ่งขึ้นต่อไป
และการเรียงความสำคัญของ Story Card ของเรียงจาก Impact มากกว่า ความง่าย/ยาก หรือตาม …. เพื่อให้ทีมรู้สึกว่างานที่ทำมีคุณค่า สามารถนำไปใช้ได้จริง ไม่ได้ไว้บนหิ้ง
Never say ‘no’ — say ‘not now’
ทีม / PO ที่ดี ไม่ควรที่จะพูดว่า “ใช่” ไปกับซะทุกเรื่อง บางครั้งอาจจะมีบาง Stroy หรือบางอย่างที่ไม่เห็นด้วย หรือไม่เหมาะสมกับเวลาในช่วงนั้นๆ ก็ควรที่จะแสดงความคิดเห็นออกมา แต่แทนที่จะพูดว่า “ไม่” ให้พูดว่า “ไม่ใช่ตอนนี้” แทนเพื่อให้ฟังดูซอฟยิ่งขึ้น ซึ่งบางครั้งก็ช่วยให้ PO/Stakeholder ได้มีเวลาเพื่อไปขัดเกา Story ให้ชัดเจน และดูมี Impact ยิ่งขึ้น แทนที่จะดรอป Story นั้นทิ้งไปเฉยๆ เลย
สรุป เล่มนี้เค้าพูดถึงวิธีการทำให้ User Stroy ให้ดีขึ้น ไม่ใช่เพียงแค่การเขียน Stroy ให้ดีเพียงอย่างเดียว พูดถึงเรื่องของทีม การให้ทีมมีส่วนร่วมมากขึ้น pitfall ต่างๆ ที่อาจจะเกิดขึ้นได้ อีกทั้งเค้าไม่ได้บอกแค่เพียง Idea แต่เค้าเล่าถึงวิธีการที่เค้านำ Idea เหล่านั้นไปใช้กับทีมที่ผู้เขียน Consult ให้ ซึ่งช่วยให้เห็นภาพได้ดียิ่งขึ้น
