Login

Ước lượng công việc phần mềm: story point và planning poker thực chất là gì?

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

'Mất bao lâu thì xong?' là câu hỏi khiến lập trình viên toát mồ hôi nhất. Ước lượng phần mềm khó vì có quá nhiều điều chưa biết. Bài này giúp bạn hiểu mục đích của việc ước lượng, cách dùng story point và planning poker, cùng những hiểu lầm thường gặp.

Vì sao ước lượng lại khó?

Phần mềm là công việc sáng tạo có nhiều ẩn số: yêu cầu thay đổi, công nghệ chưa quen, lỗi bất ngờ. Con người cũng có xu hướng lạc quan quá mức và quên cộng thời gian họp, review, sửa lỗi. Vì vậy ước lượng luôn là dự đoán, không phải cam kết. Mục tiêu không phải đoán đúng từng giờ mà là có đủ thông tin để lập kế hoạch và ra quyết định.

Ước lượng tương đối tốt hơn ước lượng tuyệt đối

Con người rất kém khi nói 'việc này mất 7 giờ 20 phút', nhưng khá giỏi khi so sánh: 'việc này lớn gấp đôi việc kia'. Story point dựa trên ý tưởng đó: nó đo độ lớn tương đối của công việc, kết hợp khối lượng, độ phức tạp và mức độ không chắc chắn, chứ không phải số giờ.

Cách làm: chọn một story nhỏ, quen thuộc làm chuẩn (ví dụ 2 điểm), rồi so sánh các story khác với nó. Story phức tạp gấp đôi thì 4 điểm, và cứ thế.

Dãy số Fibonacci

Nhiều nhóm dùng dãy 1, 2, 3, 5, 8, 13, 21 để ước lượng. Khoảng cách giữa các số tăng dần phản ánh thực tế: việc càng lớn thì sai số càng lớn, không có lý gì tranh cãi giữa 14 và 15 điểm. Nếu story vượt 13 điểm, đó thường là dấu hiệu cần cắt nhỏ.

Planning poker

Planning poker là cách ước lượng theo nhóm, giảm hiệu ứng 'neo' khi người đầu tiên nói to làm mọi người ngả theo:

  1. Product Owner đọc story, cả nhóm hỏi để làm rõ.
  2. Mỗi người chọn một lá bài (hoặc số trên ứng dụng) trong dãy, giữ kín.
  3. Tất cả cùng lật lên một lúc.
  4. Nếu các con số gần nhau, chọn một giá trị chung.
  5. Nếu chênh lệch lớn, người chọn số cao nhất và thấp nhất giải thích lý do. Thường vì ai đó biết một rủi ro hay giải pháp mà người khác không biết.
  6. Bỏ phiếu lại cho đến khi đồng thuận.

Giá trị lớn nhất của planning poker không nằm ở con số cuối mà ở cuộc thảo luận làm lộ ra những hiểu lầm sớm.

Velocity và dự báo

Velocity là tổng số điểm nhóm hoàn thành trong một sprint. Sau vài sprint, bạn có một con số trung bình khá ổn định, dùng để dự báo: nếu backlog còn 100 điểm và velocity trung bình 20 điểm mỗi sprint thì cần khoảng 5 sprint. Lưu ý rằng velocity là công cụ nội bộ để nhóm lập kế hoạch, không nên dùng để so sánh các nhóm với nhau hay đánh giá cá nhân, vì điểm của mỗi nhóm có thang riêng.

Những hiểu lầm hay gặp

  • Quy đổi cứng 1 điểm bằng 1 ngày: làm mất ý nghĩa tương đối của điểm.
  • Ép tăng velocity: nhóm sẽ bắt đầu thổi phồng điểm, con số mất giá trị.
  • Ước lượng thay cho người khác: người thực hiện nên là người ước lượng.
  • Coi ước lượng là lời hứa: dẫn đến áp lực và hạ chất lượng.
  • Ước lượng quá chi tiết: tốn thời gian mà không tăng độ chính xác đáng kể.

Giảm bất định khác

  1. Chia nhỏ công việc: việc nhỏ dễ ước lượng hơn việc lớn.
  2. Làm spike (thử nghiệm giới hạn thời gian) khi có điều chưa biết về kỹ thuật.
  3. Dùng dải thay vì con số duy nhất khi báo với khách hàng, ví dụ 'từ 4 đến 6 tuần'.
  4. Cập nhật ước lượng khi hiểu biết thay đổi.
  5. So sánh với dữ liệu quá khứ của chính nhóm.

Còn cách khác không?

Có. Một số nhóm không ước lượng điểm mà chỉ đếm số story (sau khi cắt cho cỡ gần đều nhau) và đo throughput. Cách này đơn giản hơn và nhiều nhóm thấy đủ chính xác. Hãy chọn cách ít tốn công nhưng vẫn cho bạn thông tin cần thiết.

Kết luận

Ước lượng tốt không phải đoán trúng, mà là giúp nhóm hiểu công việc, thấy rủi ro sớm và lập kế hoạch thực tế. Hãy dùng ước lượng tương đối, thảo luận trung thực và coi con số là công cụ chứ không phải lời hứa.

Nếu bạn muốn rèn kỹ năng lập kế hoạch và quản lý tiến độ cho dự án phần mềm, hãy tham khảo thêm tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment