ในบทความนี้จะเป็นเรื่องเกี่ยวกับการประมาณขนาดของ Product Backlog หรือ User Story ด้วย Story Point ซึ่งมันจะเป็นเทคนิคพื้นฐานของการประมาณการ (estimate), การวางแผนงาน (planning), การติดตามงาน (tracking), และการประเมินฝีจักร (velocity) ของทีม และยังเป็นเครื่องมือที่ใช้สำหรับการปรับแผนงาน ให้สอดคล้องกับความสามารถของทีมพัฒนาอีกด้วย อยากรู้ว่ามันคืออะไรก็ click เข้าไปอ่านต่อกันเลยครับ

ที่มาของภาพ http://www.crisp.se/planningpoker

Software Development Estimating & Planning

จากประสบการณ์ที่ผมทำงานมา ผมคิดว่าเรื่องที่ยากที่สุดเรื่องหนึ่งเมื่อต้องพัฒนาซอฟท์แวร์ซักตัวนึง ก็คือ การวางแผนและประมาณการ เพราะไม่ว่าผมจะพยายามวางแผนให้ดีที่สุดยังไงก็ตาม สุดท้ายงานมันก็ไม่เคยเป็นไปตามแผนเลย จึงทำให้ผมไม่ชอบคำถามหนึ่งมากๆ เมื่อลูกค้าถามมา ก็คือ “คิดว่าใช้เวลาเท่าไหร่ครับ ? ” … ทั้งๆ ที่ผมกับลูกค้าเพิ่งเจอหน้ากันและคุยเกี่ยวกับ project ไม่ถึง 2 ชั่วโมงเลย และที่สำคัญก็คือ ถ้าเราเผลอให้คำตอบไปละก็ มันจะไม่ใช่การ “ประมาณ” อีกแล้ว แต่มันกลายเป็น “คำสัญญา” ที่ลูกค้าจะคาดหวังว่ามันจะต้องเป็นไปตามนั้น ถ้าทำไม่ได้ก็จะโดนด่าว่า “คุณบอกเองว่า x เดือน แล้วทำไมทำไม่ได้” …

ปัญหาก็คือว่าแผนก็คือแผน เราไม่สามารถบอกได้เป๊ะๆ 100% ในความเป็นจริง คิดง่ายๆ ถ้าคุณทำงานบริษัท ต้องตื่นออกไปทำงานทุกเช้าและกลับบ้านในตอนเย็นทุกวัน (ตรงกลับบ้านเลยนะครับ อย่าแวะไปอาบน้ำที่ไหน ^^) คุณบอกผมได้ไหมครับว่าพรุ่งนี้เช้า คุณจะไปถึงที่ทำงานกี่โมง กี่นาที และตอนเย็นจะกลับถึงบ้าน กี่โมง กี่นาที เราบอกเวลาที่แน่นอนขนาดนั้นไม่ได้ใช่ไหมครับ ทั้งๆ ที่เราก็เดินทางไปทำงานทุกวัน เส้นทางก็เหมือนเดิม  สิ่งที่คุณทำได้อย่างเดียวคือ “ประมาณ” เท่านั้น โดยประเมินจากสภาพแวดล้อมระหว่างทางที่เราเดินทางไปทำงาน บวกกับประสบการณ์ที่เราคุ้นเคย แต่ถ้าวันไหนเกิดมีอุบัติเหตุบนเส้นทางที่เราใช้เป็นประจำ เวลาที่จะถึงที่หมายก็คลาดเคลื่อนออกไปแน่นอน การพัฒนา software ก็เช่นเดียวกัน

Estimate By Task

