Trả lời nhanh: Scrum là một khung làm việc (framework) gọn nhẹ giúp đội nhóm tạo ra giá trị cho những vấn đề phức tạp bằng các vòng lặp ngắn gọi là sprint, mỗi sprint tối đa một tháng. Theo Scrum Guide 2020, Scrum gồm 3 trách nhiệm, 5 sự kiện, 3 tạo phẩm gắn với 3 cam kết và 5 giá trị.
Điểm chính
- Scrum Guide 2020 của Ken Schwaber và Jeff Sutherland là định nghĩa chính thức của Scrum. Áp dụng một phần vẫn được, nhưng kết quả không còn là Scrum.
- Đội Scrum thường từ 10 người trở xuống, gồm ba trách nhiệm: Product Owner, Scrum Master và Developers, không có đội con hay cấp bậc.
- Năm sự kiện: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. Ba tạo phẩm: Product Backlog, Sprint Backlog, Increment.
- Mỗi tạo phẩm có một cam kết: Product Goal, Sprint Goal, Definition of Done. Đây là điểm mới của bản 2020 mà nhiều tài liệu tiếng Việt còn bỏ sót.
- Scrum hợp với việc phức tạp, cần thử và học nhanh. Việc đến liên tục, khó gom thành chu kỳ thì Kanban thường hợp hơn.
Mục lục
- Scrum là gì?
- Scrum dựa trên nền tảng lý thuyết nào?
- Mô hình Scrum gồm những thành phần nào?
- Đội Scrum gồm những ai?
- Sprint là gì?
- Các sự kiện Scrum diễn ra thế nào?
- Ba tạo phẩm và ba cam kết trong Scrum là gì?
- Quy trình Scrum trong một sprint diễn ra như thế nào?
- Scrum và Kanban khác nhau thế nào?
- Khi nào nên và không nên dùng Scrum?
- Bắt đầu áp dụng Scrum trong doanh nghiệp Việt Nam thế nào?
- Những sai lầm phổ biến khi làm Scrum
- Câu hỏi thường gặp
Scrum là gì?
Theo Scrum Guide 2020, Scrum là một khung làm việc gọn nhẹ giúp con người, đội nhóm và tổ chức tạo ra giá trị thông qua các giải pháp thích ứng cho những vấn đề phức tạp. Tài liệu này do hai người đồng sáng lập Scrum là Ken Schwaber và Jeff Sutherland viết và duy trì.
Nói đơn giản, thay vì lập kế hoạch cho cả dự án rồi làm một mạch, đội Scrum chia công việc thành các sprint có độ dài cố định, tối đa một tháng. Mỗi sprint tạo ra ít nhất một phần sản phẩm dùng được. Cuối sprint, đội cùng người liên quan xem kết quả thật rồi quyết định làm gì tiếp.
- Scrum là khung, không phải quy trình chi tiết. Scrum Guide chỉ khoảng 13 trang, quy định “luật chơi” tối thiểu. Cách viết yêu cầu, cách ước lượng, công cụ quản lý do đội tự chọn.
- Scrum là một khối thống nhất. Scrum Guide viết rõ khung Scrum là bất biến; áp dụng một phần là có thể, nhưng kết quả không phải là Scrum. Bỏ Retrospective hay bỏ Product Owner mà vẫn gọi là “làm Scrum” là hiểu sai.
- Scrum không chỉ dành cho phần mềm. Scrum Guide ghi nhận Scrum đã lan ra nhiều lĩnh vực có công việc phức tạp. Chữ Developers vì vậy chỉ “người làm ra sản phẩm”, có thể là nhà phân tích, nhà nghiên cứu hay người làm nội dung.
Scrum và Agile liên quan thế nào?
Agile là tư duy được viết thành Tuyên ngôn Agile năm 2001 với 4 giá trị và 12 nguyên tắc. Scrum là một khung cụ thể để thực hiện tư duy đó. Theo bài tổng kết của Scrum.org về 17 kỳ báo cáo State of Agile do Digital.ai thực hiện, Scrum luôn là khung được dùng nhiều nhất qua mọi kỳ. Phần nền tảng, bạn có thể xem bài giải thích tư duy Agile và so sánh với Waterfall; bài này đi sâu riêng vào Scrum.
Tên gọi và lịch sử Scrum
“Scrum” là thuật ngữ bóng bầu dục (rugby), chỉ đội hình cả đội chụm lại giành bóng. Hình ảnh này xuất hiện trong bài “The New New Product Development Game” của Hirotaka Takeuchi và Ikujiro Nonaka trên Harvard Business Review tháng 1/1986: phát triển sản phẩm hiệu quả giống rugby, bóng được chuyền trong đội khi cả đội tiến lên như một khối, thay vì chuyển giao tuần tự từng khâu.
- Đầu thập niên 1990: Schwaber và Sutherland phát triển Scrum; năm 1995 lần đầu cùng trình bày tại hội nghị OOPSLA.
- 2010: bản Scrum Guide đầu tiên; cập nhật vào các năm 2011, 2013, 2016, 2017 và 2020.
- Tháng 11/2020: bản hiện hành. Đến tháng 10/2026 đây vẫn là bản chính thức, có bản dịch tiếng Việt do cộng đồng thực hiện trên scrumguides.org.
- Tháng 6/2025: Jeff Sutherland cùng Ralph Jocham và John Coleman công bố Scrum Guide Expansion Pack, là tài liệu bổ sung đi kèm, không thay thế Scrum Guide 2020.
Scrum Guide 2020 khác bản 2017 ở đâu?
Nhiều bài tiếng Việt vẫn dùng khái niệm cũ như “Development Team” hay “ba câu hỏi Daily Scrum”. Theo trang ghi nhận thay đổi của scrumguides.org, bản 2020 có các điểm mới:
| Nội dung | Bản 2017 | Bản 2020 |
|---|---|---|
| Cấu trúc đội | Có Development Team, như đội trong đội | Một Scrum Team với ba trách nhiệm |
| Mục tiêu dài hạn | Chưa có | Thêm Product Goal |
| Cam kết | Chưa gắn với tạo phẩm | Product Goal, Sprint Goal, Definition of Done |
| Cách tổ chức đội | Tự tổ chức (self-organizing) | Tự quản (self-managing): tự quyết cả làm việc gì |
| Sprint Planning | Làm gì, làm thế nào | Thêm “vì sao sprint này có giá trị” |
| Daily Scrum | Gợi ý ba câu hỏi | Bỏ ba câu hỏi, đội tự chọn cấu trúc |
Scrum dựa trên nền tảng lý thuyết nào?
Scrum dựa trên thuyết thực nghiệm (empiricism): hiểu biết đến từ trải nghiệm, quyết định dựa trên điều quan sát được. Scrum cũng dựa trên tư duy tinh gọn, tức giảm lãng phí và tập trung vào điều thiết yếu, xem thêm phương pháp Lean. Từ đó có ba trụ cột:
- Minh bạch (transparency): quy trình và kết quả hiển thị cho cả người làm lẫn người nhận.
- Kiểm tra (inspection): thường xuyên soi tạo phẩm và tiến độ để phát hiện sai lệch sớm.
- Thích ứng (adaptation): thấy lệch thì điều chỉnh sớm nhất có thể. Scrum Guide nhấn mạnh: kiểm tra mà không thích ứng là vô nghĩa.
5 giá trị của Scrum
| Giá trị | Nghĩa trong Scrum | Dấu hiệu đội đang thiếu |
|---|---|---|
| Cam kết (commitment) | Cùng cam kết đạt mục tiêu, hỗ trợ nhau | “Phần tôi xong rồi”, mặc kệ Sprint Goal |
| Tập trung (focus) | Dồn sức vào việc của sprint | Bị kéo sang việc ngoài sprint mỗi ngày |
| Cởi mở (openness) | Công khai công việc và khó khăn | Không ai dám nói mình đang bị tắc |
| Tôn trọng (respect) | Tin nhau là người có năng lực, độc lập | Quản lý chỉ định từng đầu việc |
| Can đảm (courage) | Dám làm điều đúng, xử lý vấn đề khó | Biết sprint trượt mục tiêu nhưng im lặng |
Mô hình Scrum gồm những thành phần nào?
Nhiều người nhớ mô hình Scrum bằng công thức “3-5-3”: 3 trách nhiệm, 5 sự kiện, 3 tạo phẩm. Đây là cách nhớ, không phải thuật ngữ của Scrum Guide. Với bản 2020, bạn nên nhớ thêm 3 cam kết gắn với 3 tạo phẩm.
Đội Scrum gồm những ai?
Scrum Team gồm một Scrum Master, một Product Owner và các Developers. Theo Scrum Guide, đội thường từ 10 người trở xuống, liên chức năng (có đủ kỹ năng tạo ra giá trị mỗi sprint) và tự quản (tự quyết ai làm gì, khi nào, thế nào). Đội quá lớn nên tách thành nhiều Scrum Team cùng làm một sản phẩm, dùng chung Product Goal, Product Backlog và Product Owner.
Bản 2020 dùng từ “trách nhiệm” (accountability) thay cho “vai trò”. Đây không phải chức danh trong sơ đồ tổ chức: một trưởng phòng có thể giữ trách nhiệm Product Owner, một kỹ sư có thể vừa là Developer vừa làm Scrum Master.
Product Owner là gì?
Product Owner (PO) chịu trách nhiệm tối đa hoá giá trị của sản phẩm do Scrum Team làm ra, thông qua quản lý Product Backlog: xây dựng và truyền đạt Product Goal, tạo và mô tả rõ hạng mục backlog, sắp xếp thứ tự, bảo đảm backlog minh bạch và dễ hiểu. PO có thể giao việc cho người khác nhưng vẫn chịu trách nhiệm.
PO là một người, không phải một hội đồng. Scrum Guide viết: để PO thành công, cả tổ chức phải tôn trọng quyết định của họ; ai muốn thay đổi Product Backlog thì phải thuyết phục PO.
Ở nhiều doanh nghiệp, PO chỉ là người “chép yêu cầu” từ ban giám đốc, không được quyết thứ tự ưu tiên. Khi đó đội nhận yêu cầu đổi liên tục từ nhiều phía mà không ai chốt, và Scrum gần như chắc chắn thất bại.
Scrum Master là gì?
Scrum Master (SM) chịu trách nhiệm triển khai Scrum đúng như Scrum Guide và chịu trách nhiệm về hiệu quả của Scrum Team. Scrum Guide gọi SM là người lãnh đạo thực thụ, phục vụ đội và tổ chức:
| Phục vụ ai | Việc cụ thể theo Scrum Guide 2020 |
|---|---|
| Scrum Team | Huấn luyện tự quản, liên chức năng; giúp đội tạo Increment đạt Definition of Done; thúc đẩy gỡ trở ngại; bảo đảm sự kiện diễn ra hiệu quả, đúng giới hạn thời gian |
| Product Owner | Tìm kỹ thuật xác định Product Goal, quản lý backlog; giúp đội hiểu hạng mục cần rõ, gọn; hỗ trợ lập kế hoạch theo thực nghiệm và cộng tác với bên liên quan |
| Tổ chức | Dẫn dắt, đào tạo việc áp dụng Scrum; tư vấn triển khai; giúp mọi người hiểu cách tiếp cận thực nghiệm; gỡ rào cản giữa bên liên quan và đội |
Developers là ai?
Developers là những người cam kết tạo ra mọi phần của một Increment dùng được trong mỗi sprint, không chỉ lập trình viên mà cả người kiểm thử, thiết kế, phân tích. Họ lập Sprint Backlog, giữ chất lượng theo Definition of Done, điều chỉnh kế hoạch mỗi ngày hướng tới Sprint Goal và nhắc nhau giữ trách nhiệm như người chuyên nghiệp. Developers cũng là người ước lượng độ lớn công việc; PO có thể giúp họ hiểu phương án đánh đổi nhưng không áp con số.
Scrum Master khác quản lý dự án thế nào?
| Tiêu chí | Quản lý dự án truyền thống | Scrum Master |
|---|---|---|
| Quyết định làm gì | Giữ phạm vi đã ký | Không quyết; PO quyết ưu tiên |
| Phân việc | Giao việc cho từng người | Không giao việc; đội tự quản |
| Trọng tâm | Phạm vi, thời gian, ngân sách | Hiệu quả của đội và cách làm |
Việc quản lý dự án không mất đi mà được chia lại cho PO, Developers và Scrum Master.
Sprint là gì?
Sprint là “nhịp tim” của Scrum: khoảng thời gian cố định, tối đa một tháng, trong đó ý tưởng được biến thành giá trị. Sprint chứa mọi sự kiện khác, và sprint mới bắt đầu ngay khi sprint trước kết thúc. Trong sprint:
- Không thay đổi điều gì làm nguy hại đến Sprint Goal.
- Chất lượng không được giảm.
- Product Backlog được tinh chỉnh khi cần.
- Phạm vi có thể được làm rõ, thương lượng lại với PO khi đội hiểu thêm.
Sprint chỉ bị huỷ khi Sprint Goal trở nên lỗi thời, và chỉ Product Owner có quyền huỷ.
Về độ dài, Scrum Guide giải thích: sprint quá dài thì Sprint Goal dễ mất giá trị, độ phức tạp và rủi ro tăng; sprint ngắn tạo nhiều vòng học hơn. Trên thực tế, 2 tuần là lựa chọn phổ biến cho đội mới; 1 tuần hợp với sản phẩm cần phản hồi gấp; 3–4 tuần hợp khi cần nhiều thời gian tích hợp. Quan trọng hơn con số là giữ độ dài cố định. Scrum Guide cũng nhắc: burn-down, burn-up hay cumulative flow giúp dự báo, nhưng không thay thế thực nghiệm.
Các sự kiện Scrum diễn ra thế nào?
Ngoài Sprint, Scrum có bốn sự kiện bên trong mỗi sprint, mỗi sự kiện là một dịp chính thức để kiểm tra và thích ứng. Scrum Guide khuyến nghị tổ chức cùng giờ, cùng chỗ để giảm phức tạp.
| Sự kiện | Mục đích | Ai tham gia | Giới hạn (sprint 1 tháng) |
|---|---|---|---|
| Sprint Planning | Lập kế hoạch, chốt Sprint Goal | Cả Scrum Team, có thể mời thêm người tư vấn | Tối đa 8 giờ |
| Daily Scrum | Kiểm tra tiến độ tới Sprint Goal | Developers | 15 phút mỗi ngày làm việc |
| Sprint Review | Xem kết quả, quyết định điều chỉnh | Scrum Team và bên liên quan chính | Tối đa 4 giờ |
| Sprint Retrospective | Nâng chất lượng và hiệu quả | Scrum Team | Tối đa 3 giờ |
Với sprint ngắn hơn, Scrum Guide chỉ nói các sự kiện “thường ngắn hơn”. Tinh chỉnh backlog (refinement) không phải sự kiện mà là hoạt động liên tục: chia nhỏ, mô tả, sắp thứ tự hạng mục để chúng “sẵn sàng” cho Sprint Planning.
Sprint Planning
Buổi mở đầu sprint trả lời ba câu hỏi:
- Vì sao sprint này có giá trị? PO đề xuất, cả đội chốt Sprint Goal trước khi kết thúc buổi họp.
- Có thể làm xong những gì? Developers chọn hạng mục từ Product Backlog. Càng hiểu năng lực đã làm, nguồn lực sắp tới và Definition of Done, dự báo càng tự tin.
- Làm thế nào? Developers chia hạng mục thành việc nhỏ, thường một ngày hoặc ít hơn. Cách làm do Developers quyết định.
Daily Scrum
Buổi 15 phút của Developers, cùng giờ, cùng chỗ mỗi ngày làm việc, để kiểm tra tiến độ tới Sprint Goal và điều chỉnh Sprint Backlog. Nếu PO hay Scrum Master đang trực tiếp làm hạng mục trong sprint, họ tham gia với tư cách Developers. Bản 2020 bỏ ba câu hỏi quen thuộc; đội tự chọn cấu trúc, miễn tập trung vào Sprint Goal và có kế hoạch cho ngày tiếp theo.
Sprint Review
Đội trình bày kết quả cho bên liên quan chính, cùng bàn tiến độ tới Product Goal, những gì đã thay đổi trong môi trường kinh doanh và việc nên làm tiếp; Product Backlog có thể được điều chỉnh. Scrum Guide nhấn mạnh đây là buổi làm việc, không nên chỉ là thuyết trình, và Review không bao giờ là “cửa chặn” phát hành: Increment có thể giao cho người dùng trước khi sprint kết thúc.
Sprint Retrospective
Đội xem lại sprint về con người, tương tác, quy trình, công cụ và Definition of Done: điều gì tốt, vấn đề gì, đã xử lý chưa. Cải tiến có tác động lớn nhất cần làm sớm, thậm chí đưa vào Sprint Backlog sprint sau. Retrospective là sự kiện kết thúc sprint.
Ba tạo phẩm và ba cam kết trong Scrum là gì?
Tạo phẩm (artifact) thể hiện công việc hoặc giá trị, được thiết kế để tối đa hoá tính minh bạch. Theo bản 2020, mỗi tạo phẩm chứa một cam kết để mọi người có cái chung mà đo tiến độ.
| Tạo phẩm | Là gì | Cam kết |
|---|---|---|
| Product Backlog | Danh sách có thứ tự, luôn thay đổi, gồm mọi thứ cần để cải thiện sản phẩm; nguồn việc duy nhất của đội | Product Goal |
| Sprint Backlog | Sprint Goal, hạng mục được chọn và kế hoạch thực hiện, do Developers sở hữu | Sprint Goal |
| Increment | Bước tiến cụ thể tới Product Goal, cộng dồn với các Increment trước, dùng được | Definition of Done |
Product Backlog và Product Goal
Product Goal mô tả trạng thái tương lai của sản phẩm, làm đích để đội lập kế hoạch. Đây là mục tiêu dài hạn: đội phải đạt được hoặc từ bỏ mục tiêu này trước khi chuyển sang mục tiêu tiếp theo.
Ví dụ minh hoạ. Một chuỗi gara muốn số hoá khâu đặt lịch bảo dưỡng. Product Goal có thể là: “Khách tự đặt, đổi, huỷ lịch bảo dưỡng trực tuyến mà không cần gọi tổng đài”. Đội nên bắt đầu bằng phiên bản nhỏ nhất đủ kiểm chứng nhu cầu, theo tinh thần sản phẩm khả dụng tối thiểu (MVP). Nếu công ty dùng OKR, Product Goal thường gắn với một kết quả then chốt; xem thêm cách đặt mục tiêu theo OKR.
Sprint Backlog và Sprint Goal
Sprint Backlog trả lời vì sao (Sprint Goal), làm gì (hạng mục) và làm thế nào (kế hoạch). Sprint Goal là mục tiêu duy nhất của sprint, khiến đội làm cùng nhau thay vì mỗi người một việc riêng. Nếu công việc khác dự kiến, Developers thương lượng lại phạm vi với PO mà không ảnh hưởng Sprint Goal.
| Sprint Goal yếu | Sprint Goal tốt hơn (ví dụ minh hoạ) |
|---|---|
| “Làm xong 12 ticket” | “Khách đặt được lịch bảo dưỡng tại một chi nhánh và nhận tin nhắn xác nhận” |
| “Làm tiếp phần thanh toán” | “Khách đặt cọc trực tuyến được bằng một phương thức thanh toán” |
Increment và Definition of Done
Increment phải dùng được và được kiểm chứng kỹ để mọi phần chạy cùng nhau; một sprint có thể tạo nhiều Increment. Definition of Done (DoD) là mô tả chính thức trạng thái của Increment khi đạt tiêu chuẩn chất lượng cần có. Hạng mục chưa đạt DoD thì không được phát hành, cũng không được trình bày ở Sprint Review, mà quay lại Product Backlog. Nếu DoD là tiêu chuẩn chung của tổ chức, mọi Scrum Team phải theo ở mức tối thiểu.
Ví dụ minh hoạ DoD của một đội phần mềm: mã nguồn đã được người thứ hai xem lại; kiểm thử tự động chạy qua, không còn lỗi nghiêm trọng đã biết; đã triển khai lên môi trường thử nghiệm; đạt yêu cầu bảo mật và bảo vệ dữ liệu cá nhân của doanh nghiệp; tài liệu người dùng đã cập nhật. Các tiêu chí tự động hoá kiểm thử và triển khai là nơi Scrum gặp thực hành DevOps, giúp đội giao Increment nhiều lần trong một sprint.
Quy trình Scrum trong một sprint diễn ra như thế nào?
Ghép các phần trên lại, một sprint 2 tuần có thể trông như lịch dưới đây (ví dụ minh hoạ): mở bằng Sprint Planning, Daily Scrum mỗi ngày, tinh chỉnh backlog giữa tuần, khép lại bằng Review rồi Retrospective.
Scrum và Kanban khác nhau thế nào?
Kanban quản lý luồng việc bằng bảng trực quan và giới hạn số việc đang làm (WIP limit); nguồn gốc Kanban đã có trong bài về Agile, ở đây chỉ so sánh để bạn chọn đúng.
| Tiêu chí | Scrum | Kanban |
|---|---|---|
| Nhịp làm việc | Sprint cố định, tối đa 1 tháng | Luồng liên tục, không chia sprint |
| Vai trò | Bắt buộc PO, Scrum Master, Developers | Không quy định vai trò mới |
| Thay đổi giữa chừng | Không làm hại Sprint Goal | Kéo việc mới khi còn chỗ trong giới hạn WIP |
| Chỉ số hay dùng | Mức đạt Sprint Goal, burn-down | Cycle time, throughput |
| Hợp với | Phát triển sản phẩm mới, nhiều điều chưa biết | Hỗ trợ khách hàng, vận hành, việc đến liên tục |
Hai cách không loại trừ nhau. Scrum.org có tài liệu Kanban Guide for Scrum Teams để đội Scrum dùng thêm thực hành Kanban tối ưu luồng việc mà vẫn giữ đủ khung Scrum; nhiều đội gọi cách kết hợp này là Scrumban.
Khi nào nên và không nên dùng Scrum?
Nên dùng khi sản phẩm có nhiều điều chưa biết; có thể giao từng phần dùng được sau vài tuần; có người đủ thẩm quyền và thời gian làm PO; đội ổn định ít nhất vài tháng.
Cân nhắc cách khác khi việc đã rõ, lặp lại, ít rủi ro; khi phần lớn là yêu cầu đột xuất khiến sprint liên tục bị phá; khi thành viên làm cùng lúc nhiều dự án; hoặc khi lãnh đạo không chấp nhận để đội tự quản và để PO quyết ưu tiên.
Bắt đầu áp dụng Scrum trong doanh nghiệp Việt Nam thế nào?
Scrum thường đi cùng các dự án số trong chương trình chuyển đổi số doanh nghiệp, nơi cần ra mắt nhanh và điều chỉnh theo phản hồi. Gợi ý cho đội đầu tiên:
- Chọn một sản phẩm thí điểm thật, đủ quan trọng để được quan tâm, đủ nhỏ cho một đội.
- Chỉ định PO có thẩm quyền; lãnh đạo nói rõ mọi yêu cầu cho đội đi qua PO.
- Chọn Scrum Master được đào tạo bài bản, không phải trưởng nhóm cũ giữ thói quen giao việc.
- Đặt Product Goal, viết backlog đủ chi tiết cho vài sprint đầu.
- Viết Definition of Done và áp dụng ngay sprint đầu.
- Chạy 3–4 sprint 2 tuần đủ năm sự kiện, không cắt Review hay Retrospective vì “bận”.
- Đánh giá sau khoảng hai tháng: mức đạt Sprint Goal, thời gian giao hàng, phản hồi người dùng so với cách làm cũ.
Với dự án thuê ngoài, hợp đồng trọn gói cố định phạm vi dễ xung đột với Scrum. Hai bên nên thống nhất trước cơ chế đổi phạm vi, cách nghiệm thu theo Increment và ai làm PO phía khách hàng.
Khi nhiều đội cùng làm một sản phẩm: Scrum Guide chỉ quy định dùng chung Product Goal, Product Backlog và Product Owner. Để phối hợp sâu hơn có các khung mở rộng như Nexus của Scrum.org (khoảng 3 đến 9 Scrum Team, có Nexus Integration Team lo tích hợp), LeSS, Scrum@Scale và SAFe. Chỉ nên mở rộng khi từng đội đã chạy Scrum ổn định.
Những sai lầm phổ biến khi làm Scrum
- Daily Scrum thành buổi báo cáo sếp, không ai nhắc Sprint Goal.
- Không có Sprint Goal, sprint chỉ là danh sách ticket.
- DoD mơ hồ: “code xong, kiểm thử sprint sau” sinh nợ kỹ thuật và các “sprint ổn định hoá” không có trong Scrum.
- PO là hội đồng hoặc không có quyền, backlog đổi thứ tự hằng ngày.
- Scrum Master kiêm quản lý giao việc, đội mất khả năng tự quản.
- Nhồi việc giữa sprint mà không qua PO.
- Retrospective không có hành động, cùng một vấn đề lặp lại nhiều sprint.
- Dùng velocity để so sánh các đội: điểm ước lượng là công cụ dự báo nội bộ, không phải KPI.
Câu hỏi thường gặp
Scrum là gì nói ngắn gọn?
Scrum là khung làm việc theo vòng lặp ngắn gọi là sprint, tối đa một tháng. Mỗi sprint, một đội nhỏ gồm Product Owner, Scrum Master và Developers tạo ra phần sản phẩm dùng được, xem lại với người liên quan và cải tiến cách làm.
Product Owner và Scrum Master có thể là một người không?
Scrum Guide 2020 không có câu cấm cụ thể, nhưng hai trách nhiệm này dễ xung đột: PO chịu áp lực tối đa hoá giá trị, Scrum Master bảo vệ cách làm và nhịp bền vững của đội. Nên tách riêng nếu có thể.
Daily Scrum có phải đứng họp và trả lời ba câu hỏi?
Không. Scrum Guide 2020 chỉ quy định 15 phút, mỗi ngày làm việc, dành cho Developers, tập trung vào Sprint Goal. Đứng họp là thói quen của nhiều đội, Scrum Guide không yêu cầu; ba câu hỏi gợi ý của bản 2017 đã bị bỏ.
Scrum có bắt buộc dùng user story và story point?
Không. Scrum Guide không quy định cách viết hạng mục hay đơn vị ước lượng. User story, story point là kỹ thuật bổ sung. Điều bắt buộc là Developers tự ước lượng và hạng mục đủ nhỏ để làm xong trong một sprint.
Có cần chứng chỉ để làm Scrum Master không?
Không bắt buộc. Hai chứng chỉ phổ biến là Professional Scrum Master I (PSM I) của Scrum.org, thi 80 câu trong 60 phút, cần đạt 85%, có giá trị trọn đời; và Certified ScrumMaster (CSM) của Scrum Alliance, học khoá 16 giờ rồi thi 50 câu trong một giờ, gia hạn hai năm một lần. Thông tin ghi nhận tháng 10/2026; nên kiểm tra lại trên trang chính thức trước khi đăng ký.