Sprint
Khoảng thời gian cố định (2-4 tuần) trong Scrum để hoàn thành một tập công việc đã cam kết.
Định nghĩa
Hỏi mười người trong team thì mười người trả lời được: một khoảng thời gian cố định, thường 1 đến 4 tuần, hết kỳ thì có một phần sản phẩm dùng được. Chỗ hay bị bỏ qua nằm ở cách Scrum Guide 2020 xếp chỗ cho nó: Planning, Daily, Review, Retrospective đều nằm bên trong Sprint. Sprint là cái hộp chứa chúng, chứ đứng ngang hàng thì sai.
Sprint là nhịp cố định của Scrum, tối đa một tháng, bên trong chứa Planning, Daily, Review và Retrospective, và Sprint mới bắt đầu ngay khi Sprint cũ kết thúc.
Những gì Scrum Guide 2020 nói rõ
- Độ dài cố định, tối đa một tháng. Cố định là điểm mấu chốt: nhịp đều thì dữ liệu velocity mới có nghĩa, và team mới dự đoán được. Ngắn hơn thì vòng phản hồi nhanh hơn nhưng chi phí ceremony trên mỗi sprint tăng.
- Không có khoảng nghỉ giữa hai Sprint. Sprint mới bắt đầu ngay sau khi Sprint cũ kết thúc. Cái kiểu "tuần đệm để dọn dẹp và fix bug" mà nhiều team VN vẫn chèn vào không có trong Scrum — nó là dấu hiệu Definition of Done đang quá lỏng.
- Sprint Goal không đổi giữa chừng. Phạm vi thì có thể thương lượng lại giữa Product Owner và Developers khi hiểu biết thay đổi; nhưng mục tiêu thì giữ nguyên. Đây là chỗ ranh giới hay bị nhầm: bỏ bớt một story để kịp Goal là hợp lệ, đổi luôn Goal sang việc khác thì không.
- Chất lượng không bị hạ. Không có chuyện "sprint này gấp nên bỏ test".
- Chỉ Product Owner có quyền huỷ Sprint. Không phải Scrum Master, không phải sếp, không phải khách hàng. Và lý do hợp lệ duy nhất là Sprint Goal đã trở nên vô nghĩa — ví dụ sản phẩm bị đổi hướng, hoặc thị trường thay đổi khiến tính năng đang làm không còn ai cần. Huỷ Sprint là chuyện rất hiếm; nếu năm nào cũng huỷ vài lần thì vấn đề nằm ở cách lập kế hoạch chứ không ở thị trường.
Bên trong một Sprint có gì
| Event | Timebox cho Sprint 2 tuần | Ai bắt buộc có mặt |
|---|---|---|
| Sprint Planning | tối đa 4 giờ | Cả Scrum Team |
| Daily Scrum | 15 phút mỗi ngày | Developers |
| Sprint Review | tối đa 2 giờ | Scrum Team + stakeholder |
| Sprint Retrospective | tối đa 1,5 giờ | Cả Scrum Team |
Timebox trong Scrum Guide tính theo Sprint một tháng (Planning 8 giờ, Review 4 giờ, Retro 3 giờ) rồi rút tỷ lệ cho Sprint ngắn hơn. Con số là trần chứ không phải chỉ tiêu — Planning xong sớm 40 phút là chuyện tốt. Buổi đó trả lời ba câu: vì sao Sprint này đáng làm (Sprint Goal), làm được gì, làm bằng cách nào. Sprint Backlog là sản phẩm của buổi đó, và nó thuộc về Developers, không phải PO hay sếp.
Ví dụ thực tế
Đến ngày thứ 6, một dev nhắn vào nhóm chat: chia hoá đơn theo từng người phải đổi mô hình dữ liệu thanh toán, đội thêm chừng 8 điểm. Team 7 người, app giao đồ ăn cho một chuỗi 58 cửa hàng, Sprint 2 tuần, velocity quanh 34 điểm, Sprint Goal đang treo trên bảng là "Khách đặt được đơn nhóm cho văn phòng và thanh toán một lần."
Cách xử lý đúng: PO và Developers ngồi lại, bỏ story "lưu nhóm đặt hàng thường xuyên" (5 điểm) và "nhắc lịch đặt cơm hằng ngày" (3 điểm) ra khỏi Sprint. Goal giữ nguyên, hai story kia quay về Product Backlog.
Cách xử lý sai mà mình thấy khá nhiều: giám đốc kinh doanh nhảy vào giữa Sprint đòi chèn tính năng mã khuyến mãi cho chiến dịch cuối tháng, Scrum Master gật. Sprint đó kết thúc với 6 story dở dang, không demo được gì, Goal đi đâu mất. Nếu chiến dịch khẩn tới mức đó, câu trả lời đúng là để PO cân nhắc huỷ Sprint hoặc xếp nó vào Sprint kế, chứ không nhét thêm.
Lỗi hay gặp
- Đổi độ dài Sprint liên tục cho "vừa khối lượng công việc". Mọi số liệu lịch sử mất giá trị.
- Sprint không có Goal, chỉ là một rổ ticket rời rạc. Không Goal thì không có cơ sở thương lượng phạm vi, và Review biến thành buổi đọc báo cáo.
- Coi Sprint là hạn chót giao hàng. Sprint là nhịp kiểm tra và thích nghi; release có thể nhiều lần trong Sprint, hoặc vài Sprint mới một lần.
- Nhận đủ 100% capacity. Luôn chừa chỗ cho hỗ trợ production và việc bất ngờ, nhiều team để 15–20%.
- Retro tổ chức cho có. Không ra được ít nhất một hành động có người chịu trách nhiệm thì bỏ 90 phút đó đi làm việc khác còn hơn.
Câu hay bị hỏi phỏng vấn
"Giữa Sprint khách đòi thêm việc gấp, bạn xử lý sao?" Câu trả lời đầy đủ có ba tầng: kiểm tra việc đó có phục vụ Sprint Goal không; nếu không thì thương lượng đánh đổi với PO để đưa vào và bỏ ra thứ tương đương; nếu nó khiến Goal mất ý nghĩa hoàn toàn thì đó là tình huống duy nhất PO cân nhắc huỷ Sprint. Nhớ nói rõ quyền huỷ thuộc về PO — người phỏng vấn thường chờ đúng chi tiết đó.
Liên quan
Chia sẻ
Thông tin
- Danh mục
- 🔄 Agile & Scrum
- Cập nhật
- 17/12/2025
Đóng góp bởi
Phan Minh Hoàng