ที่ผ่านมาการวางแผนและประมาณการ จะทำโดยการแตกสิ่งที่ทีมพัฒนาต้องทำตาม requirement ออกมาเป็นชิ้นงาน เรียกว่า task แล้ว estimate ว่าแต่ละ task นั้นใช้เวลาเท่าไหร่ และแจกงานให้แต่ละคนเอา task เหล่านั้นไปทำ งานไหนที่ทำพร้อมกันได้ ก็เอามาวางแบบ parallel งานไหนที่ต้องรองานอื่น เราก็เอาไปต่อท้ายงานนั้น สุดท้ายก็ได้เป็น Gantt Chart ที่บอกว่าเมื่อไหร่งานจะเสร็จ

Your Estimation is not Mine

ปัญหาของการวางแผนแบบนี้ ข้อแรก ก็คือ เราประเมินงานด้วยระยะเวลาอย่างเดียว และที่สำคัญ “จำนวนวันที่คนคนหนึ่งใช้ในการพัฒนา จะไม่เท่ากับจำนวนวันที่อีกคนหนึ่งใช้ในการพัฒนา” … พูดให้เข้าใจง่ายๆ ก็คือว่า งานแบบเดียวกัน ใช้วิธีการเขียนโปรแกรมเหมือนๆ กัน ไม่ได้หมายความว่า คน 2 คนจะใช้เวลาเท่ากันเสมอไป เพราะแต่ละคนก็จะมีความถนัดและประสบการณ์ที่ต่างกัน คนที่เชี่ยวชาญอาจเขียนหน้าจอ login เสร็จในเวลาแค่ 1-2 ชั่วโมง ในขณะที่เด็กจบใหม่อาจใช้เวลามากกว่า 3 วัน … และยิ่งโดยเฉพาะถ้า SA หรือ Project Manager ประเมินเวลาให้ด้วยแล้วละก็ ยิ่งไปกันใหญ่ เพราะ SA ไม่มีทางรู้ได้เลยว่า programer จะใช้เวลาพัฒนาเท่ากับที่ SA คิดหรือไม่

บางคนอาจจะบอกว่า ถ้างั้นก็กำหนดไปเลยซิว่า task นี้ให้ใครทำ แล้วให้คนนั้นประเมินเวลา task ของตัวเองไปเลย … มันก็ได้ครับ ถ้า task นั้นให้คนๆ นั้นทำแน่นอน แต่ถ้าเกิดงานของ programmer คนนั้นเยอะเกินไปหรือทำไม่ทัน และต้องให้คนอื่นที่เสร็จงานอื่นแล้วมาช่วยทำ … เรายังจะบอกได้รึเปล่าครับว่าเวลาที่ใช้ในการ implement task นั้นจะเท่ากับที่ประเมินไว้ในครั้งแรกหรือเปล่า?

Business Value

ปัญหาในข้อสุดท้ายก็คือ ลูกค้าได้ประโยชน์อะไรจากการวางแผนตาม task เหล่านั้น?  ลองมองย้อนกลับไปในตอนที่แล้วที่เราเขียน Product Backlog กัน สิ่งที่เราสื่อสารกับ Product Owner ก็คือ requirement แต่ละข้อใน Product backlog โดยปกติแล้วลูกค้าก็ไม่สนใจ ว่า requirement แต่ละข้อนั้นจะถูกแตกไปกี่ task และใครเป็นคนทำ task ชิ้นนั้น สิ่งที่เค้าสนใจจริงๆ ตอนที่เค้าติดตามงานก็คือ “จาก Product Backlog ที่เราคุยกันวันนั้นน่ะ วันนี้ซอฟท์แวร์ไปถึงไหนแล้ว? ได้อะไรบ้าง? เสร็จไปแล้วกี่เรื่องถ้าดูจาก Backlog? เรากำหนด priority ใช่ไหม แล้วงานที่มี priority สูงๆ เสร็จหรือยัง?”

