Hỏi mười công ty có "làm Scrum" không, cả mười sẽ gật. Nhìn cách họ làm việc thực tế, bạn sẽ thấy mười kiểu khác nhau. Điều đó không hẳn sai — Agile vốn sinh ra để được điều chỉnh — nhưng nó tạo một vấn đề âm thầm: mọi người dùng cùng một từ nhưng hiểu khác nhau, và một đội không thể chạy tốt khi "story", "done", hay "3 point" lại mang ý nghĩa khác nhau với từng người trong phòng.
Bài viết này sửa điều đó. Nó là một mô hình tư duy chung, thực tế cho mọi vai trò trong team phần mềm — BA, PO, PM, lập trình viên, QC, designer, người mới — giải thích từng thành phần thực sự nghĩa là gì, chuẩn vận hành ra sao, các đội thường biến tấu thế nào, và làm sao để vận hành tốt. Đọc một lần là bạn hiểu được cái board, các buổi họp, cách estimate và các biểu đồ — đủ để đóng góp ngay từ ngày đầu.
Agile là một tư duy — một bộ giá trị (phần mềm chạy được hơn tài liệu, thích ứng với thay đổi hơn bám kế hoạch, con người hơn quy trình). Scrum là một khung (framework) cụ thể để làm Agile, với vai trò, sự kiện và artifact được định nghĩa rõ. Bạn có thể Agile mà không Scrum; cũng có thể "làm Scrum" một cách máy móc mà chẳng hề Agile. Phần lớn công ty chạy một Scrum đã tùy biến, đôi khi gọi là "Scrum-but" ("bọn mình làm Scrum, nhưng bỏ retro…"). Có biến tấu lành mạnh, có biến tấu âm thầm phá vỡ hệ thống. Bài này sẽ chỉ rõ cái nào là cái nào.
Cấu trúc công việc: epic, story, task, sub-task
Mọi thứ trên board đều là một "work item", và chúng lồng nhau từ lớn tới nhỏ. Tên gọi tùy công cụ (Jira, Azure DevOps, Linear), nhưng ý tưởng là chung:
| Cấp | Là gì | Kích cỡ điển hình |
|---|---|---|
| Initiative / Theme | Mục tiêu kinh doanh lớn, trải nhiều quý (tùy chọn, cấp cao nhất) | Nhiều tháng |
| Epic | Một khối giá trị lớn, quá to cho một sprint — một mảng tính năng | Vài tuần / vài sprint |
| User Story | Một lát giá trị nhỏ nhìn từ góc người dùng; gọn trong một sprint | Vài giờ tới vài ngày |
| Task | Một đơn vị công việc cần để hoàn thành story (thường mang tính kỹ thuật) | Vài giờ |
| Sub-task | Chia nhỏ task hơn nữa, để rõ ràng hoặc chia cho nhiều người | ≤ vài giờ |
Hai loại item nữa bạn sẽ gặp ở khắp nơi:
- Bug — thứ không chạy đúng như mong đợi. Được ước lượng và ưu tiên như các công việc khác.
- Spike — một item nghiên cứu/khảo sát có giới hạn thời gian, dùng khi bạn chưa đủ hiểu để ước lượng phần việc thật.
Story là đơn vị giá trị (mang lại thứ người dùng/stakeholder quan tâm); task là đơn vị công việc (cách team xây nó). Nếu một "story" không có giá trị với người dùng và thuần kỹ thuật, nó thường là task. Nếu một "epic" có thể xong trong một sprint, nó thường là story. Giữ các cấp này trung thực mới làm cái board dễ đọc.
User story: cú pháp, INVEST và acceptance criteria
User story không phải bản spec thu nhỏ — nó là lời hứa về một cuộc trao đổi, gói trong một cú pháp đơn giản, dễ hiểu:
Là một [loại người dùng], tôi muốn [một khả năng], để [một lợi ích].
Ví dụ: "Là một khách quay lại, tôi muốn lưu giỏ hàng, để có thể hoàn tất thanh toán sau."
Một story tốt theo nguyên tắc INVEST: Independent (độc lập), Negotiable (thương lượng được), Valuable (có giá trị), Estimable (ước lượng được), Small (nhỏ), Testable (kiểm thử được). Và nó mang theo acceptance criteria — các điều kiện cụ thể để "đúng là xong", viết sao cho QC và PO kiểm chứng được:
- Acceptance criteria trả lời "làm sao biết story này chạy đúng?" — thường là checklist hoặc theo dạng Given / When / Then. Đây là bản hợp đồng của story.
- Definition of Ready (DoR) — mức một story phải đạt trước khi team cam kết làm (rõ ràng, đã estimate, có acceptance criteria, biết phụ thuộc).
- Definition of Done (DoD) — mức áp dụng cho mọi story (đã code, review, test, merge, tài liệu…). DoD là quy ước chung toàn team và không nhân nhượng; nó là tấm khiên tốt nhất chống lại cảnh "xong… mà chưa thật xong".
Status workflow: board thực sự dịch chuyển ra sao
Các cột trên board chính là quy trình thật của team được phơi bày. Một luồng phổ biến:
| Trạng thái | Nghĩa là | Ai chuyển |
|---|---|---|
| Backlog | Đã ghi nhận, chưa đưa vào sprint nào | PO |
| To Do | Đã cam kết cho sprint này, chưa bắt đầu | Team |
| In Progress | Đang làm | Người nhận |
| In Review / Code Review | Đã làm xong, chờ review | Người làm → Reviewer |
| In Testing / QA | Đã review, đang kiểm chứng theo acceptance criteria | QC |
| Done | Đạt Definition of Done | QC / PO |
Cập nhật trạng thái theo thời gian thực — một board chỉ đúng vào lúc standup là board không ai tin. Và tôn trọng WIP limit (giới hạn việc đang làm dở): càng ít item "In Progress" cùng lúc thì mọi thứ về Done càng nhanh. Bắt đầu tất cả thì chẳng xong gì cả; mục tiêu là ngừng bắt đầu, bắt đầu hoàn thành.
Story point & estimate: ý tưởng bị lạm dụng nhiều nhất trong Scrum
Story point ước lượng kích cỡ tương đối của công việc — gồm cả công sức, độ phức tạp và độ bất định — chứ không phải số giờ. Team chọn một story nhỏ làm mốc tham chiếu ("cái này là 2") rồi đo mọi thứ so với nó, thường trên thang kiểu Fibonacci (1, 2, 3, 5, 8, 13).
Vì sao dùng point tương đối thay vì giờ? Vì con người ước lượng thời gian tuyệt đối rất tệ nhưng so sánh rất giỏi ("cái này gấp đôi cái kia"). Point cũng ổn định khi người ta làm nhanh hơn, và cho phép team đo velocity — số point hoàn thành mỗi sprint — để dự báo thực tế.
Cả team cùng ước lượng: mỗi người chọn một con số riêng, lật cùng lúc, người chọn cao nhất và thấp nhất giải thích lý do. Chính cuộc thảo luận — chứ không phải con số — mới là giá trị thật; nó phơi ra độ phức tạp ẩn và tạo hiểu biết chung. Bỏ phiếu lại tới khi đủ gần. Một story lớn hơn ~13 thì nên được chẻ nhỏ, đừng estimate.
1. Coi point là giờ ("1 point = 1 ngày") — vứt bỏ toàn bộ ưu điểm của point. 2. Dùng velocity làm thước đo hiệu suất hoặc so sánh giữa các team — chắc chắn dẫn tới lạm phát point và những con số bị "chế". 3. Estimate để cam kết-rồi-trừng-phạt thay vì để lập kế hoạch. Point là công cụ lập kế hoạch của team, không phải điểm năng suất cho cấp trên. Khoảnh khắc nó trở thành chỉ tiêu là lúc nó hết hữu ích.
Estimate thời gian & log work — một cách trung thực
Nhiều team (nhất là nơi báo cáo cho khách hàng hoặc kế toán) còn theo dõi cả thời gian bên cạnh point. Làm tốt thì nó giúp dự báo và bảo vệ team; làm dở thì thành giám sát và làm hỏng dữ liệu. Phiên bản trung thực:
- Original Estimate — ước lượng thời gian ban đầu tốt nhất cho một task. Đặt một lần, đừng "sửa" liên tục cho ra vẻ chính xác.
- Time Logged / Work Logged — thời gian thực đã bỏ ra, ghi ngay khi làm (không phải nhớ lại vào cuối tuần).
- Remaining — thời gian còn lại một cách trung thực; đây là thứ nuôi biểu đồ burndown.
Log thời gian để hiểu luồng công việc và cải thiện ước lượng, không bao giờ để xếp hạng con người. Estimate ở cấp task (giờ), size ở cấp story (point) — chúng phục vụ mục đích khác nhau. Và hãy nói thật: một dòng log "8h" mà thực ra là 3h làm việc và 5h họp thì chẳng dạy được team điều gì. Dữ liệu chỉ hữu ích khi nó trung thực, và chỉ trung thực khi người ta thấy an toàn để trung thực.
Các buổi họp (ceremony): mỗi buổi để làm gì
Các sự kiện trong Scrum không phải họp cho có — mỗi buổi có một nhiệm vụ duy nhất. Chạy đúng tinh thần đó thì vô giá; chạy theo quán tính thì thành buổi họp ai cũng ngán.
| Sự kiện | Nhiệm vụ duy nhất | Timebox |
|---|---|---|
| Sprint Planning | Thống nhất sprint này team sẽ giao gì, và kế hoạch sơ bộ để làm | ~2h cho mỗi tuần sprint |
| Daily Standup | Team đồng bộ lại và nêu blocker cho ngày hôm đó — không phải báo cáo cho sếp | ≤ 15 phút |
| Backlog Refinement | Làm rõ, chẻ nhỏ và estimate các story sắp tới để planning trơn tru | ~1h / sprint, liên tục |
| Sprint Review / Demo | Trình diễn phần mềm chạy được cho stakeholder và thu phản hồi | ~1h cho mỗi tuần sprint |
| Retrospective | Team cải thiện cách mình làm việc — giữ gì, bỏ gì, thử gì | ~1–1.5h / sprint |
Ba câu hỏi kinh điển — hôm qua làm gì, hôm nay làm gì, có vướng gì — là điểm khởi đầu, không phải bài kinh để đọc thuộc. Team giỏi thường "đi dọc board" từ phải sang trái (ưu tiên item gần Done nhất) và nói về công việc, không phải về từng người. Nếu hai người cần bàn sâu, hãy để ra ngoài ("để lát nữa nói riêng"). Đây là buổi đồng bộ, không phải buổi giải quyết mọi thứ.
Retrospective là động cơ của "cải tiến liên tục" — nó là buổi họp làm cho mọi buổi họp khác tốt lên. Bỏ nó (kiểu "Scrum-but" phổ biến nhất) nghĩa là team lặp lại cùng những sai lầm mãi mãi. Hãy giữ nó an toàn, không đổ lỗi, và kết thúc bằng 1–2 hành động cụ thể có người phụ trách, đừng là một danh sách ước muốn dài mà chẳng ai làm.
Các biểu đồ: chúng thực sự nói lên điều gì
Biểu đồ Agile là dụng cụ phản hồi, không phải bảng điểm. Hãy đọc chúng như những câu hỏi để đặt ra, không phải bản án để tuyên.
| Biểu đồ | Cho thấy gì / cần để ý gì |
|---|---|
| Sprint Burndown | Công việc còn lại theo thời gian còn lại của sprint. Đường nằm ngang nghĩa là việc không về được Done; rơi thẳng đứng cuối sprint nghĩa là trạng thái không cập nhật theo thời gian thực. |
| Burnup | Công việc đã hoàn thành so với tổng phạm vi. Điểm mạnh: làm lộ scope creep (đường trần dâng lên giữa sprint). |
| Velocity chart | Số point hoàn thành mỗi sprint theo thời gian. Dùng để dự báo và nhận ra xu hướng — đừng bao giờ để so sánh team hay làm chỉ tiêu. |
| Cumulative Flow (CFD) | Số item ở mỗi trạng thái theo thời gian. Dải phình to để lộ nút thắt (ví dụ cột "In Review" cứ dày lên). |
Khoảnh khắc một biểu đồ bị dùng để đánh giá cá nhân, team sẽ tối ưu cái biểu đồ thay vì công việc — độn estimate, "chế" trạng thái, giấu vấn đề. Team lành mạnh dùng biểu đồ để tìm chỗ quy trình đang đau, cùng nhau sửa, rồi đi tiếp.
Ai làm gì: ba vai trò Scrum (và BA/QC nằm ở đâu)
| Vai trò | Sở hữu |
|---|---|
| Product Owner | Phần làm gì và vì sao: backlog, ưu tiên, giá trị, nghiệm thu. Tối đa hóa kết quả. |
| Scrum Master | Phần cách-team-làm-việc: điều phối các buổi họp, gỡ blocker, huấn luyện quy trình. Là người phục vụ-dẫn dắt, không phải sếp. |
| Developers (Dev Team) | Phần làm như thế nào: tự tổ chức, đa năng, sở hữu việc xây và Definition of Done. Trong Scrum hiện đại, "Developers" gồm kỹ sư, QC, designer — mọi người cùng tạo ra increment. |
BA và QC thường nằm trong đội phát triển: BA cùng PO mài sắc story và acceptance criteria; QC định nghĩa và kiểm chứng chất lượng. Project Manager, nếu tồn tại song song với Scrum, thường lo ngân sách, stakeholder và phụ thuộc bên ngoài sprint — không phải việc định hướng team hằng ngày.
Cái gì là chuẩn, công ty biến tấu gì, và cái gì thật sự phá hỏng nó
Không đội thực tế nào chạy Scrum đúng sách giáo khoa, và điều đó ổn. Kỹ năng nằm ở chỗ biết biến tấu nào lành mạnh, biến tấu nào âm thầm gỡ bỏ chính thứ làm nó hiệu quả.
| Biến tấu lành mạnh ✅ | Biến tấu phá hỏng ❌ |
|---|---|
| Thêm cột board (In Review, QA) cho khớp luồng thực tế | Bỏ retro — team ngừng cải thiện |
| Trộn Scrum + Kanban ("Scrumban") cho việc thiên về luồng | Standup biến thành báo cáo trạng thái cho sếp |
| Chọn độ dài sprint phù hợp (1–3 tuần) với team | Dùng velocity / point để xếp hạng hay so sánh người |
| Theo dõi thời gian khi nghiệp vụ thật sự cần | Đổi phạm vi sprint giữa chừng theo ngẫu hứng |
| Công cụ gọn nhẹ phù hợp với team | PO không sẵn sàng để trả lời câu hỏi |
Scrum làm theo hộp thời gian cố định (sprint) với phạm vi đã cam kết — hợp cho việc làm sản phẩm có nhịp kế hoạch. Kanban là luồng liên tục với WIP limit, không có sprint — hợp cho support, vận hành, việc khó đoán. Scrumban pha trộn cả hai. Hãy chọn cái khớp với cách công việc thực sự ập đến, không phải cái đang "thời thượng".
Những điều đọng lại
- Agile là tư duy; Scrum là một framework. Phần lớn team chạy bản tùy biến — điều đó ổn, miễn là mọi người chia sẻ cùng định nghĩa.
- Cấu trúc: Epic (vài tuần) → Story (một lát giá trị người dùng, một sprint) → Task (đơn vị công việc) → Sub-task. Story = giá trị, task = công việc.
- Story dùng "Là một… tôi muốn… để…", theo INVEST, và sống còn nhờ acceptance criteria rõ ràng cùng một Definition of Done chung toàn team.
- Story point là kích cỡ tương đối, không phải giờ. Estimate cùng nhau (Planning Poker); đừng bao giờ dùng velocity để xếp hạng người.
- Log work một cách trung thực để cải thiện estimate và luồng — không phải để giám sát. Task tính giờ, story tính point.
- Mỗi buổi họp có một nhiệm vụ: lập kế hoạch (planning), đồng bộ (daily), làm rõ (refinement), trình diễn (review), cải thiện (retro). Đừng bao giờ bỏ retro.
- Biểu đồ đo hệ thống, không đo người. Burndown, burnup, velocity, CFD ở đó để tìm chỗ quy trình đang đau.
- Biến tấu khôn ngoan: khớp framework với cách công việc ập đến — và giữ những phần (DoD, retro, một PO sẵn sàng) làm nó thật sự hiệu quả.
Bạn không cần là một Scrum Master có chứng chỉ để làm việc tốt trong một team Agile — bạn cần một hiểu biết chung, trung thực về việc các từ ngữ nghĩa là gì và mỗi nghi thức để làm gì. Khi cả team đọc board theo cùng một cách, estimate vì cùng những lý do, và xem các buổi họp là công cụ chứ không phải nghĩa vụ, thì quy trình lùi về hậu cảnh và công việc trôi chảy. Đó mới là mục tiêu thật của tất cả những điều này: không phải "làm Scrum cho đúng", mà là cùng nhau xây phần mềm tốt một cách bền vững — và mỗi sprint lại khá hơn một chút.