ในการทำงานแต่ละรอบการทำงานนั้น เราจำเป็นต้องหา efforts ของทีม เพื่อให้เราสามารถรู้ได้ว่าแต่ละทีมสามารถรับงาน ได้เท่าไหร่

หลายๆ คนอาจจะเคยเจอวิธีการคำนวนแบบ Story Points ซึ่งเป็นวิธีการหา Velocity ของทีม ซึ่งวิธีนี้เหมาะกับทีมที่มีการเก็บข้อมูล Velocity ได้ก่อนแล้ว และทีมไม่มีการเปลี่ยนแปลงคนในทีมบ่อยๆ เนื่องจาก Story points เกิดจากงานเก่าที่ทำมา ยิ่งทำมาเยอะ มีข้อมูลเยอะ จะทำให้การ estimate story points ได้แม่นยำขึ้น

แต่ถ้าหากมีการเปลี่ยนสมาชิกในทีม หรือ ทีมไปทำงานที่ยังไม่เคยทำ ความแม่นยำของการ estimant ตัว story points ที่จะได้ ก็จะลดลง

ข้อเสีย อีกหนึ่งอย่าง คือ มันไม่สามารถบอกเป็นเวลาได้ และส่วนใหญ่ stakeholder อยากรู้ตัวเลขที่เป็นเวลามากกว่า มันเลยเกิดท่าประหลาดๆ ขึ้น เช่น 1 story point = 1 hour ซึ่งถ้าเป็นแบบนี้ แนะนำให้ใช้เวลาไปเลยดีกว่า

เอาจริงๆ story points ไม่เหมาะกับการนำมา estimate งานแต่ละรอบ มันเหมาะกับการนำมาใช้ในการ estimate project แบบกว้างๆ มากกว่า

บทความนี้ ผมแนะนำวิธีการหา Team Effort หรือ Team Capacity ที่ผมใช้งานอยู่ ซึ่งวิธีนี้มันจะสะท้อนเวลาทำงาน (coding + testing) จริงๆ ของทุกคนในทีมมากกว่า

ต่อไปจะเป็นวิธีการคำนวนหา Effort ของ Team กัน

1. หาจำนวนชั่วโมงการทำงาน

เริ่มต้นที่เรามาหาเวลาทำงานกันก่อนเลย โดยปกติแล้วแต่ละบริษัทจะกำหนดเวลาทำงานอยู่ที่ 8h ต่อวัน

แต่เวลาทำงานจริงๆ นั่นมันไม่ถึงหรอก ลองนึกดูว่า จะมีสักกี่คนที่นั่งทำงานตลอดเวลา ไม่เข้าห้องน้ำ ไม่ชงกาแฟ ไม่พักสายตา แทบเป็นไปไม่ได้เลย

ดังนั้น จริงๆ แล้ว เวลาทำงานจริงๆ ไม่ถึง 70% ของแต่ละวัน หรือ ตีไปประมาณ 4-5 ชม.ต่อวัน

อย่างบริษัทที่ผมทำงานอยู่ทำงานวันละ 7h/day ถ้าเราคิดว่า พนักงานทำงานอยู่ที่ 70% ต่อวัน ก็จะมีเวลาทำงานจริงๆ 5h/day (ซึ่งจริงๆ อาจจะเป็นแค่ 4h/day ด้วยซ้ำไป แต่ผมขอเอาตัวเลขที่เยอะเป็นตัวตั้งไว้ก่อน ถ้าผลลัพธ์ยังไม่ใช่ ก็ค่อยปรับ เพิ่มหรือลดลงได้)

ตัวอย่าง

  • Availability = ~70% = 5h/day
  • Working Day = 10 day / sprint
  • Working Hour = 7h/day

Calculate

คำนวนวันทำงานของทั้งหมดก่อน

💡
Team Capacity = Σ (Working Day × Working Hour x Team member × Availability)

ตัวอย่าง

10 x 7 x 5 x 70% = 245h

✅ เวลาทำงานตั้งต้นจะเท่ากับ 245h/sprint

2. หักเวลาออก

โดยทั่วไปแล้วแต่ละวันของการทำงานนั่น มักมีสิ่งที่ต้องนำเสมอ โดยเราสามารถแบ่งออกเป็น 2 ประเภทใหญ่ๆ คือ

  • กิจกรรม ที่สามารถวางแผนล่วงหน้าได้ (Plan)
  • กิจกรรม ที่ไม่สามารถวางแผนล่วงหน้าได้ (Upplan)

โดย 2 แบบนี้ เราจะจัดการมันแตกต่างกัน คือ

กิจกรรม ที่สามารถวางแผนล่วงหน้าได้

กิจกรรมไหนที่สามารถนัดหมาย หรือ กำหนดไว้เป็นกิจวัตรได้ ก็จะกำหนดไว้ล่วงหน้าได้เลย และระบุจำนวนชั่วโมงของกิจกรรมนั้นไว้

เช่น

  • Sprint Planning
  • Daily Planning & Sync up
  • Daily Review
  • Refinements
  • Spring Review + Sprint Retrospective
  • Meeting ที่มีการ invite ล่วงหน้า
  • วันลาล่วงหน้า เช่น ลากิจ, ลาพักร้อน เป็นต้น

Calculate