ถ้าเป็นการพัฒนาแบบ water fall เหมือนที่ผ่านมา เราจะเอา requirement มาแตกออกเป็น task ตามขั้นตอนของ waterfall เช่น “ตอนนี้ design เสร็จแล้ว ตอนนี้อยู่ใน phase develop ซึ่งเริ่ม implement หน้าจอ A … มี business class กับ database base แล้ว ซึ่งถ้าประเมินงานคิดว่าน่าจะไปแล้วประมาณ 25%” สำหรับทีมพัฒนา คือ 25% ครับ แต่สำหับลูกค้าแล้ว จะเท่ากับศูนย์ เพราะมันยังไม่ใช่ software ที่ทำงานได้

แนวทางในการวางแผนและประมาณการของ Agile ก็ยังคงอยู่บนพื้นฐานของ Iterative & Incremental เช่นเดิม แต่การแตกช่วงของการพัฒนาเป็น iteration นั้นเราจะต้องมีวิธีการวางแผนและประมาณการที่สอดคล้องกับลักษณะของ iteration ด้วย ซึ่ง Story Point จะเป็นเครื่องมือพื้นฐานชิ้นแรกที่จะทำให้การวางแผนและติดตามงานแบบ Iteration & Incremental เป็นไปได้ในทางปฎิบัติครับ

Basic Idea about “Story Point”

ถ้าผมจำไม่ผิด Story Point นั้นไม่ได้มาจาก Scrum …น่าจะมาจาก Extreme Programming นะ … เอาเป็นว่าบอกตรงๆ เลยละกัน ว่าผมจำไม่ได้แล้วว่ามาจาก methodology ไหน :b (ผมอ่านจากหนังสือเรื่อง Agile Estimating & Planning ครับ) แต่เราสามารถเอาวิธีการ estimate แบบ story point ไปใช้กับ methodology แบบ Agile ได้แทบจะทุกแบบครับ (ผมยังไม่ได้ศึกษาครบทุก methodology แต่คิดว่าน่าจะได้หมดนะ)

ที่ผ่านมาเราประเมินงานแต่ละงานด้วย “เวลา” เสมอมา เช่น พัฒนาหน้าจอ login จะใช้เวลากี่ man/day แต่ในขณะที่ Story Point นั้นจะเป็นการประเมิน “ขนาด” ของ requirement ครับ

ผมขอใช้ Pizza มาเป็นตัวอย่างเพื่อให้คุณเข้าใจเรื่องขนาดของ requirement ก็แล้วกัน (ต้องขอโทษด้วยนะครับ ถ้าใครกำลังหิว ^_^)

ผมคิดว่าคงไม่มีใครไม่เคยทาน Pizza นะ (จะ company หรือ hut ก็แล้วแต่) คุณพอจะนึกภาพออกไหมครับว่า Pizza ถาดใหญ่ ถาดกลาง และถาดเล็ก มีขนาดแตกต่างกันยังไง … ผมยกตัวอย่างให้ก็แล้วกัน … Pizza ถาดเล็กจะแบ่งเป็นชิ้นได้ 4 ชิ้น ถ้าถาดกลางจะได้ 6 ชิ้น ส่วนถาดใหญ่จะได้ 8 ชิ้น … ถ้าเปรียบเทียบง่ายๆ โดยมองว่า Pizza 1 ถาด คือ requirement แต่ละ requirement และ จำนวนชิ้นที่สัมพันธ์กับขนาดของ Pizza ก็คือ Story Point … เพราะฉะนั้น Pizza ถาดเล็กจะได้ Story Point (ขนาด) เท่ากับ 4 ในขณะที่ถาดกลางจะเท่ากับ 6 และถาดใหญ่จะเท่ากับ 8 … นึกภาพตรงนี้ให้ออกก่อนจะไปต่อนะครับ (โอย … พิมพ์ไปก็หิวไป -_-!)

