Ước lượng & Planning Poker

Dùng khi: lập kế hoạch sprint/release; team ước lượng lệch triền miên; hoặc một người ước lượng cho cả team và luôn sai.

3 cách ước lượng

Story point: đo độ phức tạp + nỗ lực + rủi ro tương đối (thang Fibonacci 1-2-3-5-8-13), không trực tiếp là thời gian. Phổ biến nhất.
Ideal days/hours: ngày công lý tưởng — dễ hiểu với quản lý, nhưng dễ bị đem so với lịch thật.
T-shirt size (S/M/L/XL): ước lượng thô cho roadmap/epic, khi chi tiết chưa đủ để chấm point.

Chốt point cơ sở cả team cùng hiểu, ví dụ từ course: 1đ = nút bấm gọi 1 API không validation; 3đ = form có validation + lấy dữ liệu; 5đ = màn hình CRUD đủ; 8đ = tích hợp bên thứ ba, nhiều exception; 13đ = tích hợp phức tạp, đối tác khó lường.
Planning Poker: PO đọc story → hỏi đáp làm rõ → mọi người chọn bài kín, lật cùng lúc → người chấm thấp nhất và cao nhất giải thích → chấm lại đến khi hội tụ. Lật cùng lúc để tránh neo theo người nói trước; chênh lệch lớn = hiểu khác nhau về scope, chính cuộc tranh luận đó là giá trị thật của buổi ước lượng.
Tự hiệu chỉnh qua velocity: sau mỗi sprint tính lại giờ-thực/point (vd sprint 1: 580h/200đ = 2.9h/đ; sprint 2: 2.6h/đ) — dùng dữ liệu này cho kế hoạch sau, không dùng để so team này với team khác.

Quy đổi cứng point = giờ ngay từ đầu → mất bản chất tương đối, thành công cụ ép tiến độ.
Sếp/senior chấm trước, cả team theo — đúng cái Planning Poker sinh ra để chống.
So velocity giữa các team hoặc dùng làm KPI cá nhân → team sẽ lạm phát point.
Story 13+ point cứ để nguyên đưa vào sprint — phải tách trước (Product Backlog & User Story).

Nguồn: Module 10. Liên quan: Product Backlog & User Story · Đọc Burndown Chart · Scrum & vai trò PO