เราต้องระบุกิจกรรมที่สามารถรู้ล่วงหน้าออกมาก่อน เช่น

  • Sprint Planning : 1h (Monday)
  • Daily Planning & Sync up (ทุก: 30min ยกเว้นวันสุดท้าย): (30m x 9d) / 60m = 4.5h
  • Daily Review (30min): (30m x 9d) / 60m = 4.5h
  • Refinements (4h/week, กำหนดให้ 1 sprint = 2 week): 4h x 2week = 8h
  • Spring Review + Sprint Retrospective (full day): 7h (ในตัวอย่างเวลาทำงานต่อวันเท่ากับ 7h/day ของคนอื่นๆ เป็น 8h/day)

เอาเวลาทั่งหมดมารวมกันก็จะได้

Personal's Plan Events = 1 + 4.5 + 4.5 + 8 + 7

Team's Plan Events = Personal's Plan Events ของแต่ละคนรวมกัน

Team's Plan Events = 25 + 25 + 25 + 25 + 25 = 125h

กิจกรรม ที่ไม่สามารถวางแผนล่วงหน้าได้

ขึ้นอยู่กับแต่ละทีม ซึ่งแต่ละทีมสามารถ buffer ได้เลย ขึ้นอยู่กับว่าทีมมีงานที่ unplan มากน้อยแค่ไหน

โดยตัวอย่างของงานที่เป็น upplan เช่น

  • งานแทรก (งานที่ไม่ได้อยู่ใน sprints)
  • Debug
  • Delay
  • Production issue

ตัวอย่าง

สมมติว่า buffer ไว้ที่ 10-20% ของ sprint

3. Team Effort

ผลรวมของทั่งทีมเท่ากับ effort ที่รับได้ในแต่ละ sprint

Calculate

💡
Usable Capacity = (Team Capacity - Team's Plan Events) × Buffer%

ตัวอย่าง

  • เวลาทำงานใน sprint = 245h
  • หักกิจกรรม (Team's Plan Events) = 125h
  • หัก buffer 20% = 0.2 (Availability = 0.8)

(245-125) x 0.8 = 145h

ดังนั้น งานที่ commit ควร ≤ 145h

เท่านี้เราก็สามารถเอาเวลา effort ของทีมไปหยิบงานเข้า sprint ได้เลย

[แถม] เราควรรวมเวลาของ QA/Tester เข้าไปด้วยไหม

คำตอบ คือ รวมได้ และ “ควรรวม” ด้วย ถ้าทีมเราทำงานแบบ cross-functional team จริงๆ

⚠️
ต้องคิดให้ถูก แบบ Agile

หลักคิดสำคัญ (Agile Mindset)

โดยเฉพาะใน Scrum จะไม่มีการแยก state การทำงานระหว่า Implementation กับ Testing และจะมองว่าทั้งสองเป็นทีมเดียวกันเลย

“ทีมส่งมอบงานที่ Done = dev + test”

เรานิยามคำว่างานเสร็จ เท่ากับ งานที่พร้อมนำขึ้น Production เท่านั้น

ดังนั้น:

  • Effort ของ Tester = Effort ของทีม
  • งานยังไม่ Done ถ้ายังไม่ผ่าน test

❌ การไม่รวม tester = ภาพ capacity ทีม “เกินจริง” ไม่ตรงกับความเป็นจริง

และเวลารวมของ scenarios/cases/tasks ที่จะหยิบไปทำจะต้อง estimate เวลาทดสอบลงไปด้วย

วิธีรวมเวลาของ Tester (Hour-based)

Step 1: คิด Capacity แยกตาม role (แต่รวมเป็นทีม)

วิธีนี้เราสามารถคิดแยกแต่ละ role ได้ แต่หา efforts เป็นทีม

ตัวอย่าง

  • Dev 4 คน: 10 day × 6h. × 80% = 48h/person → 192h
  • Tester 1 คน: 10 day × 6h × 80% = 48h

Team Capacity รวม = 240h

แยกคิดได้ แต่ commit เป็นทีม

Step 2: Estimate Task ให้สะท้อนงาน test จริง

ในแต่ละ tasks จะต้องลงรายละเอียดให้ครบถ้วนที่สุด เพื่อให้เคลียว่าเราจะต้องทำอะไรบ้าง และใช้เวลาทำไหร่ เช่น

Development Task

  • Implement API: 16h
  • Setup Database: 3h
  • UI: 12 h

Test Task

  • Test case design: 6h
  • Manual test: 8h
  • Regression test: 6h

สักเกตุว่า แต่ละ Scenarios มี tasks ของหลาย roles อยู่ในนั้น

สิ่งที่ “ห้ามทำ” กับ Tester

❌ คิด tester เป็น “support”
❌ เอา tester ไปใส่ท้าย Sprint
❌ คิดว่า tester จะมาทันเสมอ
❌ commit งาน dev เต็ม แต่หวังว่า tester จะ “เอาอยู่”

Sprint fail ส่วนใหญ่มาจาก test bottleneck

ดังนั้นมอง tester ให้เป็นส่วนหนึ่งของทีม และ estimate งานให้สะท้อนความเป็นจริงที่สุด จะทำให้ เราสามารถส่งมอบงานได้ใกล้เคียงกับที่ commitment มาที่สุด