สมมติว่ามีเป๊บซี่ด้วย คราวนี้เป๊บซี่ไม่มีเป็นชิ้น … คุณคิดว่าเป๊บซี่ ควรมี Story point เท่าไหร่ครับ? … วิธีการเทียบก็ง่ายๆ … เทียบกับสิ่งที่มีขนาดใกล้เคียงกับมันที่สุด … เอา Pizza ถาดเล็กก็แล้วกัน ถ้า Pizza ถาดเล็กมีขนาด 4 งั้นเป๊บซี่ก็น่าจะประมาณ 1 ถึง 2 …

ขออีกตัวอย่างก็แล้วกัน สั่งสปาเก็ตตี้มาด้วย … ขนาดของสปาเก็ตตี้ 1 ที่ น่าจะมากกว่าเป๊บซี่ แต่ไม่น่าจะมากเท่ากับ Pizza ถาดเล็ก … งั้น Story Point ของสปาเก็ตตี้น่าจะซัก 3 … OK นะครับ นี่คือแนวทางในการประเมินขนาด และให้ point มัน ตอนนี้ยังไม่ต้องสนใจว่า point นั้นจะเกี่ยวกับเวลายังไง แต่สนใจแค่เพียงว่า Point ของแต่ละ Story หรือ Requirement นั้นจะต้องมีค่าที่ความสัมพันธ์และสอดคล้องกันก็พอ

หลายคนอ่านถึงตรงนี้อาจจะงงๆ ว่า ขนาดของ Pizza กับสปาเก็ตตี้ เกี่ยวอะไรกับการ Estimate ฟะ … ใจความสำคัญมันอยู่ตรงนี้ครับ … ผมบอกไว้ในปัญหาข้อแรกว่า “จำนวนวันที่คุณใช้ในการพัฒนา ไม่ใช่จำนวนวันที่ผมใช้ในการพัฒนา” ลองเอามาใช้กับ Pizza แบบนี้ครับ … ถ้าผมกิน Pizza ถาดเล็กคนเดียวหมดภายใน 1 มื้อ ก็ไม่ได้หมายความว่าคุณจะกินคนเดียวหมดถาดภายในมื้อเดียวเหมือนผม … จริงไหมครับ เผลอๆ บางคนอาจจะต้องกิน 2 ถาดจึงจะอิ่มด้วยซ้ำ … เราก็อนุมานได้ว่า ความสามารถในการกิน Pizza ของแต่ละคน ก็คือ ความสามารถในการ implement requirement ของแต่ละคนที่ไม่เท่ากันนั่นเอง

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

การประเมิน point ให้กับแต่ละ requirement แต่ละข้อนั้น ไม่มีกฎเกณฑ์ตายตัว หลักในการประเมิน point ให้กับ requiment นั้นมีข้อเดียว คือ ถ้าเราใช้หลักอะไรในการประเมิน point ให้กับ requirement ข้อแรก ข้อต่อไปก็ต้องใช้หลักเดียวกัน

โดยทั่วไปก็มักจะประเมินจากปริมาณงานที่เราต้องทำสำหรับ requirement ข้อนั้น เช่น มีหน้าจอเยอะไหม ยากไหม ซับซ้อนแค่ไหน SQL statement ยากไหม เป็นต้น โดยให้เริ่มประเมิน requirement ข้อที่ขนาดกลางๆ ก่อน แล้วค่อยหยิบข้อต่อไปมาเปรียบเทียบกัน เป็นต้น

Using Story Point to measure Velocity

จากตัวอย่างข้างต้น ผมจะให้โจทย์ให้คุณคิดเล่นๆ ครับ สมมติว่าคุณกับแฟน (ไม่มีแฟน สมมติเอาก็ได้ครับ … T_T) ได้รางวัลส่งพิซซ่าฟรีถึงบ้าน มี pizza ถาดใหญ่ 2 ถาด สปาเก็ตตี้ 1 ที่ ไก่นีออร์ลีน 8 ชิ้น และเป๊ปซี่ 2 ลิตร 1 ขวด คุณคิดว่าคุณกับแฟนจะกินมันให้หมดได้ ในเวลากี่มื้อครับ? (ต้องหมดนะ)

