Scrum cho doanh nghiệp: ai quyết định điều gì, ba cam kết và những lỗi vận hành hay gặp

Đăng ngày 23/10/2026

Tóm tắt và điều cần nhớ

Scrum là khung làm việc nhỏ cho những việc phức tạp: nhóm làm một phần, cho người dùng xem rồi chỉnh. Bài đọc Scrum Guide 2020 như một bản phân quyền: ai quyết điều gì, cam kết nào giữ nhóm đúng hướng, mỗi buổi họp để làm gì và lỗi vận hành nào hay gặp.

• Scrum cố ý chưa đầy đủ: Hướng dẫn chỉ định nghĩa phần cần cho lý thuyết của nó, còn cách làm cụ thể thuộc về nhóm [1].
• Ba trách nhiệm quyết ba loại việc: chủ sản phẩm quyết làm gì và thứ tự, Developers quyết nhận bao nhiêu và làm thế nào, Scrum Master giữ cho Scrum chạy đúng [1].
• Ba cam kết chống mơ hồ: mục tiêu sản phẩm, mục tiêu Sprint và định nghĩa “xong” [1].
• Câu chuyện người dùng, điểm ước lượng và bảng việc là thói quen phổ biến, không phải điều Scrum quy định [1].
• Tại Việt Nam, các nguồn công khai bài đọc được chỉ nói về nhân lực và đào tạo, chưa có số đo kết quả; nên thử nhóm nhỏ trước.

Scrum cố ý chưa đầy đủ: khung nhỏ cho việc phức tạp

Hướng dẫn tự mô tả Scrum là khung nhẹ giúp người, nhóm và tổ chức tạo giá trị bằng giải pháp thích ứng cho vấn đề phức tạp, đặt trên thực nghiệm, tức quyết định dựa trên điều quan sát được, và tư duy tinh gọn [1]. Khung này chưa đầy đủ một cách có chủ ý: chỉ định nghĩa phần cần để vận hành lý thuyết, và thay cho chỉ dẫn chi tiết, luật chơi điều chỉnh quan hệ và tương tác [1].

Tài liệu nguồn viết rằng Scrum có luật chặt về cách làm và người làm. Điều đó chỉ đúng một nửa: vai trò, sự kiện và tạo tác là cố định, còn cách làm nằm ở nhóm [1]. Theo cách đọc của bài, Scrum hợp khi chưa biết đáp án trước, như sản phẩm hay dịch vụ mới.

Những chỗ tài liệu nguồn lệch Hướng dẫn 2020

Danh mục tham khảo của tài liệu nguồn ghi Hướng dẫn Scrum 2017, nên nhiều thuật ngữ trong sách thuộc bản cũ, còn bài theo bản 2020 [1]. Năm chỗ dưới đây dễ gây nhầm khi bạn đối chiếu sách, bài báo hoặc khoá học khác; mỗi dòng nêu điều sách viết, rồi điều bản 2020 nói.

• Tên nhóm làm: sách gọi Development Team; bản 2020 gọi Developers và nhấn mạnh một nhóm Scrum duy nhất, không có đội con hay thứ bậc [1].
• Độ dài Sprint: sách nói hai đến bốn tuần; bản 2020 nói tối đa một tháng [1].
• Lập kế hoạch Sprint: sách đưa hai câu hỏi; bản 2020 có ba chủ đề là vì sao, làm được gì và làm thế nào [1].
• Họp ngày: sách đưa ba câu hỏi cố định; bản 2020 để Developers tự chọn cấu trúc, miễn bám mục tiêu Sprint [1].
• Tinh chỉnh danh mục: sách xếp thành cuộc họp thứ năm; bản 2020 coi là hoạt động liên tục, còn năm sự kiện gồm cả chính Sprint [1].

Ai quyết định điều gì: ba trách nhiệm trong một nhóm

