Tóm tắt nhanh
Estimate trong Scrum không chỉ là đo "mất bao nhiêu ngày". Nhiều team dùng story point để biểu thị độ phức tạp tương đối, bao gồm effort, uncertainty và risk. Trong dự án Nhật, bạn nên giải thích estimate bằng giả định rõ ràng, nhất là khi spec chưa chắc hoặc dependency còn mở.
Bài này giúp developer Việt Nam nói về 見積もり, story point và risk một cách dễ hiểu.
Story point là gì?
Story point là đơn vị tương đối để team ước lượng độ lớn của backlog item. Nó không phải ngày công cố định.
Một story 5 point có thể vì:
- Logic phức tạp hơn story 3 point
- Có nhiều màn hình hoặc API liên quan
- Acceptance criteria nhiều hơn
- Có uncertainty vì tài liệu chưa rõ
- Có risk về dữ liệu, performance, permission
Mỗi team có scale riêng, thường dùng Fibonacci như 1, 2, 3, 5, 8, 13. Quan trọng là team hiểu chung, không phải con số tuyệt đối đúng.
Estimate nên dựa trên gì?
- Yếu tố
- Scope
- Câu hỏi
- Phạm vi gồm những phần nào?
- Yếu tố
- Complexity
- Câu hỏi
- Logic có phức tạp không?
- Yếu tố
- Uncertainty
- Câu hỏi
- Có điểm chưa rõ không?
- Yếu tố
- Dependency
- Câu hỏi
- Có phụ thuộc team khác không?
- Yếu tố
- Test
- Câu hỏi
- Cần test nhiều case không?
- Yếu tố
- Risk
- Câu hỏi
- Có ảnh hưởng production, dữ liệu, security không?
Nếu scope nhỏ nhưng uncertainty lớn, estimate vẫn có thể cao. Vì vậy cần nói lý do, không chỉ đưa số.
Planning poker trong team Nhật
Planning poker là cách team cùng estimate rồi so sánh kết quả. Nếu một người chọn 3 point, người khác chọn 8 point, team cần thảo luận vì sao khác nhau.
Ví dụ:
- Người
- Developer A
- Point
- 3
- Lý do
- Nghĩ chỉ sửa màn hình
- Người
- Developer B
- Point
- 8
- Lý do
- Biết API và CSV cũng bị ảnh hưởng
Chênh lệch estimate giúp phát hiện 認識違い. Đây là điểm rất hữu ích trong team Nhật.
Cách nói uncertainty
Đừng ngại nói "chưa đủ thông tin". Nhưng hãy nói cụ thể:
現時点ではAPI仕様が未確定のため、正確な見積もりが難しいです。
まず調査タスクを1日分入れたいです。
Nghĩa là: Hiện tại API spec chưa chốt nên khó estimate chính xác. Tôi muốn thêm một task điều tra 1 ngày trước.
Nếu vẫn phải estimate:
画面修正のみであれば3ポイントです。
API修正も含む場合は5ポイントになると思います。
Bạn đang làm rõ giả định của estimate, rất quan trọng trong planning.
Câu tiếng Nhật nên nhớ
- 日本語
- 見積もりを確認します。
- かな
- みつもりをかくにんします
- Nghĩa tiếng Việt
- Tôi sẽ xác nhận estimate.
- Dùng khi nào
- Planning
- 日本語
- 3ポイントだと思います。
- かな
- さんぽいんとだとおもいます
- Nghĩa tiếng Việt
- Tôi nghĩ là 3 point.
- Dùng khi nào
- Planning poker
- 日本語
- 不確実性があります。
- かな
- ふかくじつせいがあります
- Nghĩa tiếng Việt
- Có uncertainty.
- Dùng khi nào
- Spec chưa rõ
- 日本語
- 前提を確認したいです。
- かな
- ぜんていをかくにんしたいです
- Nghĩa tiếng Việt
- Tôi muốn xác nhận giả định.
- Dùng khi nào
- Trước estimate
- 日本語
- 調査が必要です。
- かな
- ちょうさがひつようです
- Nghĩa tiếng Việt
- Cần điều tra.
- Dùng khi nào
- Spike
- 日本語
- 影響範囲が広いです。
- かな
- えいきょうはんいがひろいです
- Nghĩa tiếng Việt
- Phạm vi ảnh hưởng rộng.
- Dùng khi nào
- Estimate cao
- 日本語
- 画面修正のみであれば3ポイントです。
- かな
- がめんしゅうせいのみであればさんぽいんとです
- Nghĩa tiếng Việt
- Nếu chỉ sửa màn hình thì 3 point.
- Dùng khi nào
- Nêu giả định
Developer Việt Nam dễ hiểu sai điểm nào?
1. Story point là ngày
Không nên quy đổi máy móc. Point là tương đối trong team.
2. Estimate thấp để gây ấn tượng
Estimate thấp nhưng trễ liên tục làm mất niềm tin. Hãy estimate dựa trên scope và risk.
3. Không nói giả định
Nếu estimate dựa trên "chỉ sửa màn hình", hãy nói rõ. Nếu sau đó thêm API, estimate cần đổi.
4. Không tách spike
Khi uncertainty quá lớn, spike giúp team học trước khi cam kết implementation.
Checklist estimate
- Scope đã rõ chưa?
- Acceptance criteria đã đủ chưa?
- Có dependency hoặc approval ngoài team không?
- Có cần spike không?
- Estimate có nêu giả định không?
- Nếu point khác nhau trong team, đã thảo luận lý do chưa?
Học tiếp trên JLPTVN
Đọc thêm sprint planning, refinement, quản lý deadline. Luyện câu tại progress và ticket.
Sau khi đọc, làm bài luyện IT và lưu câu sai ở Review để quay lại đúng điểm yếu.
FAQ
Story point có cần chính xác tuyệt đối không?
Không. Nó là công cụ để team cùng hiểu độ phức tạp và lập kế hoạch tốt hơn.
Nếu estimate sai thì có bị đánh giá kém không?
Estimate có thể sai. Điều quan trọng là học từ sai lệch, nói risk sớm và cải thiện refinement.
Khi nào nên tách spike?
Khi team chưa biết đủ để estimate hoặc implement an toàn: API mới, library mới, dữ liệu lớn, ảnh hưởng hệ thống cũ.