อาหารแต่ละอย่างก็คือแต่ละ requirement ส่วนมื้ออาหารแต่ละมื้อ ก็คือแต่ละ iteration ไง … บางคู่อาจจะ 2 มื้อ บางคู่ก็ 3 มื้อ แต่ถ้าคู่ไหนพลังในการทำลายล้างสูง ก็อาจจะ clear ได้ภายใน 1 มื้อ … ความสามารถในการ implement ของแต่ละคู่นั้น เราเรียกว่า Velocity ครับ

คำว่า Velocity นั้น ถ้าแปลตาม Google Translate มันจะแปลว่า ฝีจักร ฝีเท้า ความเร็ว ในแง่ของ Agile นั้น Valocity จะเป็นค่าที่เราเอาไว้ประเมินความสามารถของทีม ทั้งทีมครับ ไม่ประเมินรายบุคคล เพื่อใช้วัดว่า ทีมของเรานั้นจะสามารถพัฒนาซอฟท์แวร์ได้กี่ Story Point ต่อ 1 iteration

ยกตัวอย่างคร่าวๆ ครับ สมมติว่า project ที่เรากำลังจะ implement มี requirement 30 ข้อ โดยที่ Product Owner กำหนด Priority ไว้เรียบร้อยแล้ว ขั้นแรก เราก็ให้ทุกคนช่วยกันประเมิน point ของแต่ละ requirement จากนั้นขั้นตอนต่อไป ก็เอา requirement เหล่านั้นมาเรียงลำดับเพื่อประเมินว่า ใน Sprint รอบแรกนั้นจะมี requirement ข้อไหนบ้างที่เราคิดว่าน่าจะทำให้เสร็จได้ จำนวน Story Point ที่ได้ใน Sprint รอบแรก ก็คือค่าของ Velocity ที่เรา estimate ครับ

เมื่อทำงานจริง เป็นไปได้ (มาก) ว่าเราจะทำไม่เสร็จตามแผน นั่นคือเมื่อจบ Sprint รอบแรก จะมีบาง requirement ที่ไม่เสร็จ ให้เรารวม Story Point ของ requirement ที่เสร็จแล้ว (ย้ำว่าเฉพาะที่ “เสร็จแล้ว” เท่านั้นนะครับ ผมจะแยกหัวข้อเรื่อง “เสร็จแล้วเท่านั้น” ไปเป็นอีกหัวข้อหนึ่ง เรียกว่า Done Done Definition ครับ) ตัวเลขนั้นคือ Velocity จริงของทีมเรา

เมื่อได้ Velocity มาจาก Sprint รอบแรก คราวนี้เราจะต้องเอา velocity มาปรับแผนใน Spring รอบถัดไป เพื่อให้การ estimate นั้นใกล้เคียงกับความเป็นจริงมากที่สุด นั่นหมายความว่า ถ้าในแต่ละรอบคุณ estimate point ไว้มากเกินไปแต่เมื่อทำจริงคุณเก็บ point ไม่ได้ตามนั้น แสดงว่า วันที่ส่งมอบ software จะต้องเลื่อนออกไปแน่นอน

Example

ลองดูตัวอย่างนะครับ