Hướng dẫn mô tả một nhóm Scrum gồm một chủ sản phẩm, một Scrum Master và các Developers, thường không quá mười người, đủ kỹ năng để tạo giá trị mỗi Sprint và tự quyết ai làm gì, khi nào, thế nào [1]. Khi nhóm quá lớn, nên cân nhắc tách thành nhiều nhóm cùng một mục tiêu sản phẩm, danh mục việc và chủ sản phẩm [1]. Hãy đọc ba trách nhiệm như ba quyền quyết định (Hình 1):

• Chủ sản phẩm (Product Owner) tối đa hoá giá trị sản phẩm: nêu mục tiêu sản phẩm, viết rõ từng mục, sắp thứ tự và giữ danh mục minh bạch [1]. Vai này do một cá nhân giữ, không phải một ban, và cả tổ chức phải tôn trọng quyết định ấy [1].
• Developers là những người cam kết tạo mọi phần của bản dùng được mỗi Sprint, với kỹ năng tuỳ lĩnh vực chứ không chỉ lập trình [1]. Họ lập kế hoạch Sprint, giữ chất lượng theo định nghĩa xong và chỉnh kế hoạch mỗi ngày [1].
• Scrum Master chịu trách nhiệm cho việc Scrum chạy đúng như Hướng dẫn và cho hiệu quả của nhóm, như người lãnh đạo phục vụ nhóm, chủ sản phẩm và tổ chức: huấn luyện tự quản lý, gỡ cản trở, giữ các sự kiện đúng khung giờ [1].

Chủ doanh nghiệp nhỏ thường kiêm cả ba việc: tự nghĩ việc, tự chia việc, tự kiểm. Scrum buộc tách ba chiếc mũ ấy. Nếu bạn giữ mũ chủ sản phẩm, hãy quyết làm gì trước, nhưng để nhóm quyết nhận bao nhiêu và làm cách nào. Tài liệu nguồn coi thiếu chủ sản phẩm chuyên trách là lỗi hay gặp, và bài đồng tình: khi người quyết thứ tự vắng mặt, nhóm không biết nên làm gì trước.

Ba cam kết giữ nhóm đi đúng hướng

Hướng dẫn gắn mỗi tạo tác với một cam kết để tăng minh bạch và có thước đo tiến độ [1]. Ba cam kết tạo thành ba tầng (Hình 2), mỗi tầng trả lời một câu hỏi nhóm hay né: đi đâu, Sprint này vì sao, thế nào là xong.

• Mục tiêu sản phẩm mô tả trạng thái tương lai của sản phẩm làm đích lập kế hoạch; nhóm phải hoàn thành hoặc bỏ một mục tiêu rồi mới nhận mục tiêu khác [1].
• Mục tiêu Sprint là mục tiêu duy nhất của Sprint, lập trong buổi lập kế hoạch; đó là cam kết của Developers nhưng cho phép linh hoạt về công việc cụ thể [1].
• Định nghĩa “xong” mô tả chính thức trạng thái của bản tăng trưởng khi đạt chuẩn chất lượng; mục chưa đạt không được phát hành hay đưa ra buổi rà soát mà quay về danh mục [1].

Cách viết để cam kết kiểm được là phần bài bổ sung. Mục tiêu Sprint nên trả lời “sau Sprint này, ai làm được gì mà trước đây chưa làm được”. Định nghĩa xong nên là danh mục kiểm vài dòng mà người ngoài nhóm cũng chấm được đạt hay chưa, thay vì câu chung chung như “làm cho kỹ”. Nếu tổ chức đã có chuẩn chung, mọi nhóm theo chuẩn đó như mức tối thiểu [1].

Một Sprint từ đầu đến cuối: năm sự kiện, mỗi sự kiện một câu hỏi

Sprint là nhịp tim của Scrum: một sự kiện có độ dài cố định, không quá một tháng, bao trọn các sự kiện còn lại; Sprint mới bắt đầu ngay khi Sprint trước kết thúc [1]. Trong Sprint, không có thay đổi nào làm hại mục tiêu Sprint, chất lượng không giảm, và phạm vi có thể được làm rõ hay thương lượng lại với chủ sản phẩm [1]. Chỉ chủ sản phẩm có quyền huỷ Sprint, và chỉ khi mục tiêu đã lỗi thời [1]. Bốn sự kiện còn lại (Hình 3):

