Dù một đội đang phát triển sản phẩm hay dự án, chúng ta cần trả lời: “Chúng ta có thể hoàn thành vào lúc nào?” hay “Chúng ta có thể cung cấp đến mức nào vào một thời điểm nhất định?” Giống như trong các mô hình phát triển truyền thống, chúng ta cần ước lượng khối lượng công việc trước khi bắt đầu một dự án.
Ước lượng Agile có ba đặc điểm sau:
Ước lượng hợp tác của đội
Trong Scrumphát triển, đội chia sẻ trách nhiệm và cùng nhau làm việc hướng đến mỗi Sprint. Do đó, các đội Agile sử dụng các kỹ thuật ước lượng hợp tác để ước lượng khối lượng công việc. Ước lượng hợp tác thường sử dụng Planning Poker như một công cụ, nơi đội chơi một trò chơi ước lượng cùng nhau. Planning Poker được coi là một trong những kỹ thuật hiệu quả và hấp dẫn nhất để ước lượng nỗ lực trong Agilephát triển. Nó bao gồm một tập hợp các số tương tự dãy Fibonacci: 0, 0,5, 1, 2, 3, 5, 8, 20, 40, ?, ∞. Mỗi bộ bài bao gồm bốn bộ các số Fibonacci này, được thiết kế để sử dụng bởi tối đa bốn thành viên đội.
Độ chính xác của ước lượng nhóm so với ước lượng cá nhân
Một nghiên cứu về độ chính xác ước lượng nỗ lực giữa cá nhân và nhóm trong một thí nghiệm dự án phần mềm cho thấy rằng 20 chuyên gia phần mềm từ cùng một công ty đã ước lượng riêng lẻ nỗ lực cần thiết để triển khai cùng một dự án phần mềm. Các người tham gia có nền tảng và vai trò, và dự án phần mềm đã được triển khai trước đó. Sau đó, họ được chia thành năm nhóm. Mỗi nhóm thảo luận và kết hợp kiến thức của mình để thống nhất một ước lượng duy nhất.
Kết quả: Các ước lượng dựa trên thảo luận nhóm chính xác hơn so với ước lượng cá nhân.
Các bước chơi Planning Poker
- Mỗi thành viên đội nhận một bộ bài gồm: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, ?, ∞ — tổng cộng 12 lá bài.
- Người Product Ownerđọc mô tả câu chuyện người dùng hoặc tính năng cho đội.
- Các thành viên đội thảo luận về tính năng và hỏi Product Owner nếu cần thiết.
- Sau khi thảo luận, mỗi thành viên chọn một lá bài đại diện cho ước lượng của mình và công khai cùng lúc.
- Nếu các ước lượng khác nhau đáng kể, đội sẽ thảo luận: Chúng ta có đồng thuận không? Những yếu tố nào đã bị bỏ sót? Người có ước lượng cao nhất hoặc thấp nhất nên giải thích lý do trước khi vòng bỏ phiếu tiếp theo diễn ra.
- Sau khi thảo luận, đội có thể thực hiện thêm một vòng nữa cho đến khi đạt được sự đồng thuận.
- Quay lại bước 2 và bắt đầu ước lượng mục tiếp theo trong danh sách công việc.
Ước lượng kích thước, không phải thời gian — Sử dụng ước lượng tương đối thay vì ước lượng tuyệt đối
Việc ước lượng đơn giản chỉ là một phỏng đoán có căn cứ. Chúng ta sử dụng tất cả kiến thức và kinh nghiệm sẵn có để ước lượng thời gian cần thiết. Thay vì đánh giá từng công việc mới một cách tách biệt, tại sao không so sánh nó với các công việc đã hoàn thành trước đó? Con người giỏi hơn trong việc so sánh các đối tượng có kích thước tương tự thay vì đoán kích thước tuyệt đối.
Ví dụ: Nó có gần giống với món đồ rất nhỏ này không? Hay giống hơn với dự án vừa phải này? Hay thực sự lớn, như dự án chúng ta đã hoàn thành tháng trước? Ước lượng tương đối không chỉ giảm thời gian dành cho việc ước lượng mà còn cải thiện đáng kể độ chính xác.
Não bộ của chúng ta không giỏi trong việc ước lượng tuyệt đối — chúng ta luôn so sánh những thứ mới cần ước lượng với những gì chúng ta đã biết.

Ước lượng Điểm Câu chuyện
Ước lượng Tốc độ — Ghi nhận và tính trung bình Tốc độ Đội trong mỗi Sprint
Tốc độ của đội tốc độ là số lượng điểm câu chuyện mà đội Scrumthực tế hoàn thành trong một Sprint. Tốc độ đội cho bạn biết đội làm việc nhanh đến mức nào. Đối với một dự án hoặc đội mới (không có dữ liệu tốc độ trước đó), chúng ta có thể thực hiện 1–2 Sprint để đo lường và xác lập tốc độ ban đầu. Trong quá trình thực hiện Sprint, chúng ta ghi nhận tốc độ của đội trong mỗi Sprint để lập kế hoạch cho tương lai.

Ước lượng Tốc độ Câu chuyện Người dùng
Chúng tôi ước lượng tổng số điểm câu chuyện trong Danh sách Sản phẩm. Biết được tốc độ trung bình mỗi Sprint, chúng tôi có thể tính toán số Sprint cần thiết để hoàn thành dự án — từ đó ước tính thời gian hoàn thành dự án. Như được hiển thị trong hình bên dưới.

Ước lượng Thời lượng Dự án Scrum