1. สมมติ มี 30 requirement แต่ละ requirement มี point เท่าๆ กัน คือ 5 นั่นคือเราจะมี Story Point ที่ต้องเก็บให้หมดเท่ากับ 150 point
2. เบื้องต้น เราประเมินกันว่า ทีมของเราน่าจะเก็บได้ Sprint ละ 30 Point (requirement 6 ข้อ ต่อ Sprint 1 รอบ)  … แสดงว่าเราน่าจะจบ release ได้ใน 5 เดือน
3. เมื่อ Sprint แรกผ่านไป ปรากฎว่าเรา implement requirement เสร็จจริงแค่ 4 ข้อเท่านั้น แสดงว่า velocity ของทีม คือ 4 x 5 = 20 point ต่อ Sprint 1 รอบ
4. เมื่อได้ velocity เราก็ต้องเอามาปรับแผนใหม่ โดยเอา requirement ที่เหลือมาวางแผนใหม่
5. จากรอบแรกที่เสร็จไปแล้ว 20 point ก็จะเหลือ point เท่ากับ 130 point … ค่าของ velocity ในรอบแรกคือ 20 เพราะฉะนั้น จำนวน Sprint ที่เราจะต้องใช้จากนี้ไป คือ 130 หาร 20 เท่ากับ 6.5 หรือเท่ากับ Sprint อีก 7 รอบ
6. เมื่อจบ Sprint รอบที่ 2 เราก็ต้องดูอีกครั้งว่า เราเก็บ point ได้เท่าไหร และประเมินกันว่า ทำไมระหว่าง Sprint รอบแรกและรอบที่ 2 ไม่เท่ากัน แล้ว Velocity ในรอบที่ 3 ควรจะเป็นเท่าไหร่ ก็เอา point ที่ได้ มาหารกับ point ที่เหลือ เราก็จะรู้ได้ว่าเวลาที่จะส่งมอบนั้นจะเป็นอย่างไรในทุกๆ Iteration ครับ

บางคนอาจจะสงสัยว่า แล้วในครั้งแรก เราจะรู้ velocity ของทีมได้ยังไง คำตอบคือ ไม่รู้หรอกครับ มันคือ “การประมาณคร่าวๆ” เท่านั้น เค้าถึงใช้คำว่า estimate ไง เราจะรู้ก็ต่อเมื่อป่านไปแล้ว 1 iteration แต่ตัวเลขจะเริ่มนิ่งจริงๆ ก็น่าจะ 3-4 iteration โน่นแหละ

บางคนอ่านถึงตรงนี้ก็จะคิดว่า อ้าว แล้วจะมีประโยชน์อะไรละ ในเมื่อ estimate ไปก็ไม่ตรงอยู่ดี คำตอบก็คือ มีประโยชน์ครับ สังเกตุว่าการคำนวณ velocity นั้นจะทำทุกๆ Sprint เพื่อให้เรารู้ velocity ของทีม แทนที่จะประเมินกันทีเดียวตอนจบ project (ซึ่งผมเชื่อว่าไม่เคยมี) ก็ให้ประเมินฝีเท้ากันทุกๆ Sprint แทนว่า ในรอบที่ผ่านมา เรา estimate กันถูกไหม ด้วยการประเมิน velocity ในทุกๆ รอบ มันจะเป็นการช่วยให้

• ทีมทั้งทีม ได้เรียนรู้ถึงศักยภาพที่แท้จริงของทีม
• ได้เรียนรู้ปัญหาที่เกิดขึ้นในทีมว่า มีอะไรบ้างที่เป็น factor ที่ทำให้เราใช้เวลาเท่านี้กับงานประมาณนี้
• สามารถบอกกับลูกค้าได้ว่า งานที่เสร็จในตอนท้ายของ project อาจจะได้ไม่ 100% แต่บอกได้ว่าจะได้ requirement ข้อไหนบ้าง
• ในกรณีที่เราทำงานไม่ทัน Product Owner ก็ยังมีข้อมูลช่วยให้ตัดสินใจได้ว่า จะยืดเวลาออกไปเพื่อทำให้เสร็จทั้งหมด หรือที่เหลือค่อยทำต่อ แต่ขอ deploy ระบบตามวันเวลาเดิมก่อนได้ ตั้งแต่ Sprint รอบแรกแทนที่จะไปรู้เอาตอนใกล้จบ project