• Lập kế hoạch Sprint trả lời vì sao, làm gì, làm thế nào: chủ sản phẩm đề xuất cách tăng giá trị để cả nhóm chốt mục tiêu Sprint, rồi Developers chọn mục và lập kế hoạch cho từng mục [1]. Tối đa tám giờ cho Sprint một tháng [1].
• Họp ngày kéo dài 15 phút và dành cho Developers, tự chọn cấu trúc miễn bám mục tiêu Sprint và ra kế hoạch cho ngày kế tiếp [1].
• Rà soát Sprint là buổi làm việc chứ không chỉ trình bày: nhóm đưa kết quả cho các bên liên quan chính, bàn tiến độ tới mục tiêu sản phẩm và có thể chỉnh danh mục [1]. Tối đa bốn giờ cho Sprint một tháng [1].
• Nhìn lại Sprint nhằm tăng chất lượng và hiệu quả: nhóm xem cá nhân, tương tác, quy trình, công cụ và định nghĩa xong, rồi chọn thay đổi hữu ích nhất, có thể đưa vào danh mục việc Sprint sau [1]. Tối đa ba giờ cho Sprint một tháng [1].

Sprint ngắn hơn cho nhiều vòng học hơn và giới hạn rủi ro chi phí, công sức trong khung nhỏ hơn [1]; bài đề xuất doanh nghiệp mới thử hai tuần. Scrum Master bảo đảm các sự kiện diễn ra và giữ đúng khung giờ [1].

Danh mục việc: thứ tự, kích cỡ và sự sẵn sàng

Danh mục việc sản phẩm là danh sách có thứ tự, luôn thay đổi, về điều cần để cải thiện sản phẩm; chủ sản phẩm có thể giao bớt việc nhưng vẫn chịu trách nhiệm [1]. Tài liệu nguồn nêu ba yếu tố khi sắp thứ tự là giá trị, rủi ro và phụ thuộc. Bài thêm một phép thử: mục nào bỏ đi mà khách không nhận ra thì xuống cuối.

Tinh chỉnh là việc chia nhỏ và làm rõ mục một cách liên tục [1]. Developers định kích cỡ vì họ làm việc; chủ sản phẩm có thể ảnh hưởng bằng cách giúp họ hiểu và chọn đánh đổi [1]. Mục nào làm xong được trong một Sprint thì sẵn sàng để chọn [1].

Câu chuyện người dùng, điểm ước lượng với planning poker, bảng việc ba cột và biểu đồ burndown là thói quen phổ biến trong tài liệu nguồn, nhưng Hướng dẫn không quy định chúng [1]. Hướng dẫn chỉ nhắc burndown như một cách dự báo hữu ích nhưng không thay được thực nghiệm [1]. Với việc không phải phần mềm, nhóm có thể dùng thẻ “nhỏ, vừa, lớn” và bảng dán tường.

Các bước áp dụng cho nhóm nhỏ

Các bước dưới đây dành cho một nhóm nhỏ, kể cả khi không làm phần mềm; chúng là đề xuất của bài, đối chiếu với Hướng dẫn 2020 chứ không phải thủ tục bắt buộc. Mục tiêu của Sprint đầu là kiểm tra xem ba quyền quyết định và ba cam kết có chạy được trong doanh nghiệp bạn hay không.

• Bước 1: Chọn một sản phẩm hoặc dịch vụ có khách thật, nhiều điều chưa chắc; viết mục tiêu sản phẩm trong một câu.
• Bước 2: Chọn một chủ sản phẩm có mặt ở buổi rà soát và quyết thứ tự việc.
• Bước 3: Lập nhóm đủ kỹ năng ra bản dùng được; chọn người giữ vai Scrum Master và để người ấy đọc Hướng dẫn.
• Bước 4: Viết định nghĩa xong thành danh mục kiểm ngắn, rồi lập danh mục việc.
• Bước 5: Chọn Sprint hai tuần; trong buổi lập kế hoạch, chốt mục tiêu Sprint và để Developers chọn việc nhận.
• Bước 6: Họp ngày 15 phút, cùng giờ cùng chỗ, chốt kế hoạch cho ngày kế tiếp.
• Bước 7: Cuối Sprint, cho khách thật xem bản dùng được, rồi nhìn lại và chọn một thay đổi.
• Bước 8: Sau ba Sprint, quyết định giữ, chỉnh hay dừng.

