Scrum cơ bản cho engineer (không kịch trình diễn)
Scrum thật sự cần gì - sprint, ceremony, vai trò - lột bỏ kịch của tư vấn. Tối thiểu chạy được cho team 5 engineer và thêm gì khi scale.
Mục lục
Cuốn Scrum Guide chính thức chỉ dài 13 trang, trong khi cả ngành Scrum lại trị giá hàng tỷ đô la, và khoảng trống giữa hai con số đó được lấp đầy bằng kịch của tư vấn. Chương này lột Scrum trở về với những gì một team kỹ thuật thật sự cần - bốn ceremony, ba vai, một timebox - kèm theo template để team có thể áp dụng vào thứ Hai mà không phải mua thêm gì cả.
Khi nào Scrum thật sự hợp với một team?
Có ba tín hiệu chính.
Việc giao tính năng. Khi team đang xây những capability mới có outcome nhìn thấy được, nhịp "ship gì đó sau mỗi hai tuần" của Scrum khớp một cách tự nhiên.
Thành viên team ổn định. Scrum giả định rằng cùng những con người ấy sẽ xuất hiện sprint này qua sprint khác để học được velocity của nhau. Một team có consultant xoay vòng liên tục thường làm tệ hơn với Scrum.
Stakeholder muốn một nhịp dự đoán được. Marketing muốn biết cái gì sẵn sàng vào lúc nào. Cuộc review sprint hai tuần một lần cho họ một bề mặt đều đặn để đặt câu hỏi.
Nếu công việc đến liên tục (ticket support, ops), không dự đoán được (spike nghiên cứu), hoặc chỉ một mình một dự án, thì Kanban hoặc không phương pháp nào cả thường lại tốt hơn Scrum.
Cái giá của việc làm Scrum kém là gì?
Có ba kiểu lỗi thường gặp.
Ceremony hoá thành kịch. Họp planning hai giờ, daily standup một giờ, retro chẳng thay đổi được gì. Team tốn nhiều thời gian nói về công việc hơn là làm việc. Engineer dần dần mất hứng và rút ra khỏi nhịp.
Velocity bị biến thành metric đánh giá hiệu suất. Story point trở thành mục tiêu, team thổi phồng ước lượng để "cải thiện velocity", và con số dần mất ý nghĩa. Quy luật Goodhart sẽ đến chỉ trong một quý.
Sprint goal bị quên. Backlog sprint biến thành một wishlist mà team chọn ngẫu nhiên. Không có goal sprint - chỉ có các item rời rạc - nên việc đạt hay lỡ trở nên tuỳ tiện.
Scrum tối thiểu cho team 5 người trông thế nào?
flowchart LR
Start[Sprint Day 0] --> Plan[Planning<br/>30 phút]
Plan --> Daily[Daily standup<br/>15 phút x 9 ngày]
Daily --> Review[Review<br/>30 phút]
Review --> Retro[Retro<br/>60 phút]
Retro --> Next[Sprint Day 0<br/>sprint kế]
Bốn ceremony trong hai tuần, tổng cộng khoảng 5.5 giờ họp. Nhiều hơn thế là gánh nặng.
- Planning (30 phút): chọn sprint goal, kéo các story vừa đủ vào sprint. Không phân rã ở đây - đó là việc của buổi grooming trước đó.
- Daily standup (15 phút): ba câu hỏi mỗi người - hôm qua, hôm nay, blocker. Đây là buổi sync chứ không phải status report.
- Review (30 phút): demo những gì đã ship cho PO và các stakeholder quan tâm. Không slide; chỉ trình diễn phần mềm đang chạy.
- Retrospective (60 phút): cái gì tốt, cái gì gây đau, một hoặc hai action item cho sprint kế tiếp. Action item được theo dõi cẩn thận.
Vai trò trong phiên bản tối thiểu này: tất cả engineer làm việc engineering; engineer senior hoặc PM xoay nhau làm Scrum Master mỗi sprint; PM (hoặc product owner) định nghĩa sprint goal.
Template sprint planning cụ thể là gì?
Một file markdown cho mỗi sprint, đặt trong repo của team:
# Sprint 2026-12 — 9-20 tháng 6
## Sprint goal
Ship luồng refund đầu cuối để team customer support xử lý refund
không cần engineering vào.
## Backlog sprint
| Story | Owner | Ước lượng | Trạng thái |
|-------|-------|-----------|------------|
| Nút refund trên trang chi tiết đơn | Alice | 3 pts | Xong |
| API refund với idempotency | Bob | 5 pts | Đang làm |
| Tích hợp Stripe refund | Bob | 3 pts | Chưa làm |
| Template email refund | Carol | 2 pts | Chưa làm |
| Audit log refund | Alice | 2 pts | Chưa làm |
| **Tổng** | | **15 pts** | |
## Capacity
- Alice: 8 ngày sẵn (2 ngày OOO)
- Bob: 10 ngày sẵn
- Carol: 9 ngày (1 ngày event công ty)
- Velocity 3 sprint cuối: 14, 16, 13 pts
## Rủi ro sprint này
- Stripe sandbox flaky tuần trước — Bob xác nhận trước Day 2
## Ngoài sprint (hoãn)
- Tool refund hàng loạt (đẩy sang Should; sprint kế)
- Dashboard analytics refund (Could; cuối quý)
Có hai chi tiết đáng chú ý. Một là capacity được tính bằng ngày chứ không phải story point - story point là ước lượng khối lượng việc, còn ngày là ràng buộc thời gian. Hai là mục "rủi ro sprint này" chỉ là một section ngắn 2 dòng để flag những gì có thể trật - và nó link sang RAID log của dự án.
Scrum ở quy mô đa team trông thế nào?
Câu trả lời không phải là SAFe. Phần lớn team áp dụng các scaled Agile framework cuối cùng đều tự chôn mình trong quy trình. Câu trả lời đơn giản hơn nhiều:
flowchart TB
Team1[Team A<br/>sprint 2 tuần] --> Demo[Demo chung<br/>mỗi 2 tuần]
Team2[Team B<br/>sprint 2 tuần] --> Demo
Team3[Team C<br/>sprint 2 tuần] --> Demo
Demo --> Roadmap[Roadmap quý<br/>đặt mục tiêu]
Roadmap --> Team1
Roadmap --> Team2
Roadmap --> Team3
Mỗi team chạy Scrum của riêng mình; các sprint khớp ngày bắt đầu với nhau giữa các team; có một buổi review demo chung vào cuối mỗi sprint; và roadmap quý đặt ra mục tiêu để mỗi team mang về planning của mình. Ba team chỉ tốn 30 phút sync xuyên team mỗi sprint, không phải cả một nghi lễ PI-planning kéo dài nhiều ngày kiểu SAFe.
Scrum có thể tự tạo ra những lỗi nào?
Có năm kiểu lỗi thường gặp:
- Gaming velocity. Ước lượng phồng dần lên theo thời gian. Cách phòng: theo dõi velocity nhưng không bao giờ đặt làm target; thay vào đó hãy thưởng cho việc đạt sprint goal.
- Standup biến thành status report. Engineer báo cáo cho PM một cách cá nhân. Cách phòng: PM không chủ trì standup; engineer nói chuyện với nhau, còn PM thì nghe.
- Action item từ retro rớt mất. Retro lộ ra vấn đề, action item được gán, nhưng đến retro kế chẳng có gì thay đổi. Cách phòng: theo dõi action item trong một file nhỏ và check lại ở đầu retro kế; cap ở 2 action item mỗi sprint.
- PO/PM tách rời team. Khi PO không nằm trong nhịp ngày của team, sprint goal sẽ trôi khỏi ưu tiên sản phẩm. Cách phòng: PO tham gia cả planning và review; chương stakeholder sẽ nói về nhịp này.
- Sprint goal là một wishlist. Khi có nhiều goal trong một sprint, đảm bảo sẽ lỡ. Cách phòng: một câu, một outcome, vừa đủ để viết lên bảng standup.
Khi nào Scrum là lựa chọn sai?
Có ba trường hợp.
Việc continuous-flow. Support, ca on-call, team platform mà việc đến không dự đoán được. Hãy dùng Kanban thay vào đó.
Dự án đang khủng hoảng. Khi dự án đang cháy (xem case study cứu), việc chạy đầy đủ ceremony là xa xỉ. Hãy thoát khủng hoảng trước, rồi mới quay lại Scrum.
Việc làm một mình. Một engineer làm một dự án không cần Scrum. Buổi check-in tuần với manager cộng một bảng kanban cá nhân là đã đủ.
Đi tiếp từ đây như thế nào?
Chương tiếp theo: Kanban flow - phương pháp thay thế cho công việc liên tục. Sau đó, chọn phương pháp sẽ khép lại phần methodology bằng cách giúp bạn quyết định khi nào nên dùng cái nào.