ในหนังสือเรื่อง Agile Estimating & Planning บอกว่า เราได้เรียนรู้ตลอดเวลาในระหว่างที่พัฒนา ประสบการณ์ที่ได้จะเป็นตัวช่วยให้เราสามารถประมาณการได้ตรงขึ้นเรื่อยๆ (ถ้าไม่เคยทำก็ประเมินไม่ถูกน่ะ) เพราะฉะนั้น Agile จึงแบ่งงานออกเป็น iteration และ estimate ใหม่ทุก iteration เพราะแต่ละรอบเราจะได้เรียนรู้อยู่เสมอ เพียงแต่ที่ผ่านมา กว่าที่เราจะได้เอาสิ่งที่เราเรียนรู้ไปใช้ก็ตอนที่จบ project แรกไปแล้ว (เหมือนกับที่หลายๆ คนพบว่า ถ้าทำรอบ 2 นะ รับรองว่า design ได้ดีกว่านี้ และประเมินเวลาได้แม่นกว่านี้แน่ๆ) นั่นคือจุดมุ่งหมายที่แท้จริงของการนำเรื่อง Story Point และ Velocity มาใช้กับ Iteration และการ estmate แบบ Agile ครับ

Conclusion

การนำ Story Point มา estimate เวลานั้น อาจจะทำได้ยากและใช้เวลามากกว่าในช่วงแรกๆ แต่นั่นก็เป็นเพราะเราไม่มีประสบการณ์ในการประมาณขนาดของ requirement (เคยคิดแค่เวลาอย่างเดียว) แต่เมื่อเริ่มทำไปจะพบว่าการ estimate ด้วย point จะทำง่ายกว่าการประเมินด้วยเวลา และถ้าในครั้งแรกเราประเมินเวลาผิดไป เช่น Pizza ถาดใหญ่ เราเคยคิดว่ากินคนเดียว 2 มื้อก็น่าจะหมด แต่พอกินจริงๆ กลับต้องกิน 3 มื้อ เราก็จะรู้แล้วว่า ต่อไปถ้าเจอ Pizza ถาดใหญ่ ก็ต้องกิน 3 มื้อนั่นแหละ หรือต่อไปเรามีศักยภาพในการกินสูงขึ้น (อ้วนขึ้นน่ะ) เราจะพบว่าคราวนี้ 2 มื้อก็หมดแล้ว แต่ไม่ว่ายังไงก็ตาม ขนาดของ Pizza ก็ยังคงเท่าเดิม

ด้วยแนวคิดแบบนี้ Story Point จึงเปรียบเสมือนเป็นการวัดค่าอีก 1 แกนที่นำมาใช้ประเมินระยะเวลาที่ใช้ implement requirement แต่ละข้อ ถ้า requirement ขนาด 3 point เราใช้เวลา 4 วันแทนที่จะใช้เวลา 3 วันเสร็จ ก็เป็นไปได้ที่ requirement อีกข้อหนึ่งที่มีขนาด 3 เท่ากัน จะใช้เวลา 4 วันเช่นเดียวกัน การปรับแผนก็สามารถทำได้ง่าย เพราะเราสามารถปรับระยะเวลาจาก 3 ไปเป็น 4 ให้กับ requirement ที่มี point เท่ากับ 3 ได้ในครั้งเดียว

และด้วยการประเมิน velocity จะทำให้เราทำงานได้แบบมั่นคง (sustainable) คือไม่ต้องเร่งมากในช่วงท้ายๆ เพราะช่วงแรกๆ ของ project ไม่ค่อยได้ทำงาน เพราะ velocity จะเป็นตัวบอกถึงความสามารถของทีมตั้งแต่ต้นครับ ตาม Principle ของ Agile ข้อที่ว่า

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

นอกจากนั้นยังเป็นไปตาม principle อีกหลายข้อเลย รวมถึง Core Values ตาม Agile manifesto ด้วย ลองกลับไปอ่านบทความเก่าๆ หรือไปอ่านที่ดูที่ Agile Manifesto ก็ได้ครับ