Tình huống áp dụng tại Việt Nam

Tại Việt Nam, Dân trí ngày 17/5/2016 thuật lại rằng cộng đồng AgileVietnam ghi nhận hàng trăm công ty đang nỗ lực chuyển cách phát triển phần mềm sang Agile và Scrum; bài không nêu cách đếm [2]. Ông Dương Trọng Tấn, giám đốc Học viện Agile, một đơn vị đào tạo, nói nhu cầu ScrumMaster khá lớn nhưng ScrumMaster chuyên nghiệp vô cùng thiếu vì thiếu đơn vị đào tạo chuyên nghiệp [2]. Đó là nhận định của người trong ngành đào tạo, đã hơn mười năm tuổi.

VietnamNet ngày 3/6/2016 viết rằng từ năm 2010 môn Agile và Scrum là học phần chính thức của Khoa Công nghệ thông tin, Đại học Bách khoa Đà Nẵng, và công ty Axon Active hợp tác với hơn 10 trường đại học [3]. Tin không nêu nguồn các con số này; lời được thuật lại duy nhất là của giám đốc chi nhánh Đà Nẵng của chính công ty ấy. Hai tin cho thấy nhu cầu nhân lực và việc đào tạo, chưa cho thấy kết quả kinh doanh của Scrum.

Trang tải về của scrumguides.org liệt kê một bản dịch tiếng Việt của Hướng dẫn Scrum, ghi là tháng 11/2020, trong mục Community Translations, nơi cá nhân và nhóm đóng góp bản dịch [4]. Bài chưa đọc bản dịch nên không đánh giá; nếu dùng, hãy đối chiếu với bản tiếng Anh.

Ví dụ giả định, không lấy từ doanh nghiệp có thật: một hiệu sách sáu người muốn bán hộp sách giao theo tuần. Hai vợ chồng cùng đứng tên; bà vợ nắm khách quen nên làm chủ sản phẩm, ông làm Scrum Master, còn hai nhân viên bán hàng, người đóng gói và chị thu ngân là Developers. Mục tiêu của Sprint đầu, hai tuần, là bốn khách quen nhận một hộp sách thử và cho biết có muốn nhận tiếp. Định nghĩa xong gồm sách đúng chủ đề khách chọn, giao đúng giờ hẹn và khách trả lời phiếu ba câu. Khi nhìn lại, nhóm thấy giao buổi chiều thường không có người nhận nên Sprint sau thử giao buổi sáng.

Lỗi vận hành hay gặp, giới hạn và khi nào không nên dùng

Tài liệu nguồn kể sáu lỗi, từ thiếu chủ sản phẩm hay Scrum Master chuyên trách đến định nghĩa xong mơ hồ và bỏ buổi nhìn lại. Bài đưa ra sáu dấu hiệu theo cách riêng, một phần dựa trên danh sách ấy, mỗi dấu hiệu kèm hướng sửa theo Hướng dẫn 2020:

• Chủ sản phẩm là một ban hoặc vắng mặt: nhóm chờ quyết định, việc đổi hướng liên tục; hãy chọn một người và để cả tổ chức tôn trọng quyết định ấy [1].
• Scrum Master thành thư ký hoặc người giao việc: Hướng dẫn mô tả vai trò này là phục vụ và huấn luyện, còn ai làm gì do nhóm quyết [1].
• Định nghĩa xong mơ hồ: việc gần xong dồn sang Sprint sau; hãy viết thành danh mục kiểm và loại khỏi bản tăng trưởng mọi mục chưa đạt [1].
• Mục tiêu Sprint bị đổi giữa chừng: Hướng dẫn chỉ cho thương lượng phạm vi mà không làm hại mục tiêu, và chủ sản phẩm có quyền huỷ nếu mục tiêu lỗi thời [1].
• Họp ngày thành buổi báo cáo cho quản lý: hãy trả buổi họp về Developers để họ lập kế hoạch ngày kế tiếp [1].
• Rà soát thành màn trình diễn một chiều, nhìn lại bị bỏ vì bận: Hướng dẫn gọi rà soát là buổi làm việc và dành khung giờ riêng cho cải tiến [1].

Tài liệu nguồn gọi Scrum là mô hình thành công với tương lai tươi sáng và nêu nhiều lợi ích của buổi nhìn lại mà không dẫn bằng chứng; bài không lặp lại. Theo bài, Scrum không hợp khi việc lặp lại đã có quy trình ổn định, khi không có người quyết thứ tự, hoặc khi khách chỉ góp ý được sau nhiều tháng.

Ba Sprint đầu: mỗi Sprint cần chứng minh điều gì

Bài đề xuất thử ba Sprint hai tuần, tức sáu tuần, để biết Scrum có hợp với nhóm hay không. Mỗi Sprint nên trả lời một câu hỏi bằng quan sát chứ không bằng cảm giác. Nếu sau Sprint thứ ba người quyết thứ tự vẫn vắng hoặc khách chưa từng xem bản dùng được, hãy tạm dừng, sửa điều kiện rồi mới thử tiếp.

• Sprint 1: kiểm quyền quyết định; chủ sản phẩm có đưa ra thứ tự việc không, Developers có tự chọn việc nhận không.
• Sprint 2: kiểm định nghĩa xong; mục nào bị loại khỏi bản tăng trưởng và vì sao, rồi sửa định nghĩa.
• Sprint 3: kiểm mục tiêu Sprint; đạt hay chưa, vì sao, và quyết định giữ, chỉnh hay dừng.

Kết luận

Scrum đáng dùng khi được hiểu là một hệ thống quyền quyết định nhỏ: ai quyết làm gì, ai quyết làm thế nào, và ba cam kết để mọi người biết đích, biết Sprint này vì sao và biết thế nào là xong. Tại Việt Nam, bằng chứng công khai bài tìm được mới nói về nhân lực và đào tạo, nên hãy thử ba Sprint nhỏ rồi để kết quả quan sát của chính mình quyết định.

Nguồn và phương pháp

Bài này là tổng hợp và phân tích có hỗ trợ trí tuệ nhân tạo (AI), được diễn đạt lại bằng lời riêng, không phải bản dịch hay bản tóm tắt theo chương. Kiến thức khung dựa trên tài liệu Scrum Manual của Business Explained (bản v2, 2023), từ trang 1 đến trang 44 của tệp, đối chiếu với Scrum Guide 2020 của Ken Schwaber và Jeff Sutherland; cách đọc theo quyền quyết định, ba tầng cam kết, các bước, dấu hiệu lỗi, ví dụ giả định và kế hoạch ba Sprint do bài bổ sung. Nhiều chỗ của tài liệu nguồn đã được sửa theo Hướng dẫn 2020, như tên nhóm, độ dài Sprint, họp ngày, lập kế hoạch và tinh chỉnh danh mục. Bạn nên tìm tài liệu gốc để đọc đầy đủ.

Các nguồn web được truy cập ngày 20/10/2026 và đối chiếu lại ngày 21/10/2026; trang bản dịch tiếng Việt chỉ truy cập ngày 21/10/2026. Điều chưa kiểm chứng: hai tin năm 2016 là bài báo, số liệu không nêu cách đo; chưa tìm được doanh nghiệp Việt Nam công bố kết quả Scrum có số đo; chưa đọc bản dịch tiếng Việt của Hướng dẫn, chỉ thấy tên trong danh sách bản dịch; việc Hướng dẫn không quy định câu chuyện người dùng, điểm ước lượng và bảng việc dựa trên tìm từ khoá trên trang; tình huống hiệu sách là giả định.