Agile Scrum Bo Cau Hoi Kiem Tra Nhanh

Agile Scrum — Bộ Câu Hỏi Kiểm Tra Nhanh Tổng hợp 40 câu hỏi kiểm tra kiến thức Agile Scrum, bao gồm các chủ đề về vai trò, sự kiện, tạo phẩm và nguyên tắc cốt lõi của Scrum Framework. 40 CÂU HỎI QUICK TEST AGILE & SCRUM

Question 1 — Scrum Master's Role in Sprint Retrospective What is the role of the Scrum Master in the Sprint Retrospective? a) Auditor Evaluates and audits the process, reports to management b) Facilitator ✓ Facilitates the event and ensures it is productive and positive c) Silent Observer Only listens and does not participate d) Decision Maker Decides what improvements will be implemented Đáp án đúng: b) Facilitator Giải thích chi tiết: Theo Scrum Guide 2020, Scrum Master phục vụ Scrum Team bằng cách tạo điều kiện (facilitate) cho các Scrum events khi được yêu cầu hoặc khi cần thiết. Trong Sprint Retrospective, Scrum Master không đóng vai trò kiểm toán hay ra quyết định thay cho nhóm, mà giúp sự kiện diễn ra hiệu quả, an toàn và có giá trị cải tiến thực sự. Không phải người ra quyết định: các hành động cải tiến là trách nhiệm của cả Scrum Team, không phải riêng Scrum Master. Không phải kiểm toán viên: Scrum Master không đứng ngoài để đánh giá quy trình rồi báo cáo lên quản lý. Vai trò servant-leader: Scrum Master hỗ trợ nhóm thảo luận cởi mở, tập trung vào nguyên nhân, bài học và các cải tiến khả thi. Bảo đảm tính hiệu quả của sự kiện: Scrum Master giúp giữ đúng mục tiêu, đúng thời gian, và tạo môi trường tích cực để nhóm phản hồi trung thực. Tham gia như một thành viên của Scrum Team: Scrum Master có thể đóng góp quan điểm, nhưng không điều khiển cuộc họp như một quản lý. Căn cứ Scrum Guide: “The Scrum Master serves the Scrum Team in several ways, including facilitating the Scrum events as requested or needed.” Điều này khẳng định Scrum Master là người hỗ trợ và tạo điều kiện, đặc biệt trong Retrospective, chứ không phải auditor hay decision maker.

Question 2 — Number of Product Owners for Multiple Scrum Teams Three different Scrum Teams are formed to deliver a single product. How many Product Owners are needed? a) As recommended by the Scrum Master Not correct — the Scrum Master does not determine the number of Product Owners. b) One per Scrum Team — 3 Product Owners total Not correct — each team does not need its own Product Owner. c) One Product Owner for all three teams ✓ Correct answer. A single product needs one Product Owner, regardless of how many Scrum Teams work on it. d) Decided by the organization's management Not correct — management does not decide this role within Scrum. Đáp án đúng: c) Một Product Owner cho cả ba nhóm Giải thích chi tiết: Theo Scrum Guide 2020, khi một sản phẩm được phát triển bởi nhiều Scrum Team, các nhóm đó vẫn phải cùng hướng tới một Product Goal, dùng chung một Product Backlog, và được phục vụ bởi một Product Owner duy nhất. Scrum Guide nêu rõ rằng nếu một sản phẩm cần nhiều Scrum Team, các nhóm nên được tổ chức lại sao cho cùng tập trung vào cùng một product và chia sẻ cùng một Product Backlog, Product Goal và Product Owner. Nguyên tắc cốt lõi: Một sản phẩm = Một Product Backlog = Một Product Owner Product Owner là người chịu trách nhiệm tối đa hóa giá trị của sản phẩm và quản lý Product Backlog Nếu có nhiều Product Owner cho cùng một sản phẩm, rất dễ phát sinh xung đột ưu tiên, thiếu nhất quán trong Product Goal và làm giảm tính minh bạch của quyết định sản phẩm Product Owner có thể ủy quyền một số hoạt động hoặc cộng tác với các bên liên quan, nhưng trách nhiệm cuối cùng vẫn thuộc về một Product Owner duy nhất Liên hệ với theory/Scrum practice: khi nhiều Scrum Team cùng xây dựng một sản phẩm, Product Owner cần đảm bảo mọi công việc trong Product Backlog phản ánh một định hướng ưu tiên thống nhất. Điều này giúp các team không “kéo” sản phẩm theo nhiều hướng khác nhau, đồng thời hỗ trợ Sprint Planning, Refinement và ra quyết định dựa trên giá trị chung của sản phẩm. Kết luận: với ba Scrum Team nhưng chỉ một sản phẩm, Scrum chỉ yêu cầu một Product Owner để bảo đảm sự nhất quán, tập trung và tối đa hóa giá trị sản phẩm.

Question 3 — Production Release After Sprint Review After the Sprint Review, what does releasing a product in Scrum require? a) Approval from the Scrum Master before any release b) A separate release Sprint dedicated to deployment c) A decision by the Product Owner — release can happen at any time ✓ d) Unanimous agreement from all Developers Đáp án đúng: c) Quyết định của Product Owner — có thể phát hành bất kỳ lúc nào Giải thích chi tiết: Theo Scrum Guide 2020, việc phát hành sản phẩm không bị ràng buộc bởi Sprint boundary. Scrum không quy định phải chờ đến một thời điểm cố định sau Sprint Review mới được release. Thay vào đó, Product Owner là người quyết định khi nào phát hành Increment, dựa trên giá trị kinh doanh, mức độ sẵn sàng của sản phẩm và bối cảnh thị trường. Các điểm cốt lõi theo Scrum Guide/theory: “The Product Owner may release the Increment at any time” — đây là tinh thần quan trọng của Scrum: Increment có thể được phát hành bất cứ lúc nào nếu tổ chức muốn. Không cần “Release Sprint” — Scrum không có khái niệm bắt buộc phải dành riêng một Sprint chỉ để triển khai. Nếu đội phải có một Sprint ổn định hóa hay release riêng, đó thường là dấu hiệu quy trình chưa thực sự tạo ra Increment có thể phát hành ngay. Scrum Master không phê duyệt release — Scrum Master hỗ trợ hiểu và áp dụng Scrum, tháo gỡ trở ngại, nhưng không giữ vai trò “người duyệt phát hành” sản phẩm. Developers không cần bỏ phiếu đồng thuận tuyệt đối để release. Trách nhiệm của Developers là tạo ra Increment đáp ứng Definition of Done. Về mặt thực hành Scrum: sau Sprint Review, các bên liên quan có thể xem xét Increment, phản hồi sản phẩm và điều chỉnh Product Backlog. Nhưng quyết định phát hành vẫn là quyết định sản phẩm thuộc về Product Owner. Nếu Increment đã đạt Definition of Done, nó được xem là “Done” và potentially releasable (có khả năng phát hành). Tuy nhiên, Done không đồng nghĩa với Released. Lưu ý quan trọng: một Increment có thể hoàn toàn Done nhưng Product Owner vẫn chọn chưa phát hành vì lý do kinh doanh, chiến lược thị trường, phối hợp truyền thông, hoặc chờ thời điểm phù hợp hơn. Điều này hoàn toàn phù hợp với Scrum. Kết luận: Sau Sprint Review, Scrum không yêu cầu approval từ Scrum Master, không yêu cầu release Sprint riêng, và cũng không yêu cầu toàn bộ Developers đồng thuận. Quyền quyết định phát hành thuộc về Product Owner, và việc release có thể diễn ra bất kỳ lúc nào khi Increment đã sẵn sàng.

Question 4 — Sprint Goal About Automated Testing "All the Sprint code should have passed 100% automated unit tests." A Scrum Team sets the following Sprint Goal. Which assessment is correct? a) This is a good Sprint Goal because it ensures quality Quality is important, but this statement describes a technical criterion rather than a Sprint Goal. b) This is not a valid Sprint Goal — it describes a technical constraint, not a business objective ✓ Đáp án đúng. Sprint Goal cần thể hiện mục tiêu có ý nghĩa về mặt giá trị, không chỉ là ràng buộc kỹ thuật nội bộ. c) This Sprint Goal is acceptable if agreed upon by the whole team Agreement from the team is not enough if the statement still fails to express a meaningful Sprint objective. d) Only the Developers can evaluate whether this is a valid Sprint Goal Sprint Goal is created by the Scrum Team, and its validity should be understood in the context of Scrum theory. Đáp án đúng: b) Đây không phải Sprint Goal hợp lệ Giải thích chi tiết: Theo Scrum Guide 2020, “The Sprint Goal is the single objective for the Sprint... The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.” Điều này cho thấy Sprint Goal không chỉ là một câu mô tả công việc kỹ thuật, mà phải là mục tiêu duy nhất mang lại định hướng và sự gắn kết cho cả Sprint. Vì sao Sprint Goal này không hợp lệ: Sprint Goal phải phản ánh giá trị kinh doanh hoặc giá trị mà stakeholders nhận được, chứ không chỉ là một tiêu chí chất lượng nội bộ. “100% automated unit tests” là tiêu chí kỹ thuật. Đây phù hợp hơn với Definition of Done hoặc với các hạng mục trong Sprint Backlog, không phải là Sprint Goal. Sprint Goal tốt nên trả lời câu hỏi: “Tại sao Sprint này có giá trị với stakeholders?” Nếu chỉ nhìn vào test coverage, ta mới biết cách làm, nhưng chưa biết giá trị sản phẩm mà Sprint hướng tới. Một Sprint Goal tốt thường gắn với kết quả người dùng hoặc kết quả kinh doanh, ví dụ: “Enable customers to manage their payment methods”. Câu này nêu rõ năng lực mới mà khách hàng sẽ nhận được. Phân biệt theo Scrum theory: Sprint Goal = WHY — tại sao Sprint này quan trọng, Sprint này nhằm đạt điều gì có ý nghĩa. Sprint Backlog = WHAT + HOW — đội sẽ làm gì và thực hiện bằng cách nào để đạt Sprint Goal. Definition of Done = chất lượng tối thiểu — các tiêu chuẩn cần đạt để Increment được coi là hoàn thành. Nói cách khác, yêu cầu “100% automated unit tests” có thể là một điều kiện chất lượng rất tốt, nhưng nó không nên được dùng làm Sprint Goal nếu không gắn với một mục tiêu kinh doanh rõ ràng. Scrum khuyến khích Scrum Team tập trung vào outcome hơn là chỉ output. Kết luận: Sprint Goal này không hợp lệ vì nó mô tả một ràng buộc kỹ thuật, không phải một mục tiêu kinh doanh có ý nghĩa. Nếu muốn đúng theo Scrum, Sprint Goal nên diễn đạt giá trị mà Sprint mang lại cho người dùng hoặc stakeholders.

Question 5 — Developer Also Acting as Scrum Master One of the Developers is also serving as the Scrum Master. Which statement is true? a) This is not allowed — the roles must always be separate b) This is allowed, but it may create a conflict of interest ✓ c) This is ideal because it reduces team size d) The Scrum Master role must be a full- time dedicated position Đáp án đúng: b) Được phép, nhưng có thể tạo ra xung đột lợi ích Giải thích chi tiết: Theo Scrum Guide 2020, <The Scrum Master is a member of the Scrum Team=. Điều này có nghĩa là Scrum Master là một thành viên của Scrum Team, và Scrum Guide không hề cấm một người vừa làm Developer vừa đảm nhận thêm trách nhiệm Scrum Master. Tuy nhiên, việc kiêm nhiệm này cần được nhìn nhận cẩn thận trong bối cảnh Scrum theory: Xung đột lợi ích tiềm ẩn: Developer thường chịu áp lực hoàn thành công việc tạo ra Increment, trong khi Scrum Master phải giữ vai trò servant- leader, coaching, facilitation, và giúp nhóm loại bỏ trở ngại. Nếu một người vừa phải <làm việc của Developer= vừa <bảo vệ tính đúng đắn của Scrum=, họ có thể vô thức ưu tiên mục tiêu ngắn hạn của công việc kỹ thuật hơn là trách nhiệm hỗ trợ cả nhóm. Giảm hiệu quả của vai trò Scrum Master: Scrum Master không chỉ là người điều phối cuộc họp. Vai trò này còn bao gồm coaching cho Scrum Team, giúp tổ chức hiểu Scrum, hỗ trợ Product Owner, và thúc đẩy cải tiến liên tục. Khi bị chia đôi sự tập trung, chất lượng phục vụ của Scrum Master có thể suy giảm. Scrum Guide không cấm, nhưng cũng không xem đây là mô hình lý tưởng: Trong thực tiễn, kiêm nhiệm có thể chấp nhận được ở nhóm nhỏ, giai đoạn đầu áp dụng Scrum, hoặc khi chưa có đủ nguồn lực. Nhưng với nhóm lớn, phức tạp, hoặc có nhiều trở ngại tổ chức, Scrum Master cần sự tập trung cao hơn để phát huy hiệu quả. Không bắt buộc là vai trò full-time: Scrum Guide không quy định Scrum Master phải là một vị trí toàn thời gian dành riêng cho một nhóm. Điều quan trọng là trách nhiệm Scrum Master phải được thực hiện đầy đủ và hiệu quả, chứ không phải số giờ cố định. Theo Scrum theory, Scrum Master là người giúp Scrum Team tự quản tốt hơn, làm việc hiệu quả hơn và hiểu đúng Scrum hơn. Vì vậy, dù một Developer có thể kiêm Scrum Master, best practice thường là tách biệt vai trò để đảm bảo tính khách quan, tránh xung đột lợi ích và giúp Scrum Master tập trung vào servant leadership, coaching và facilitation. Kết luận: Câu trả lời đúng là b) vì Scrum cho phép một người vừa là Developer vừa là Scrum Master, nhưng đây không phải lựa chọn tối ưu trong nhiều bối cảnh vì có thể tạo ra xung đột lợi ích và làm giảm hiệu quả của vai trò Scrum Master.

Question 6 — Who Decides Sprint Length? Who decides the length (duration) of a Sprint? a) The Product Owner — based on business priorities b) The Scrum Master — as part of their facilitation role c) The Scrum Team collectively ✓ d) The organization's management or PMO Đáp án đúng: c) Toàn bộ Scrum Team Giải thích chi tiết: Theo Scrum Guide 2020, Sprint là một “container” cho tất cả các sự kiện Scrum và các hoạt động cần thiết để tạo ra giá trị trong một nhịp làm việc cố định. Guide nêu rõ: “A new Sprint starts immediately after the conclusion of the previous Sprint...” và tất cả công việc cần thiết để đạt Product Goal đều diễn ra bên trong Sprint. Về việc quyết định độ dài Sprint: Scrum Team quyết định độ dài Sprint, không phải riêng Product Owner hay Scrum Master. Sprint có thời lượng tối đa 1 tháng lịch (calendar month). Scrum Guide 2020 không còn đóng khung cứng “2–4 tuần”, mà chỉ đặt ra giới hạn tối đa này. Trên thực tế, nhiều nhóm chọn Sprint 1, 2 hoặc 4 tuần tùy vào mức độ phức tạp của sản phẩm, tốc độ phản hồi mong muốn và khả năng phối hợp của nhóm. Từ góc nhìn Scrum theory, độ dài Sprint nên hỗ trợ ba mục tiêu quan trọng: Phản hồi nhanh hơn: Sprint ngắn giúp nhóm nhận phản hồi sớm hơn từ khách hàng, người dùng và các bên liên quan. Giảm rủi ro tích lũy: Càng kéo dài Sprint, càng có nhiều thời gian để sai lệch phát sinh trước khi được phát hiện. Giữ nhịp điệu ổn định: Khi đã chọn độ dài Sprint, nhóm nên giữ nhất quán để tạo cadence rõ ràng cho việc lập kế hoạch, kiểm tra và thích nghi. Vai trò của các bên: Product Owner có thể góp ý dựa trên nhu cầu giá trị kinh doanh, nhưng không đơn phương quyết định. Scrum Master hỗ trợ nhóm hiểu Scrum và tối ưu hóa cách làm việc, nhưng không phải là người tự quyết định độ dài Sprint. Management/PMO không phải là bên quyết định Sprint theo Scrum. Nếu tổ chức áp đặt thời lượng từ bên ngoài, điều đó thường đi ngược tinh thần tự quản của Scrum Team. Kết luận: Độ dài Sprint là một quyết định của toàn bộ Scrum Team. Sprint phải đủ ngắn để tạo phản hồi nhanh và giảm rủi ro, nhưng cũng đủ dài để nhóm có thể tạo ra giá trị đáng kể và duy trì cadence ổn định.

Question 7 — Reference Plan Used in Daily Scrum In the Daily Scrum, which plan is used as a reference to understand changes in progress toward the Sprint Goal? 1 Sprint Backlog ✓ The correct answer. The Sprint Backlog is the plan for the current Sprint and serves as the reference during the Daily Scrum to inspect progress and adapt work as needed. 2 Product Backlog The Product Backlog is the overall list of product work, not the day- to-day reference plan for a specific Sprint. 3 Release Plan A release plan is not an official Scrum artifact and is not the primary reference used in the Daily Scrum. 4 Project Roadmap A project roadmap is a high-level planning tool, but it is not the Scrum reference used to inspect progress in the Daily Scrum. Đáp án đúng: a) Sprint Backlog Giải thích chi tiết: Theo Scrum Guide 2020, Daily Scrum là một sự kiện 15 phút dành cho Developers trong Scrum Team. Scrum Guide nêu rõ rằng Developers có thể chọn bất kỳ cấu trúc và kỹ thuật nào, miễn là Daily Scrum tập trung vào progress toward the Sprint Goal và tạo ra một kế hoạch hành động cho ngày làm việc tiếp theo. Vì vậy, kế hoạch được dùng làm tham chiếu trong Daily Scrum chính là Sprint Backlog. Đây là artifact của Sprint hiện tại và phản ánh đầy đủ cách nhóm đang tiến tới Sprint Goal. Vì sao Sprint Backlog là tham chiếu phù hợp? Sprint Backlog bao gồm Sprint Goal, các Product Backlog Items đã được chọn cho Sprint, và kế hoạch để tạo ra Increment. Trong Daily Scrum, Developers kiểm tra tiến độ thực tế so với Sprint Goal và xem cần điều chỉnh Sprint Backlog như thế nào. Daily Scrum không phải là buổi báo cáo trạng thái cho quản lý; đó là thời điểm để Developers tự quản lý công việc của chính họ trong Sprint. Phân biệt với các lựa chọn khác: Product Backlog: là danh sách công việc tổng thể cho toàn bộ sản phẩm, dùng cho quản lý và tinh chỉnh sản phẩm ở tầm rộng hơn, không phải tham chiếu chính trong Daily Scrum của một Sprint cụ thể. Release Plan: không phải là một Scrum artifact chính thức theo Scrum Guide. Project Roadmap: là công cụ hoạch định cấp cao, nhưng không phải tài liệu tham chiếu mà Scrum Guide dùng cho Daily Scrum. Ba câu hỏi truyền thống của Daily Scrum tuy không còn là bắt buộc trong Scrum Guide 2020, nhưng vẫn rất phổ biến trong thực hành: Hôm qua tôi đã làm gì để tiến gần Sprint Goal?1. Hôm nay tôi sẽ làm gì?2. Có trở ngại nào không?3. Kết luận: Trong Daily Scrum, nhóm nên dùng Sprint Backlog làm tham chiếu để hiểu các thay đổi trong tiến độ, kiểm tra mức độ tiến gần Sprint Goal, và điều chỉnh kế hoạch cho ngày tiếp theo nếu cần.

Question 8 — Urgent Request from Senior Leadership A senior leader wants the Developers to add an important feature to the current Sprint. What should the Developers do? 1 a) Immediately add the feature to the Sprint Backlog to satisfy the leader Not correct — Developers should not unilaterally change the Sprint Backlog in response to outside pressure. 2 b) Refuse — no changes are allowed during a Sprint under any circumstances Not correct — changes can happen during a Sprint, but they should be handled through the proper Scrum accountabilities and with care for the Sprint Goal. 3 c) Refer the request to the Product Owner to evaluate and prioritize ✓ Correct answer. The Product Owner should evaluate the request, decide whether it adds more value than the current work, and prioritize it appropriately. 4 d) Add the feature only if the Scrum Master approves Not correct — the Scrum Master facilitates and coaches, but does not own product prioritization or approve scope changes. Đáp án đúng: c) Chuyển yêu cầu đến Product Owner để đánh giá và ưu tiên Giải thích chi tiết: Theo Scrum Guide 2020, Product Owner là người chịu trách nhiệm tối đa hóa giá trị của sản phẩm. PO cũng là người quản lý Product Backlog và có quyền quyết định thứ tự ưu tiên của các hạng mục công việc. Vì vậy, khi có một yêu cầu khẩn cấp từ lãnh đạo cấp cao, Developers không nên tự ý nhận việc hoặc thay đổi Sprint Backlog mà phải chuyển yêu cầu đó cho Product Owner để đánh giá giá trị, mức độ khẩn cấp và tác động đến Sprint Goal. Nguyên tắc xử lý yêu cầu bên ngoài trong Sprint: Developers không tự ý thêm công việc vào Sprint Backlog chỉ vì có người bên ngoài yêu cầu. Sprint Backlog là kế hoạch của Developers cho Sprint hiện tại, nên mọi thay đổi phải được cân nhắc trong ngữ cảnh Sprint Goal. Product Owner là người duy nhất có thẩm quyền về thứ tự ưu tiên của Product Backlog, và là người phù hợp nhất để đánh giá xem tính năng mới có nên được đưa vào Sprint hay không. Nếu PO xác định yêu cầu mới thực sự quan trọng hơn, PO có thể thương lượng với Developers để điều chỉnh phạm vi Sprint: thêm hạng mục mới, hoặc bỏ/hoãn một hạng mục khác có giá trị thấp hơn hoặc tương đương. Sprint không bị hủy chỉ vì xuất hiện yêu cầu mới. Theo Scrum Guide, chỉ Product Owner mới có quyền hủy Sprint, và việc này chỉ xảy ra khi Sprint Goal trở nên lỗi thời. Vai trò của Scrum Master: Scrum Master không phê duyệt ưu tiên sản phẩm. Vai trò của Scrum Master là hỗ trợ Scrum Team hiểu và áp dụng Scrum đúng cách, đồng thời bảo vệ Developers khỏi các can thiệp bên ngoài. Trong tình huống này, Scrum Master nên hướng senior leader làm việc qua Product Owner thay vì tác động trực tiếp lên Developers. Tóm lại: Khi có yêu cầu khẩn cấp từ lãnh đạo cấp cao, Developers nên giữ vững tính tự quản, không tự ý thay đổi Sprint Backlog, và chuyển yêu cầu đến Product Owner để đánh giá, ưu tiên và quyết định cách xử lý phù hợp với Sprint Goal.

Question 9 — Format of Product Backlog Items The Scrum Master notices the team is not using the User Story format to document backlog items. What should the Scrum Master do? a) Immediately correct the team and enforce the User Story format Not correct — Scrum Master should not impose a specific backlog item format. b) Report the issue to management for resolution Not correct — this is not a management issue, and Scrum does not require escalation for format choices. c) Do nothing — the format of backlog items is not prescribed by Scrum ✓ Correct answer. Scrum does not prescribe a mandatory format for Product Backlog Items. The team may choose the most suitable format for its context, as long as the items are transparent, understandable, and useful for planning and refinement. d) Ask the Product Owner to rewrite all items in User Story format Not correct — the Product Owner is accountable for the Product Backlog, but Scrum does not require rewriting everything as User Stories. Đáp án đúng: c) Không làm gì — Scrum không quy định định dạng của backlog items Giải thích chi tiết: Theo Scrum Guide 2020, Product Backlog Items (PBIs) là những hạng mục trong Product Backlog được mô tả ở mức đủ rõ để Scrum Team có thể chọn vào Sprint Planning khi chúng đã sẵn sàng. Scrum Guide nhấn mạnh rằng các hạng mục này thường đạt được độ minh bạch cần thiết sau các hoạt động refinement. Guide cũng nêu rõ: "Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items." Điểm mấu chốt: Scrum Guide không quy định User Story — User Story là một kỹ thuật phổ biến đến từ Extreme Programming (XP), không phải yêu cầu bắt buộc của Scrum. Scrum chỉ quan tâm đến tính minh bạch và khả năng sử dụng của PBIs — các mục backlog cần đủ rõ, có thể ước lượng, và có thể được sắp xếp theo thứ tự ưu tiên. Nhóm có thể chọn bất kỳ định dạng nào phù hợp như User Stories, Use Cases, tasks, bugs, epics, hoặc mô tả theo ngữ cảnh sản phẩm. Scrum Master không áp đặt công cụ hay kỹ thuật — vai trò của Scrum Master là servant-leader, huấn luyện và hỗ trợ Scrum Team, chứ không phải “process police” kiểm soát cách viết backlog items. Liên hệ với lý thuyết Scrum: Scrum là một framework tối giản. Nó cung cấp cấu trúc, trách nhiệm và sự kiện cần thiết để tạo ra giá trị, nhưng không ép buộc nhóm phải dùng một mẫu viết cụ thể cho Product Backlog Items. Điều quan trọng là PBIs hỗ trợ được việc refinement, estimation, prioritization và giúp Scrum Team có đủ thông tin để lập kế hoạch Sprint hiệu quả. Tóm lại: Scrum Master nên tôn trọng cách nhóm tổ chức Product Backlog, miễn là cách đó giúp công việc minh bạch, dễ hiểu và phục vụ cho việc phát triển sản phẩm. Không có quy định nào trong Scrum bắt buộc phải dùng User Story format.

Question 10 — Transparency of Scrum Artifacts The Scrum Team uses information from Scrum artifacts to make ongoing decisions. What does the quality of these decisions depend on? c) The transparency of the artifacts ✓ Correct answer. In Scrum, important decisions are based on the perceived state of the three formal artifacts. When artifacts are transparent, the Scrum Team can inspect reality accurately and make decisions that maximize value and reduce risk. a) The experience level of the Scrum Master Not correct — the quality of decisions should not depend on the Scrum Master’s personal experience, but on the transparency of the artifacts and the empiricism of Scrum. b) The number of stakeholders involved in reviews Not correct — involving stakeholders can help, but it does not determine the quality of decisions in the same way transparency does. d) The completeness of the project documentation Not correct — Scrum does not rely on heavy documentation. What matters is that the artifacts themselves are transparent, usable, and support empiricism. Đáp án đúng: c) Tính minh bạch của các artifacts Giải thích chi tiết: Theo Scrum Guide 2020, Scrum dựa trên chủ nghĩa kinh nghiệm ( Empiricism), nghĩa là các quyết định quan trọng được đưa ra dựa trên những gì quan sát được từ thực tế. Scrum Guide nêu rõ rằng: "The emergent process and work must be visible to those performing the work as well as those receiving the work. With Scrum, important decisions are based on the perceived state of its three formal artifacts. Artifacts that have low transparency can lead to decisions that diminish value and increase risk." Điều này có nghĩa là: nếu các artifacts không minh bạch, Scrum Team có thể hiểu sai tình trạng công việc, từ đó đưa ra quyết định kém chất lượng, làm giảm giá trị sản phẩm và tăng rủi ro. Ba trụ cột của Empiricism trong Scrum: Transparency (Minh bạch): Thông tin về sản phẩm, tiến độ và công việc phải hiển thị rõ ràng, dễ hiểu và có cùng một cách diễn giải đối với mọi người. Inspection (Kiểm tra): Scrum Team thường xuyên kiểm tra artifacts, Increment và tiến độ để phát hiện sai lệch. Adaptation (Thích nghi): Khi phát hiện vấn đề, Scrum Team điều chỉnh kế hoạch, phạm vi hoặc cách làm việc để quay lại đúng hướng. Tại sao Transparency quan trọng: Nếu Product Backlog không phản ánh đúng thực tế, Sprint Planning có thể dựa trên thông tin sai và dẫn đến lựa chọn công việc không phù hợp. Nếu Definition of Done không rõ ràng, Increment có thể không đáng tin cậy và các bên liên quan hiểu sai về mức độ hoàn thiện. Nếu Sprint Backlog không được cập nhật đầy đủ, Daily Scrum sẽ mất tác dụng vì nhóm không còn dùng nó để kiểm tra tiến độ và điều chỉnh kế hoạch trong Sprint. Commitments của 3 Scrum artifacts cũng hỗ trợ transparency: Product Goal gắn với Product Backlog Sprint Goal gắn với Sprint Backlog Definition of Done gắn với Increment Các commitments này giúp Scrum Team có cùng một điểm tham chiếu khi kiểm tra và ra quyết định. Nói cách khác, càng minh bạch thì việc inspect càng chính xác, và adaptation càng hiệu quả. Tóm lại: Chất lượng quyết định trong Scrum phụ thuộc trực tiếp vào tính minh bạch của các artifacts. Đây là nền tảng để Scrum Team áp dụng empiricism đúng cách và đưa ra quyết định dựa trên sự thật, không dựa trên giả định.

Question 11 — Scrum Team Too Small An organization decides to have Scrum Teams with fewer than three Developers. What is a likely outcome? a) Reduced interaction The team may have less collaboration. b) Decreased skill diversity, leading to dependency and reduced productivity ✓ The team may lack enough cross-functional skills to work independently and deliver value effectively. c) Faster delivery due to less coordination overhead Small size can reduce coordination, but Scrum does not describe this as the likely benefit when the team is too small. d) No impact — team size does not affect Scrum effectiveness Team size does matter in Scrum because it affects collaboration, skills, and the ability to complete work within a Sprint. Đáp án đúng: b) Giảm đa dạng kỹ năng, dẫn đến phụ thuộc và giảm năng suất Giải thích chi tiết: Theo Scrum Guide 2020, Scrum Team phải “small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people.” Đồng thời, Scrum Guide cũng nhấn mạnh rằng “Fewer than three people on the Scrum Team decreases interaction and results in smaller productivity gains.” Điều này cho thấy khi một Scrum Team có ít hơn 3 Developers, nhóm thường không còn đủ “độ rộng” về kỹ năng để thực hiện trọn vẹn công việc theo hướng cross-functional. Trong Scrum, Developers phải cùng nhau tạo ra Increment “Done” trong mỗi Sprint, nên nếu số lượng quá ít, nhóm rất dễ gặp các vấn đề sau: Thiếu kỹ năng đa dạng: Một nhóm quá nhỏ thường không có đủ kỹ năng để thiết kế, xây dựng, kiểm thử và hoàn thiện Increment một cách độc lập. Tăng phụ thuộc bên ngoài: Nhóm buộc phải nhờ đến người hoặc bộ phận khác để hoàn thành công việc, làm giảm tính self-managing (tự quản lý) vốn là đặc trưng của Scrum Team. Giảm năng suất: Ít người hơn không phải lúc nào cũng hiệu quả hơn. Khi nhóm quá nhỏ, khả năng xử lý song song, chia sẻ công việc và hỗ trợ lẫn nhau bị hạn chế. Tăng rủi ro vận hành: Nếu một thành viên vắng mặt, nghỉ phép hoặc rời nhóm, năng lực thực thi của team có thể giảm mạnh, thậm chí làm chậm hoặc gián đoạn Sprint. Giảm tương tác và góc nhìn: Ít thành viên đồng nghĩa với ít trao đổi, ít phản biện và ít ý tưởng hơn trong việc giải quyết vấn đề. Về mặt lý thuyết Scrum, một team quá nhỏ đi ngược với mục tiêu tạo ra sự cân bằng giữa tính linh hoạt và khả năng hoàn thành công việc đáng kể trong Sprint. Scrum không tối ưu cho đội quá nhỏ vì empiricism trong Scrum cần sự cộng tác đủ mạnh để quan sát, kiểm tra và thích nghi hiệu quả. Kích thước tối ưu theo Scrum Guide: Scrum Team bao gồm Product Owner, Scrum Master và Developers, tổng cộng không quá 10 người. Trong thực tế, Developers thường ở mức 3–9 người để đảm bảo đủ đa dạng kỹ năng mà vẫn giữ được sự linh hoạt. Tóm lại: Nếu Scrum Team có ít hơn 3 Developers, hậu quả có khả năng cao nhất là giảm đa dạng kỹ năng, tăng phụ thuộc và làm giảm năng suất. Đây là lý do lựa chọn b là đáp án phù hợp nhất.

Question 12 — Sprint Length for an Internal Project A product development project involves delivering an internal feature for the organization. The team has a good skill mix and has done similar projects before. What could the Sprint length be? 1 a) Must be exactly 2 weeks — the industry standard This is not required by Scrum. 2 b) Must be 1 month — to allow enough time for complex features Scrum allows up to one month, but does not require every Sprint to be one month. 3 c) Any length up to 1 month, chosen by the Scrum Team ✓ This matches Scrum Guide guidance on Sprint length. 4 d) Determined by the project deadline divided by number of features Sprint length is not set by dividing deadlines across features. Đáp án đúng: c) Bất kỳ độ dài nào tối đa 1 tháng, do Scrum Team quyết định Giải thích chi tiết: Theo Scrum Guide 2020, Sprint là “heartbeat of Scrum”, nơi các ý tưởng được biến thành giá trị. Sprint là các sự kiện có độ dài cố định và phải không quá một tháng lịch. Scrum Guide nêu rõ rằng độ dài Sprint được giữ ổn định để tạo ra tính nhất quán trong nhịp làm việc và phản hồi. Nói cách khác, Scrum không quy định một Sprint phải đúng 2 tuần hay phải đúng 1 tháng. Thay vào đó, Scrum Team được quyền chọn độ dài phù hợp trong phạm vi 1 tháng hoặc ngắn hơn, rồi giữ nguyên độ dài đó trong một khoảng thời gian đủ dài để tạo cadence ổn định. Các yếu tố thường ảnh hưởng đến việc chọn Sprint length gồm: Mức độ phức tạp và rủi ro: Dự án càng phức tạp, càng có nhiều bất định thì Sprint ngắn hơn thường hữu ích hơn vì giúp nhóm nhận phản hồi sớm và điều chỉnh nhanh. Kinh nghiệm và độ trưởng thành của nhóm: Nhóm đã làm các dự án tương tự, hiểu rõ domain và có kỹ năng tốt có thể tự tin chọn Sprint dài hơn nếu điều đó giúp giảm chi phí điều phối và tăng tính liên tục. Nhu cầu phản hồi từ stakeholders: Nếu cần kiểm tra hướng đi thường xuyên, demo liên tục hoặc cần phản hồi nghiệp vụ sớm, Sprint ngắn hơn sẽ phù hợp. Chi phí overhead: Sprint quá ngắn làm tăng tỷ lệ thời gian dành cho planning, review, retro so với thời gian tạo ra giá trị. Vì vậy, cần cân bằng giữa tốc độ phản hồi và chi phí sự kiện. Trong trường hợp này, đây là một dự án nội bộ với nhóm có skill mix tốt và đã làm các dự án tương tự. Điều đó cho thấy nhóm có đủ năng lực để tự đánh giá và chọn Sprint phù hợp với bối cảnh. Thực tế có thể là 2–4 tuần, miễn là không vượt quá giới hạn tối đa 1 tháng. Tuy nhiên, không có “tiêu chuẩn ngành” bắt buộc nào nói rằng Sprint phải là 2 tuần. Về mặt lý thuyết Scrum, điều quan trọng nhất không phải là một con số cố định cho mọi tổ chức, mà là tính nhất quán. Khi Sprint length được chọn hợp lý và giữ ổn định, team sẽ dễ dự đoán hơn, dễ học từ dữ liệu thực tế hơn, và dễ cải tiến dựa trên empirical process control. Nếu thay đổi độ dài liên tục, nhóm sẽ khó tạo nhịp làm việc và khó so sánh kết quả giữa các Sprint. Kết luận: Scrum cho phép Sprint có độ dài bất kỳ miễn là không quá 1 tháng và do Scrum Team quyết định. Vì vậy, lựa chọn c là đáp án đúng nhất.

Question 13 — Empiricism in Scrum What does Empiricism provide? Select all that apply. a) Frequent opportunities to obtain information ✓ Transparency creates visibility so the team can access accurate information about work and progress. b) Frequent opportunities to inspect what is happening ✓ Inspection allows the Scrum Team to regularly review artifacts, progress, and emerging issues. c) Opportunities to adapt when deviating from the goal ✓ Adaptation helps the team make informed changes when inspection shows that outcomes are drifting away from the goal. d) A detailed upfront plan to eliminate uncertainty Empiricism does not eliminate uncertainty with a fixed upfront plan; it reduces uncertainty through learning and evidence. Đáp án đúng: a), b), c) — Ba trụ cột của Empiricism Giải thích chi tiết: Theo Scrum Guide 2020: “Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.” Đây là nền tảng quan trọng nhất của Scrum: thay vì cố gắng biết hết từ đầu, Scrum khuyến khích học từ thực tế, quan sát kết quả và điều chỉnh liên tục. Ba trụ cột của Empiricism trong Scrum: 🔍 Transparency (Minh bạch): Công việc, tiến độ, trạng thái và các vấn đề phải được hiển thị rõ ràng cho mọi người liên quan. Đây là điều kiện tiên quyết để những người tham gia có thể cùng nhìn thấy cùng một thực tế. Trong Scrum, các artifacts như Product Backlog, Sprint Backlog và Increment được thiết kế để tạo ra transparency. Nếu thông tin bị che giấu hoặc mơ hồ, inspection sẽ không đáng tin cậy. 🔎 Inspection (Kiểm tra): Scrum yêu cầu kiểm tra thường xuyên các artifacts, tiến độ và kết quả để phát hiện sai lệch sớm. Theo Scrum theory, inspection phải diễn ra đủ thường xuyên để các sai lệch không tích tụ thành vấn đề lớn. Cả 5 Scrum events đều tạo cơ hội để kiểm tra: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective và chính Sprint như một khung thời gian để quan sát giá trị được tạo ra. 🔄 Adaptation (Thích nghi): Khi inspection cho thấy sản phẩm, kế hoạch hoặc cách làm việc đang lệch khỏi mục tiêu, Scrum Team phải điều chỉnh. Adaptation là hành động phản hồi lại những gì đã quan sát được, thay vì tiếp tục đi theo một kế hoạch cứng nhắc. Nếu không thích nghi, nhóm sẽ lặp lại cùng một sai lầm và lãng phí thời gian, công sức, cũng như cơ hội tạo giá trị. Vì sao d) sai: Empiricism đi ngược với tư duy detailed upfront plan nhằm loại bỏ hoàn toàn bất định. Đó là đặc trưng của cách tiếp cận waterfall hoặc predictive planning. Trong Scrum, không phải mọi thứ đều được biết trước; thay vào đó, team chấp nhận sự không chắc chắn và học dần qua từng Sprint bằng quan sát thực tế, phản hồi từ stakeholder và kết quả của Increment. Kết luận: Empiricism cung cấp minh bạch, kiểm tra thường xuyên và khả năng thích nghi. Vì vậy, các lựa chọn đúng là a), b), c).

Question 14 — Scrum Master's Leadership Model What leadership model does the Scrum Master follow? a) Micro-management Controls every small detail of the team. b) Authoritative leadership Gives direct orders and expects compliance. c) Servant leadership ✓ Serves the team and organization to enable effectiveness. d) Laissez-faire Completely hands-off, with no involvement. Đáp án đúng: c) Servant leadership — lãnh đạo phục vụ Giải thích chi tiết: Theo Scrum Guide 2020, Scrum Master “is accountable for establishing Scrum as defined in the Scrum Guide” và thực hiện điều đó bằng cách “helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.” Scrum Guide cũng nhấn mạnh rằng Scrum Master là “a true leader who serves the Scrum Team and the larger organization.” Đây chính là cốt lõi của Servant Leadership: lãnh đạo bằng cách phục vụ, hỗ trợ và tạo điều kiện để người khác thành công. Servant Leadership trong Scrum có nghĩa là: Phục vụ Developers: Coaching, loại bỏ impediments, và bảo vệ nhóm khỏi các can thiệp bên ngoài để Developers có thể tập trung tạo ra Increment có giá trị. Phục vụ Product Owner: Hỗ trợ quản lý Product Backlog hiệu quả, tạo điều kiện cho sự hợp tác với stakeholder, và giúp Product Owner tối ưu hóa giá trị sản phẩm. Phục vụ tổ chức: Dẫn dắt, đào tạo, huấn luyện và hỗ trợ tổ chức trong việc áp dụng Scrum đúng tinh thần, thay vì chỉ áp dụng hình thức. Phân biệt với các mô hình khác: Micro-management: Tập trung kiểm soát chi tiết từng việc nhỏ, đi ngược lại tinh thần tự quản của Scrum Team. Authoritative leadership: Ra lệnh từ trên xuống, trong khi Scrum Master không phải là người chỉ huy đội nhóm theo quyền lực chức danh. Laissez-faire: Hoàn toàn thụ động, “để mặc” nhóm tự xoay sở; điều này cũng sai vì Scrum Master phải chủ động hỗ trợ, coaching và loại bỏ cản trở. Từ khóa quan trọng: “ true leader who serves” — Scrum Master là người lãnh đạo thực thụ thông qua phục vụ, không phải thông qua quyền lực hay kiểm soát. Kết luận: Scrum Master theo đuổi Servant Leadership vì vai trò này tập trung vào việc giúp Scrum Team, Product Owner và tổ chức nâng cao hiệu quả, thay vì điều khiển con người hay áp đặt mệnh lệnh.

Question 15 — Responsibility for Transparency in Sprint Review During the Sprint Review, stakeholders find that product development progress is unclear and lacks transparency. Furthermore, they do not understand the next steps. Who is responsible? a) The Developers They should have communicated progress better. b) The Product Owner ✓ Accountable for transparency of the Product Backlog and progress. c) The Scrum Master Responsible for all communication with stakeholders. d) The entire Scrum Team equally Shared responsibility with no primary owner. Đáp án đúng: b) Product Owner Giải thích chi tiết: Theo Scrum Guide 2020, Product Owner là người accountable cho effective Product Backlog management. Điều này bao gồm việc developing and explicitly communicating the Product Goal, creating and clearly communicating Product Backlog items, ordering Product Backlog items, và đặc biệt là ensuring that the Product Backlog is transparent, visible and understood. Vì vậy, khi stakeholders không thấy rõ tiến độ phát triển và không hiểu các bước tiếp theo, vấn đề cốt lõi nằm ở việc Product Owner chưa đảm bảo sự minh bạch và truyền đạt hiệu quả ở cấp độ sản phẩm. Vì sao Product Owner chịu trách nhiệm: PO chịu trách nhiệm về tính minh bạch của Product Backlog: Product Backlog không chỉ là danh sách việc cần làm, mà còn là công cụ thể hiện định hướng sản phẩm, giá trị ưu tiên và tiến độ hiện tại. Nếu nó không rõ ràng, stakeholders sẽ khó hiểu sản phẩm đang đi về đâu. PO phải truyền đạt Product Goal và hướng đi tiếp theo: Trong Sprint Review, mục tiêu không chỉ là xem những gì đã làm được, mà còn là tạo sự thấu hiểu chung về kết quả hiện tại, cơ hội điều chỉnh backlog, và bước tiếp theo của sản phẩm. PO là người kết nối giữa Scrum Team và stakeholders: PO làm việc với stakeholders để tối đa hóa giá trị sản phẩm, vì vậy PO phải đảm bảo thông tin về tiến độ, thay đổi ưu tiên, và next steps được truyền đạt rõ ràng, minh bạch. Liên hệ với Sprint Review: Sprint Review là sự kiện dùng để kiểm tra Increment và thích nghi Product Backlog nếu cần. Đây là cơ hội để Scrum Team và stakeholders cùng trao đổi về điều gì đã đạt được, điều gì đã thay đổi, và nên làm gì tiếp theo. Nếu stakeholders không hiểu “next steps”, nghĩa là Product Owner chưa làm tốt vai trò truyền đạt Product Backlog và định hướng sản phẩm. Vai trò của Scrum Master: Scrum Master có thể hỗ trợ Product Owner cải thiện cách trình bày, facilitation, hoặc cách làm rõ thông tin với stakeholders. Tuy nhiên, trách nhiệm chính vẫn thuộc về Product Owner, không phải Scrum Master. Vì sao không phải Developers: Developers chịu trách nhiệm về chất lượng kỹ thuật của Increment và việc tạo ra giá trị trong Sprint, nhưng không phải là người chịu trách nhiệm chính cho việc giao tiếp mức sản phẩm với stakeholders. Nếu thông tin với stakeholders chưa rõ ràng, đó không phải là lỗi chính của Developers. Kết luận: Trong tình huống này, Product Owner là người chịu trách nhiệm chính vì phải đảm bảo Product Backlog minh bạch, dễ hiểu và thể hiện rõ tiến độ cũng như các bước tiếp theo của sản phẩm theo đúng tinh thần Scrum Guide.

Question 16 — Team Member Asked to Support Outside Work During Sprint Mid-Sprint, a team member is asked by another department manager to support an important task outside of Sprint work. What should the team member do? a) Immediately help the other department — being a team player is important This is not the best response because it can disrupt the Sprint Goal and the team's focus. b) Ignore the request and continue Sprint work without informing anyone This avoids the issue instead of handling it transparently and collaboratively. c) Inform the Scrum Master and let the Scrum Master handle the impediment ✓ This is the correct response because external requests during the Sprint should be handled as impediments through the Scrum Master. d) Ask the Product Owner to remove a Sprint Backlog item to make time This is not the right first step. Sprint Backlog changes are handled within the Scrum Team, and the external request should first be raised as an impediment. Đáp án đúng: c) Thông báo cho Scrum Master và để SM xử lý impediment Giải thích chi tiết: Theo Scrum Guide 2020, Scrum Master có vai trò serves the Scrum Team và đặc biệt bao gồm việc removing impediments to the Scrum Team's progress. Trong tình huống này, yêu cầu từ một quản lý bộ phận khác là một tác động bên ngoài có thể làm gián đoạn Sprint và ảnh hưởng trực tiếp đến Sprint Goal. Phân tích tình huống: Yêu cầu từ bên ngoài trong Sprint là một impediment điển hình: Khi một thành viên bị kéo ra khỏi công việc Sprint để làm việc khác, nhóm mất tập trung, giảm năng lực hoàn thành mục tiêu Sprint, và có nguy cơ làm giảm giá trị của Sprint đang thực hiện. Thành viên không nên tự ý bỏ Sprint work: Theo Scrum, Developers chịu trách nhiệm cùng nhau quản lý công việc trong Sprint Backlog để hướng tới Sprint Goal. Việc tự ý rời khỏi công việc hiện tại vì một yêu cầu ngoài luồng có thể phá vỡ cam kết của nhóm. Scrum Master là người bảo vệ đội ngũ khỏi can thiệp bên ngoài: SM có trách nhiệm làm việc với các bên liên quan hoặc quản lý khác để xử lý trở ngại, giúp nhóm giữ được trọng tâm và tôn trọng ranh giới của Sprint. Nguyên tắc Sprint Protection: Sprint Backlog thuộc về Developers: Developers quản lý Sprint Backlog trong phạm vi Sprint. Nếu cần thay đổi, việc đó phải được xem xét trong Scrum Team, không phải do một quản lý bên ngoài áp đặt trực tiếp. Không ai bên ngoài Scrum Team nên can thiệp trực tiếp vào công việc của Developers: Các yêu cầu ngoài Sprint nếu muốn được xử lý phải đi qua cơ chế phù hợp, thường là thông qua Scrum Master để đánh giá tác động và phối hợp giải quyết. Nếu yêu cầu thật sự khẩn cấp: Scrum Master có thể làm việc với Product Owner và các bên liên quan để cân nhắc lại ưu tiên hoặc điều chỉnh kế hoạch theo đúng tinh thần Scrum, thay vì để cá nhân trong nhóm tự quyết định. Vì sao không chọn các đáp án khác: a) Immediately help the other department: Câu này thể hiện tinh thần hỗ trợ, nhưng trong Scrum, ưu tiên trước hết là bảo vệ Sprint Goal và sự tập trung của nhóm. Nếu tự ý chuyển hướng, nhóm có thể thất bại trong việc hoàn thành cam kết Sprint. b) Ignore the request: Phớt lờ yêu cầu là thiếu minh bạch và không giải quyết được impediment. Scrum khuyến khích phản ứng có chủ đích, giao tiếp rõ ràng và xử lý trở ngại một cách thích hợp. d) Ask the Product Owner to remove a Sprint Backlog item: Product Owner có thể tham gia thảo luận về ưu tiên, nhưng việc đầu tiên cần làm vẫn là báo cho Scrum Master để xử lý impediment và phối hợp giữa các bên. Không nên vội vàng tự điều chỉnh Sprint Backlog vì một yêu cầu bên ngoài khi chưa có đánh giá đầy đủ. Scrum Value liên quan: Courage (Dũng cảm) — dũng cảm nói “không” với yêu cầu không phù hợp, bảo vệ Sprint Goal, và chuyển vấn đề đến đúng vai trò để xử lý. Kết luận: Trong tình huống này, thành viên nên thông báo cho Scrum Master để SM xử lý trở ngại với quản lý bộ phận khác. Đây là cách làm đúng theo Scrum Guide, vừa bảo vệ Sprint Goal vừa đảm bảo sự minh bạch và tôn trọng cấu trúc trách nhiệm trong Scrum.

Question 17 — Adding More Scrum Teams to a Project When adding more Scrum Teams to a project working on a single product, the productivity of the original Scrum Teams will likely increase. True or False? a) True More teams means more output and faster delivery. b) False ✓ Adding teams initially decreases productivity due to coordination overhead. Đáp án đúng: b) Sai — Thêm nhóm ban đầu có thể làm giảm năng suất Giải thích chi tiết: Theo Scrum Guide 2020, khi một sản phẩm cần nhiều hơn một Scrum Team, các team đó vẫn phải cùng hướng tới một Product Goal và làm việc với cùng một Product Backlog. Scrum không giả định rằng chỉ cần thêm team là năng suất tổng thể sẽ tăng ngay lập tức. Ngược lại, trong giai đoạn đầu, hiệu quả thường bị ảnh hưởng bởi chi phí phối hợp và sự phức tạp tăng lên. Tại sao thêm nhóm không tự động tăng năng suất: Brooks's Law: “Adding manpower to a late software project makes it later.” Khi thêm người hoặc thêm team vào một dự án đang chạy, hệ thống phối hợp trở nên nặng hơn và tiến độ ban đầu thường chậm lại. Coordination overhead tăng: Nhiều Scrum Team đồng nghĩa với nhiều cuộc họp đồng bộ hóa hơn, nhiều phụ thuộc giữa các team hơn, và nhiều quyết định cần thống nhất hơn. Onboarding cost: Team mới cần thời gian để hiểu domain, kiến trúc, codebase, quy ước làm việc và cách sản phẩm vận hành. Trong giai đoạn đó, họ chưa đóng góp tối đa ngay lập tức. Integration complexity: Khi nhiều team cùng phát triển một sản phẩm, rủi ro xung đột kỹ thuật, merge conflict, phụ thuộc lẫn nhau và lỗi tích hợp tăng lên. Liên hệ với Scrum Guide và theory: Cùng một Product Backlog: Các team phải ưu tiên theo cùng một nguồn công việc, nên việc mở rộng quy mô đòi hỏi sự phối hợp chặt chẽ để tránh trùng lặp và lãng phí. Coherence và alignment: Scrum nhấn mạnh tính nhất quán của một sản phẩm. Khi có nhiều team, cần bảo đảm các team vẫn là cohesive Scrum Teams, cùng hiểu mục tiêu sản phẩm và cách phối hợp với nhau. Scale cần thêm cơ chế đồng bộ: Khi tăng số team, tổ chức thường cần thêm cơ chế như Scrum of Scrums, Nexus, LeSS, hoặc các thực hành tích hợp liên tục để giảm ma sát và giữ nhịp phát triển. Scrum Guide khuyến nghị khi scale: Chia sẻ cùng Product Backlog và Product Owner. Thiết lập các cơ chế đồng bộ hóa giữa team, ví dụ Scrum of Scrums. Sử dụng framework mở rộng như LeSS hoặc Nexus khi cần. Kết luận: Năng suất của các Scrum Team ban đầu thường giảm trong ngắn hạn trước khi có thể tăng trở lại khi các team học cách phối hợp hiệu quả. Vì vậy, câu trả lời đúng là False.

Question 18 — What Scrum Increases Transparency Of In the first few Sprints, Scrum increases the transparency of which of the following? Đáp án đúng: b) Rối loạn tổ chức và các vấn đề quy trình Giải thích chi tiết: Theo Scrum Guide 2020, Scrum “makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.” Nói cách khác, Scrum không phải là công cụ để che giấu vấn đề; nó là một cơ chế làm cho sự thật trở nên rõ ràng hơn. Trong những Sprint đầu tiên, khi nhóm bắt đầu thực hành các sự kiện Scrum, tạo Increment và kiểm tra - thích nghi liên tục, rất nhiều điểm yếu trong hệ thống làm việc sẽ lộ ra. Scrum giống như một tấm gương phản chiếu của tổ chức: Scrum không giải quyết vấn đề ngay lập tức — nó làm lộ ra những vấn đề đang tồn tại để tổ chức có thể nhìn thấy và cải thiện. Trong vài Sprint đầu, nhóm thường phát hiện quy trình không hiệu quả, thiếu kỹ năng, giao tiếp kém, technical debt, và các phụ thuộc chưa được xử lý tốt. Organizational dysfunction trở nên rõ ràng hơn, chẳng hạn như quản lý can thiệp quá nhiều, Product Owner không có quyền ra quyết định thực sự, hoặc yêu cầu không rõ ràng và thay đổi liên tục. Vì sao đáp án b đúng nhất? Câu hỏi hỏi về điều mà Scrum làm tăng tính minh bạch trong vài Sprint đầu tiên. Ở giai đoạn này, điểm nổi bật nhất thường không phải là các chỉ số cá nhân hay tài chính, mà là sự bộc lộ các vấn đề của hệ thống làm việc và cấu trúc tổ chức. Khi nhóm bắt đầu làm việc minh bạch hơn, những bất cập vốn bị che khuất bởi báo cáo, giả định hoặc thói quen cũ sẽ hiện ra rất rõ. Ví dụ thực tế: Sprint 1: Nhóm không thể deliver Increment đạt chất lượng → lộ ra thiếu Definition of Done hoặc thiếu năng lực tích hợp. Sprint 2: Daily Scrum kéo dài 1 giờ và đi chệch mục tiêu → lộ ra vấn đề communication và thiếu kỷ luật trong phối hợp. Sprint 3: PO không thể prioritize hiệu quả → lộ ra vấn đề về organizational governance và quyền ra quyết định. Liên hệ với theory và Scrum Guide: Scrum là một empirical process control framework, dựa trên transparency, inspection, adaptation. Transparancy không có nghĩa là mọi thứ “trông đẹp hơn”, mà là mọi thứ được nhìn thấy đúng như thực tế. Scrum's empirical approach helps organizations discover what is actually happening rather than what they think is happening. Kết luận: Trong những Sprint đầu, Scrum làm lộ ra các vấn đề thật của hệ thống làm việc — đặc biệt là rối loạn tổ chức và các vấn đề quy trình. Vì vậy, đáp án đúng là b. a) Technical debt accumulated in the codebase b) Organizational dysfunction and process problems ✓ c) Individual developer performance metrics d) Budget utilization and cost efficiency

Question 19 — Product Architecture in Scrum How should architectural features of the product be handled in Scrum? Low Hardening Low Flexibility High Hardening High Flexibility Assign architecture to a separate architecture team Architecture is not a concern in Scrum Design all architecture upfront before Sprint 1 Develop architecture incrementally each Sprint (Recommended) ✓ a) Develop architecture incrementally each Sprint ✓ Đáp án đúng. Kiến trúc của sản phẩm nên được phát triển dần dần, song song với các Sprint delivery. Đây là cách tiếp cận phù hợp với Scrum, Agile Manifesto và nguyên tắc kiến trúc tiến hóa. b) Design all architecture upfront before Sprint 1 Không đúng — thiết kế toàn bộ kiến trúc từ đầu là một dạng Big Design Up Front (BDUF), thường đi ngược lại tư duy Agile vì giả định rằng ta có thể biết đủ mọi thứ ngay từ đầu. c) Assign architecture to a separate architecture team Không đúng — trong Scrum, Developers là một phần của Scrum Team. Scrum không tách kiến trúc ra thành một nhóm riêng chịu trách nhiệm thay cho đội ngũ phát triển. d) Architecture is not a concern in Scrum Không đúng — kiến trúc vẫn là một mối quan tâm quan trọng trong Scrum. Vấn đề là cách xử lý kiến trúc phải hỗ trợ khả năng thích nghi, chất lượng và sự phát triển liên tục của sản phẩm. Đáp án đúng: Develop architecture incrementally each Sprint Giải thích chi tiết: Theo Scrum Guide 2020, Scrum không quy định một mô hình thiết kế kiến trúc cố định, nhưng Scrum được xây dựng trên nền tảng empiricism — tức là minh bạch, kiểm tra và thích nghi. Điều này có nghĩa là kiến trúc của sản phẩm không nên bị “đóng băng” từ sớm, mà nên được hình thành và hoàn thiện dần khi nhóm học thêm về sản phẩm, người dùng, công nghệ và rủi ro. Trong thực hành Agile, cách tiếp cận phù hợp nhất là evolutionary architecture hoặc emergent design: kiến trúc được phát triển từng phần, được kiểm tra qua từng Sprint, và được tinh chỉnh thông qua phản hồi thực tế. Đây là cách giúp sản phẩm vừa giữ được cấu trúc kỹ thuật đủ tốt, vừa không bị ràng buộc bởi các quyết định sớm thiếu thông tin. Tại sao không thiết kế kiến trúc toàn bộ trước? Vi phạm nguyên tắc empiricism: ở giai đoạn đầu, nhóm chưa thể biết đầy đủ nhu cầu thật, các ràng buộc hệ thống, hay thay đổi từ thị trường. Dẫn đến Big Design Up Front (BDUF), một anti-pattern phổ biến trong Agile khi cố định quá nhiều quyết định trước khi có phản hồi thực tế. Khi sản phẩm và hiểu biết tăng lên, kiến trúc cũng phải thích nghi; nếu không, hệ thống dễ trở nên cứng nhắc, khó mở rộng và khó bảo trì. Cách xử lý đúng trong Scrum: Các yêu cầu kiến trúc được xem như các Product Backlog Items và được đưa vào Product Backlog cùng với các hạng mục chức năng khác. Chúng được ưu tiên dựa trên giá trị, rủi ro, phụ thuộc kỹ thuật và nhu cầu phát triển sản phẩm. Trong từng Sprint, nhóm áp dụng emergent design, refactoring và các thực hành kỹ thuật phù hợp để kiến trúc tiến hóa cùng Increment. Developers trong Scrum Team, bao gồm cả những người có kiến thức kiến trúc, cùng chịu trách nhiệm về thiết kế kỹ thuật; Scrum không định nghĩa một architecture team tách biệt để “độc quyền” quyết định kiến trúc. Liên hệ với Scrum Guide và Agile theory: Scrum Guide 2020 nhấn mạnh rằng Scrum là một framework giúp con người giải quyết các vấn đề phức tạp thông qua học hỏi liên tục, chứ không phải một quy trình thiết kế cố định từ đầu. Agile Manifesto Principle #11: “ The best architectures, requirements, and designs emerge from self- organizing teams.” Điều này có nghĩa là kiến trúc tốt không phải là thứ được “xong từ đầu”, mà là thứ trỗi dậy dần từ quá trình làm việc thực tế của một đội tự quản. Kết luận: Trong Scrum, kiến trúc của sản phẩm nên được phát triển dần dần theo từng Sprint, gắn với Product Backlog, feedback thực tế và kỹ thuật thiết kế tiến hóa. Vì vậy, đáp án đúng là Develop architecture incrementally each Sprint.

Question 20 — Sprints Longer Than One Month What can Sprints longer than one calendar month lead to? a) Better quality — more time means more thorough development b) Increased risk of complexity, cost, and misalignment with stakeholder needs ✓ c) Higher team morale due to less frequent reviews d) More accurate velocity measurements Đáp án đúng: b) Tăng rủi ro về độ phức tạp, chi phí và không phù hợp với nhu cầu stakeholders Giải thích chi tiết: Theo Scrum Guide 2020, Sprint là một khoảng thời gian cố định, với giới hạn tối đa là 1 tháng lịch. Scrum nhấn mạnh rằng khi chân trời của Sprint quá dài, Sprint Goal có thể mất giá trị, độ phức tạp có thể tăng lên, và rủi ro có thể tăng lên. Mục đích của Sprint là tạo ra nhịp kiểm tra và thích nghi đủ thường xuyên để nhóm có thể điều chỉnh hướng đi dựa trên phản hồi thực tế. Rủi ro của Sprint dài hơn 1 tháng: Sprint Goal mất giá trị: Khi thời gian kéo dài, thị trường, nhu cầu người dùng, hoặc ưu tiên kinh doanh có thể thay đổi. Điều này khiến mục tiêu Sprint ban đầu trở nên lỗi thời hoặc kém phù hợp. Tích lũy rủi ro: Càng lâu mới nhận được phản hồi, nhóm càng có thể tiếp tục đi xa theo một hướng sai. Khi đó, chi phí sửa lỗi, rework, và điều chỉnh sẽ cao hơn nhiều. Mất nhịp điệu kiểm tra và thích nghi: Scrum dựa trên các vòng lặp ngắn để inspection và adaptation. Sprint quá dài làm giảm tần suất học hỏi, khiến đội ngũ khó duy trì focus và momentum. Dễ trượt sang kiểu làm việc waterfall: Khi khoảng thời gian quá dài, Sprint dễ bị chia thành các pha tuần tự như analysis → design → code → test, thay vì tạo ra một luồng phát triển linh hoạt và phản hồi sớm. Liên hệ với Scrum theory: Scrum được xây dựng trên empiricism — minh bạch, kiểm tra và thích nghi. Sprint ngắn giúp nhóm kiểm tra tiến độ thường xuyên hơn, giảm độ mù thông tin và tăng khả năng điều chỉnh trước khi chi phí thay đổi trở nên quá lớn. Vì vậy, giới hạn 1 tháng lịch không phải là khuyến nghị tùy chọn mà là một quy định cốt lõi trong Scrum. Kết luận: Sprint dài hơn một tháng có thể làm tăng độ phức tạp, chi phí và nguy cơ lệch khỏi nhu cầu của stakeholders. Do đó, đáp án đúng là b).

Question 21 — Tool That Shows Remaining Work Over Time Which tool displays remaining work over time? a) Team Velocity Measures the average amount of work completed per Sprint, not the remaining work over time. b) Sprint Burndown Chart ✓ Shows remaining work decreasing over time within a Sprint. c) Cumulative Flow Diagram Shows work items distributed across states such as To Do, In Progress, and Done. d) Release Burnup Chart Shows completed work increasing toward a goal, rather than remaining work. Đáp án đúng: b) Sprint Burndown Chart Giải thích chi tiết: Theo Scrum Guide 2020, có nhiều cách thực hành để dự báo tiến độ như burn-downs, burn-ups hoặc cumulative flows. Tuy các công cụ này hữu ích và được sử dụng rộng rãi, chúng không thay thế được tinh thần empiricism trong Scrum. Nghĩa là Scrum ưu tiên minh bạch, kiểm tra và thích nghi hơn là phụ thuộc vào một biểu đồ cụ thể. Sprint Burndown Chart là công cụ trực quan hóa lượng công việc còn lại trong Sprint theo thời gian: Trục X: Thời gian, thường là từng ngày trong Sprint. Trục Y: Công việc còn lại, có thể đo bằng story points, giờ, hoặc số task. Đường lý tưởng: Giảm đều từ đầu Sprint đến cuối Sprint. Đường thực tế: Phản ánh tiến độ thật của nhóm, có thể lên xuống tùy theo việc phát sinh, hoàn thành hoặc ước lượng lại. Nhờ đó, Scrum Team và stakeholders có thể quan sát nhanh liệu Sprint Goal có đang tiến triển đúng hướng hay không, đồng thời phát hiện sớm các dấu hiệu chậm tiến độ để kịp điều chỉnh. Phân biệt các công cụ: Velocity: Đo lường lượng công việc trung bình mà nhóm hoàn thành qua nhiều Sprint. Velocity hữu ích cho dự báo năng lực, nhưng không hiển thị remaining work theo thời gian. Burn-up Chart: Hiển thị lượng công việc đã hoàn thành tăng dần và thường hướng tới một mục tiêu tổng. Nó cho thấy tiến độ hoàn thành, nhưng không phải là biểu đồ chính để thể hiện công việc còn lại giảm dần như Burndown. Cumulative Flow Diagram (CFD): Hiển thị số lượng work items ở các trạng thái khác nhau như To Do, In Progress, Done. CFD rất hữu ích để thấy dòng chảy công việc và điểm nghẽn, nhưng không phải biểu đồ đặc trưng cho remaining work theo thời gian. Lưu ý quan trọng: Scrum Guide không bắt buộc phải dùng Burndown Chart. Đây chỉ là một trong nhiều công cụ dự báo và theo dõi tiến độ. Điều cốt lõi vẫn là empiricism — minh bạch, kiểm tra, và thích nghi liên tục. Vì vậy, khi cần hiển thị công việc còn lại theo thời gian, đáp án đúng nhất là Sprint Burndown Chart.

Question 22 — Discussing "Next Steps" in Sprint Review In the Sprint Review, besides reviewing the Increment and progress, is "what to do next" discussed? c) Yes ✓ — the Sprint Review results in a revised Product Backlog that defines likely next steps The Sprint Review leads to a revised Product Backlog, which helps clarify the probable next steps for the Scrum Team and stakeholders. Answer choices a) No — next steps are only discussed in Sprint Planning b) No — Sprint Review is only for demonstrating the Increment c) Yes ✓ — the Sprint Review results in a revised Product Backlog that defines likely next steps d) Only if the Product Owner requests it Đáp án đúng: c) Có — Sprint Review tạo ra Product Backlog đã được điều chỉnh Giải thích chi tiết: Theo Scrum Guide 2020, Sprint Review là một working session, không phải buổi trình diễn một chiều. Mục tiêu của sự kiện này là kiểm tra Increment đã hoàn thành, xem xét tiến độ hướng tới Product Goal, và từ đó điều chỉnh Product Backlog. Scrum Guide nêu rõ rằng kết quả của Sprint Review là một Product Backlog đã được sửa đổi, qua đó xác định các bước tiếp theo có khả năng nhất. Sprint Review không chỉ là "demo": Inspect Increment: Xem xét những gì đã được hoàn thành trong Sprint.1. Discuss progress: Thảo luận tiến độ so với Product Goal và các kỳ vọng hiện tại.2. Adapt Product Backlog: Điều chỉnh Product Backlog dựa trên phản hồi từ Scrum Team và Stakeholders.3. Determine next steps: Xác định các hướng đi và hạng mục có khả năng được làm tiếp theo.4. Về mặt lý thuyết Scrum, Sprint Review hỗ trợ tính thực nghiệm ( empiricism) thông qua việc minh bạch hóa kết quả, kiểm tra thực tế và thích nghi ngay trên sản phẩm. Vì vậy, câu hỏi "làm gì tiếp theo" không chỉ được phép thảo luận, mà còn là một phần quan trọng của sự kiện này để đảm bảo Product Backlog luôn phản ánh đúng nhu cầu và cơ hội hiện tại. Các bên tham gia Sprint Review: Toàn bộ Scrum Team tham dự. Stakeholders được mời bởi Product Owner. Đây là một working session, nơi mọi người cùng trao đổi và cập nhật định hướng sản phẩm, không phải chỉ nghe báo cáo một chiều. Timebox: Tối đa 4 giờ cho Sprint dài 1 tháng, tương đương khoảng 1 giờ cho mỗi tuần Sprint. Vì vậy, đáp án đúng là c: Sprint Review có thảo luận "bước tiếp theo", và kết quả mong đợi là một Product Backlog đã được điều chỉnh làm cơ sở cho các quyết định tiếp theo.

Question 23 — Developers Attending Customer Meeting Mid-Sprint Mid-Sprint, the Product Owner wants the Developers to attend an important meeting with a customer group. What should be done? a) Refuse — Developers must not attend any meetings outside Scrum events during a Sprint This is not correct. Scrum does not prohibit Developers from participating in other meetings during a Sprint if there is value in doing so. b) Attend only if the Scrum Master approves Incorrect. The Scrum Master is not a manager who gives permission. Scrum Teams are self-managing and decide internally. c) The Developers and Product Owner collaborate to decide — if valuable, they may attend ✓ This is correct. The Scrum Team should inspect the value of the meeting, its impact on the Sprint Goal, and whether attending helps the team deliver better outcomes. d) Only the Scrum Master should attend on behalf of the Developers Incorrect. The Scrum Master does not attend instead of Developers unless there is a specific reason. Value should be judged by the Scrum Team, not delegated automatically. Đáp án đúng: c) Developers và Product Owner cùng quyết định — nếu có giá trị, họ có thể tham dự Giải thích chi tiết: Theo Scrum Guide 2020, "The Scrum Team is self-managing, meaning they internally decide who does what, when, and how." Điều này có nghĩa là nhóm Scrum tự quyết định cách tổ chức công việc và việc tham gia các hoạt động hỗ trợ mục tiêu Sprint, miễn là việc đó mang lại giá trị. Phân tích tình huống: Scrum không cấm Developers tham dự các cuộc họp ngoài các Scrum Events trong Sprint. Đây là một quyết định của Scrum Team tự quản lý, dựa trên việc cân nhắc giá trị mang lại so với chi phí cơ hội. Nếu cuộc họp với khách hàng giúp làm rõ nhu cầu, xác nhận hướng đi, hoặc giảm rủi ro hiểu sai yêu cầu, thì việc tham dự có thể rất hữu ích cho Sprint Goal. Scrum Master không có quyền “phê duyệt” theo nghĩa quản lý nhân sự. Scrum Master là người phục vụ Scrum Team, huấn luyện và hỗ trợ, chứ không phải cấp trên ra lệnh. Cân nhắc thực tế: Cuộc họp có ảnh hưởng đến Sprint Goal hay không? Có cần tất cả Developers tham dự hay chỉ một vài người đại diện là đủ? Thông tin thu được có thể làm rõ Sprint Backlog hoặc giúp điều chỉnh cách tiếp cận trong Sprint hiện tại không? Về mặt lý thuyết Scrum, nguyên tắc self-management nhấn mạnh rằng nhóm tự quyết định cách làm việc tốt nhất để đạt mục tiêu. Scrum không áp đặt rằng Developers chỉ được tham gia các Scrum Events, cũng không bắt buộc Scrum Master phải là người duyệt mọi quyết định. Quan trọng nhất là nhóm phải luôn xem xét giá trị đối với Product Goal và Sprint Goal. Vì vậy, lựa chọn phù hợp nhất là c: Developers và Product Owner cùng trao đổi để quyết định; nếu cuộc họp có giá trị, Developers có thể tham dự mà không cần xin phép từ bên ngoài.

Question 24 — Reducing Daily Scrum Frequency The Scrum Team decides to reduce the frequency of the Daily Scrum to once per week. Is this appropriate? a) Yes — the team is self- managing and can choose their own practices Không đúng — tự quản lý không có nghĩa là có thể thay đổi hoặc bỏ qua các sự kiện Scrum bắt buộc. b) Yes — if the team feels daily meetings are unnecessary Không đúng — cảm nhận của nhóm không thay đổi được quy định của Scrum Guide về Daily Scrum. c) No — the Daily Scrum is a fixed Scrum event that must occur every day ✓ Đáp án đúng. Daily Scrum là một Scrum event bắt buộc, được tổ chức vào mỗi ngày làm việc trong Sprint để Developers inspect tiến độ và adapt kế hoạch kịp thời. d) Only acceptable if the Sprint is longer than 3 weeks Không đúng — độ dài Sprint không làm thay đổi bản chất của Daily Scrum. Dù Sprint dài hay ngắn, sự kiện này vẫn diễn ra hằng ngày. Đáp án đúng: c) Không — Daily Scrum là sự kiện Scrum cố định phải diễn ra hàng ngày Giải thích chi tiết: Theo Scrum Guide 2020: "The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint." Câu này thể hiện rất rõ rằng Daily Scrum không phải là một cuộc họp tùy chọn hay có thể giảm tần suất theo ý thích của nhóm. Tại sao không thể giảm tần suất: Daily Scrum là một trong 5 Scrum events của Scrum framework, nên không thể bỏ hoặc giảm xuống còn hàng tuần. Cụm từ "every working day" trong Scrum Guide là quy định rõ ràng về tần suất tổ chức. Mục đích của sự kiện này là giúp Developers inspect tiến độ hàng ngày hướng tới Sprint Goal và adapt Sprint Backlog hoặc kế hoạch làm việc ngay khi cần. Tự quản lý có giới hạn trong framework Scrum: Scrum Team là self-managing, nghĩa là họ có quyền tự quyết định cách làm việc để đạt Sprint Goal. Nhóm có thể điều chỉnh format, câu hỏi, cách trao đổi, hoặc thứ tự cập nhật trong Daily Scrum. Nhưng họ không thể thay đổi tần suất của một Scrum event bắt buộc, vì điều đó đi ngược lại quy tắc cốt lõi của Scrum. Theory áp dụng: Trong Scrum, tính tự quản lý không đồng nghĩa với việc nhóm được tùy ý sửa framework. Scrum cung cấp một cấu trúc tối thiểu để giảm phức tạp và tạo nhịp kiểm tra - thích nghi rõ ràng. Nếu Daily Scrum không hiệu quả, vấn đề thường nằm ở cách tổ chức hoặc nội dung trao đổi, không phải ở việc giảm số lần họp. Lưu ý thực tế: Nếu nhóm cảm thấy Daily Scrum đang rườm rà hoặc không tạo giá trị, đó là tín hiệu tốt để đưa vào Sprint Retrospective. Tại đây, nhóm có thể cải thiện cách thực hiện Daily Scrum để nó ngắn gọn, tập trung hơn và phục vụ Sprint Goal tốt hơn — thay vì bỏ bớt tần suất.

Question 25 — Who Performs Work Inspections in Scrum? Who performs inspections of work in Scrum? a) Only the Scrum Master — as the process guardian Không đúng — Scrum Master không phải là người duy nhất thực hiện inspection, và cũng không phải “người gác cổng” kiểm tra mọi thứ thay cho cả nhóm. b) Only the Product Owner — as the value accountable role Không đúng — Product Owner chịu trách nhiệm tối đa hóa giá trị sản phẩm, nhưng không độc quyền thực hiện inspection trong Scrum. c) External QA auditors assigned by the organization Không đúng — Scrum không dựa vào kiểm toán viên QA bên ngoài như cơ chế inspection chính thức của framework. d) Those who perform the work and those who receive the work ✓ Đáp án đúng. Trong Scrum, inspection là hoạt động diễn ra bởi những người tạo ra công việc và những người nhận/tiếp nhận kết quả của công việc đó. Điều này phù hợp với tinh thần minh bạch - kiểm tra - thích nghi của Scrum. Đáp án đúng: d) Những người thực hiện công việc và những người nhận công việc Giải thích chi tiết: Theo Scrum Guide 2020: "The emergent process and work must be visible to those performing the work as well as those receiving the work." Câu này cho thấy inspection không phải là hoạt động của một vai trò đơn lẻ, mà là một cơ chế tập thể để đảm bảo công việc và quy trình luôn được nhìn thấy, được đánh giá và được điều chỉnh kịp thời. Ai thực hiện Inspection trong Scrum: Developers: Kiểm tra công việc hàng ngày trong Daily Scrum, kiểm tra chất lượng kỹ thuật, độ hoàn thành của Increment và các trở ngại ảnh hưởng đến Sprint Goal. Product Owner: Kiểm tra Increment trong Sprint Review, kiểm tra Product Backlog để bảo đảm các mục tiêu sản phẩm, giá trị kinh doanh và thứ tự ưu tiên luôn phù hợp. Scrum Master: Kiểm tra mức độ hiệu quả của Scrum process, quan sát cách team áp dụng Scrum, và hỗ trợ cải tiến khi có vấn đề. Stakeholders: Kiểm tra Increment trong Sprint Review, đưa phản hồi để giúp Product Owner và Scrum Team điều chỉnh hướng đi của sản phẩm. Toàn bộ Scrum Team: Kiểm tra quy trình, tương tác, công cụ và cách làm việc trong Sprint Retrospective để cải tiến cách thức cộng tác. Inspection xảy ra trong tất cả Scrum events: Sprint Planning: Inspect Product Backlog, Sprint Goal và khả năng thực hiện công việc trong Sprint. Daily Scrum: Inspect tiến độ Sprint, kế hoạch trong 24 giờ tới và các trở ngại cần xử lý. Sprint Review: Inspect Increment cùng stakeholders để thu thập phản hồi thực tế. Sprint Retrospective: Inspect quy trình làm việc, công cụ, tương tác và cách cộng tác của team. Theory áp dụng: Trong Scrum, inspection là một trong ba trụ cột cốt lõi cùng với transparency và adaptation. Inspection phải được thực hiện thường xuyên bởi những người có liên quan trực tiếp đến công việc và kết quả công việc. Nếu chỉ một vai trò kiểm tra toàn bộ, Scrum sẽ mất đi tính cộng tác và khả năng tự quản lý của nhóm. Kết luận: Inspection không phải trách nhiệm của riêng Scrum Master hay Product Owner. Đây là trách nhiệm tập thể của Scrum Team và, ở những sự kiện phù hợp như Sprint Review, còn có sự tham gia của stakeholders để bảo đảm sản phẩm luôn đi đúng hướng và tạo giá trị.

Question 26 — Team Member Doesn't Know When Their Task Will Be Done During the Daily Scrum, a team member says they don't know when their task will be completed. What should be done? a) The Scrum Master should immediately escalate this to management Incorrect — the Daily Scrum is not a management escalation meeting. b) The team member should be removed from the task and replaced Incorrect — this is an extreme reaction and does not reflect Scrum's collaborative approach. c) The Developers should discuss and collaborate after the Daily Scrum to resolve the issue ✓ Correct — the Developers should coordinate after the Daily Scrum, inspect the issue, and adapt their plan so the Sprint Goal remains protected. d) The Product Owner should reprioritize the Sprint Backlog immediately Incorrect — the Product Owner does not re-prioritize the Sprint Backlog for this kind of immediate execution issue. Đáp án đúng: c) Developers thảo luận và cộng tác sau Daily Scrum để giải quyết vấn đề Giải thích chi tiết: Theo Scrum Guide 2020, Daily Scrum là sự kiện ngắn để Developers inspect progress toward the Sprint Goal và adapt the Sprint Backlog. Đây không phải là nơi để giải quyết chi tiết mọi vướng mắc ngay trong cuộc họp. Khi một thành viên chưa biết khi nào task sẽ hoàn thành, đó là tín hiệu cho thấy nhóm cần trao đổi thêm sau Daily Scrum để làm rõ nguyên nhân, tìm phương án hỗ trợ và điều chỉnh kế hoạch thực hiện. Scrum Guide cũng nêu rõ rằng: "The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint's work." Điều này có nghĩa là sau khi Daily Scrum kết thúc, các Developers có thể tiếp tục họp ngắn với những người liên quan để xử lý vấn đề cụ thể một cách chi tiết hơn. Tại sao đây là câu trả lời đúng: Daily Scrum chỉ kéo dài 15 phút và tập trung vào việc inspect tiến độ, không phải để mổ xẻ chi tiết từng trở ngại. Những người liên quan nên gặp nhau sau Daily Scrum để phân tích nguyên nhân, xem task đang bị chậm vì phụ thuộc, thiếu thông tin, hay gặp trở ngại kỹ thuật. Đây là biểu hiện của self-managing Developers: nhóm tự phối hợp để giải quyết vấn đề thay vì chờ một vai trò khác ra quyết định hộ. Giữ vững Sprint Goal là ưu tiên chính; mọi điều chỉnh nên nhằm giúp nhóm tiếp tục tiến về mục tiêu của Sprint. Các bước xử lý đúng: Trong Daily Scrum: thành viên nêu rõ rằng họ chưa chắc thời điểm hoàn thành task.1. Sau Daily Scrum: các Developers liên quan họp riêng để phân tích vấn đề và tìm hướng xử lý.2. Nếu nguyên nhân là impediment bên ngoài nhóm, Developers hoặc Scrum Master có thể cùng phối hợp để gỡ trở ngại đó. 3. Nếu cần thay đổi cách làm trong Sprint, Developers tự điều chỉnh Sprint Backlog để phản ánh kế hoạch mới.4. Liên hệ với theory trong Scrum: Scrum nhấn mạnh vào transparency, inspection và adaptation. Khi một task chưa rõ thời điểm hoàn thành, điều quan trọng không phải là đổ lỗi hay áp dụng biện pháp hành chính, mà là tạo ra sự minh bạch về vấn đề, kiểm tra thực trạng và thích nghi kế hoạch. Đây chính là cách nhóm tự quản vận hành hiệu quả trong Scrum. Scrum Values liên quan: Openness giúp thành viên dám nói thật về rủi ro; Respect giúp nhóm không đổ lỗi cá nhân mà tập trung vào giải pháp; Courage giúp Developers chủ động thừa nhận vấn đề và cùng nhau xử lý nó. Kết luận: Trong tình huống này, phản ứng đúng là để các Developers thảo luận và cộng tác sau Daily Scrum nhằm giải quyết vấn đề cụ thể, rồi tự điều chỉnh kế hoạch làm việc nếu cần. Scrum ưu tiên sự phối hợp của nhóm và khả năng thích nghi nhanh, không phải escalations hay thay người một cách vội vàng.

Question 27 — Testing Strategy Within Each Sprint Within each Sprint, should the Increment be tested sequentially from unit testing → integration testing → UAT? Testing strategy Team decides Continuous testingDefinition of Done Combined techniques a) Yes — sequential testing ensures thorough quality control Incorrect — Scrum does not prescribe a fixed sequential testing strategy. b) No — testing should be integrated throughout the Sprint, not done sequentially at the end ✓ Correct answer. The Scrum Team must ensure the Increment is thoroughly tested and meets the Definition of Done, but the specific testing approach is determined by the team. c) Testing is not required within a Sprint — only at the end of the release Incorrect — the Increment must be usable and meet the Definition of Done within the Sprint. d) The testing strategy is determined by the QA team, not the Scrum Team Incorrect — Scrum is accountable to the Scrum Team; there is no separate QA team owning the strategy in Scrum. Đáp án đúng: b) Không — kiểm thử phải được tích hợp xuyên suốt Sprint Giải thích chi tiết: Theo Scrum Guide 2020, mỗi Sprint là một khung thời gian ngắn để tạo ra một Increment có giá trị. Scrum Guide nêu rõ: "The Increment must meet the Definition of Done." Điều đó có nghĩa là trước khi Sprint kết thúc, Increment phải đủ hoàn thiện theo tiêu chuẩn chất lượng mà nhóm đã thống nhất, chứ không phải chờ đến cuối Sprint mới bắt đầu kiểm thử. Vì vậy, cách hiểu kiểm thử tuần tự theo mô hình unit testing → integration testing → UAT như một chuỗi cứng ở cuối Sprint là không phù hợp với Scrum. Cách làm đó dễ biến Sprint thành một mini-waterfall: phát triển trước, kiểm thử sau, rồi nếu phát hiện lỗi muộn thì rất khó sửa trong cùng Sprint. Điều này làm giảm tính minh bạch, kéo dài vòng phản hồi và tăng nguy cơ Increment không đạt trạng thái Done. Tại sao kiểm thử tuần tự là anti-pattern: Kiểm thử dồn về cuối Sprint khiến lỗi được phát hiện muộn, làm giảm khả năng thích nghi kịp thời. Nếu chỉ đến UAT mới phát hiện vấn đề, nhóm có thể không còn đủ thời gian để sửa và kiểm thử lại trước khi Sprint kết thúc. Cách làm này tách biệt “phát triển” và “kiểm thử”, trái với tinh thần cộng tác liên tục của Scrum Team. Nó làm suy yếu mục tiêu tạo ra Done Increment sau mỗi Sprint, thay vì một sản phẩm chỉ “gần xong”. Cách tiếp cận đúng trong Scrum: Test-Driven Development (TDD): viết test trước hoặc đồng thời với code để phản hồi sớm. Continuous Integration: tích hợp thường xuyên và chạy kiểm thử liên tục để phát hiện lỗi sớm. Definition of Done: bao gồm các tiêu chí kiểm thử cần thiết để bảo đảm chất lượng cho mỗi Product Backlog Item. Mỗi PBI nên được hoàn thiện và kiểm thử đầy đủ ngay khi được triển khai, thay vì dồn mọi kiểm thử sang cuối Sprint. Theo lý thuyết Scrum, chất lượng không phải là một bước riêng biệt ở cuối quy trình; chất lượng được xây dựng xuyên suốt quá trình phát triển. Scrum khuyến khích nhóm “inspect and adapt” liên tục. Khi kiểm thử được tích hợp trong từng PBI và diễn ra trong suốt Sprint, nhóm sẽ phát hiện vấn đề sớm hơn, giảm rework, và tăng khả năng tạo ra Increment có giá trị đúng hạn. Liên hệ với Agile: Nguyên tắc Agile số 1 nói rằng: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Kiểm thử liên tục là điều kiện quan trọng để thực hiện đúng nguyên tắc này, vì nó giúp phần mềm có thể được xác nhận chất lượng sớm, ổn định hơn và sẵn sàng mang lại giá trị ngay trong Sprint. Kết luận: Scrum không yêu cầu một chuỗi kiểm thử tuần tự cứng nhắc. Đúng hơn, Scrum Team nên tích hợp kiểm thử xuyên suốt Sprint bằng các kỹ thuật như TDD, continuous integration và Definition of Done rõ ràng. Như vậy, Increment có thể được kiểm tra, điều chỉnh và hoàn thành đúng chuẩn trước khi Sprint kết thúc.

Question 28 — Adding New Members Mid- Sprint New team members are added to the Scrum Team in the middle of a Sprint. What is the likely impact? a) Immediate productivity increase — more people means more output Không đúng — thêm người không đồng nghĩa với tăng năng suất ngay lập tức, đặc biệt trong một Sprint đang diễn ra. b) No impact — new members can start contributing right away Không đúng — thành viên mới thường cần thời gian để hiểu Sprint Goal, Sprint Backlog, cách làm việc của nhóm và bối cảnh sản phẩm. c) Short-term productivity decrease due to onboarding and integration overhead ✓ Đáp án đúng. Việc bổ sung thành viên giữa Sprint thường làm giảm năng suất ngắn hạn do phát sinh chi phí onboarding, phối hợp và tích hợp vào nhóm. d) The Sprint must be cancelled and restarted with the new team composition Không đúng — Scrum không yêu cầu hủy Sprint chỉ vì có thêm thành viên trong Scrum Team.

Question 29 — Horizontal vs. Vertical Decomposition A Scrum Team developing a web app sets Sprint Goals like: "Develop Data Layer for Functionality A." What is your assessment? Đáp án đúng: b) Không đúng — Sprint Goals phải phản ánh giá trị kinh doanh, không phải tầng kỹ thuật Giải thích chi tiết: Theo Scrum Guide 2020: "The Sprint Goal is the single objective for the Sprint... it creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives." Phân rã Ngang (Horizontal) — Anti-pattern: Chia theo tầng kỹ thuật: Data Layer → Business Logic → UI Mỗi Sprint chỉ hoàn thành một tầng → không tạo ra Increment có giá trị Stakeholders không thể sử dụng hay đánh giá kết quả sau mỗi Sprint Vi phạm nguyên tắc: "Each Sprint produces a usable Increment" Phân rã Dọc (Vertical) — Đúng theo Scrum: Chia theo tính năng/chức năng: Mỗi Sprint deliver một tính năng hoàn chỉnh (end-to-end) Ví dụ đúng: "Enable users to search for products" → bao gồm cả Data Layer + Business Logic + UI Tạo ra Increment có thể sử dụng sau mỗi Sprint Sprint Goal tốt: Phải trả lời "Tại sao Sprint này có giá trị?" từ góc độ kinh doanh/người dùng.

Question 30 — Definition of Done What is the Definition of Done (DoD) and how is it managed? 1Initially The Scrum Team defines the DoD for the product at the start. 2 If org standard exists The DoD must meet or exceed the organizational standard. 3Evolution The DoD is expanded over time as the team improves quality standards. 4 Accountability Developers are accountable for adhering to the DoD. Đáp án đúng: DoD là cam kết chất lượng, được quản lý bởi Scrum Team và phải đáp ứng tiêu chuẩn tổ chức Giải thích chi tiết: Theo Scrum Guide 2020, "The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product... If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum." Điều này có nghĩa DoD không chỉ là một checklist kỹ thuật đơn lẻ, mà là tiêu chuẩn chất lượng tối thiểu để xác định khi nào một Increment thực sự “Done”. Các điểm quan trọng về DoD: 📋 Ai tạo ra DoD? Nếu tổ chức có tiêu chuẩn chung, Scrum Team phải tuân theo như mức tối thiểu bắt buộc. Nếu không có tiêu chuẩn tổ chức, Scrum Team tự định nghĩa DoD phù hợp với sản phẩm và bối cảnh của mình. DoD thuộc về Scrum Team, nhưng phải phản ánh kỳ vọng chất lượng của sản phẩm và tổ chức. 📈 DoD phải tiến hóa: Qua mỗi Sprint Retrospective, nhóm có thể mở rộng DoD để nâng cao chất lượng và độ tin cậy của Increment. DoD không bao giờ được thu hẹp, vì việc giảm tiêu chuẩn sẽ làm suy yếu tính minh bạch và chất lượng. Khi nhóm trưởng thành hơn, DoD thường trở nên nghiêm ngặt hơn, ví dụ bổ sung kiểm thử, review, security checks, hoặc tiêu chí phi chức năng. ⚠ Khi không đáp ứng DoD: Item đó chưa được xem là Done. Item chưa Done không được tính là một phần của Increment hoàn chỉnh. Không nên release một item chưa đáp ứng DoD vì điều đó vi phạm cam kết chất lượng của Scrum. DoD vs. Acceptance Criteria: DoD áp dụng cho tất cả Increments và mô tả mức chất lượng tối thiểu của “xong”; còn Acceptance Criteria áp dụng cho từng PBI cụ thể, mô tả điều kiện chấp nhận của riêng item đó. Nói cách khác, một Product Backlog Item có thể đạt Acceptance Criteria nhưng vẫn chưa Done nếu chưa thỏa DoD.

Question 31 — Conditions After Sprint Planning Which of the following statements are true? Select all that apply. a) A Sprint cannot proceed without complete requirement specifications — False Scrum does not require complete requirement specifications before a Sprint starts. b) The Sprint Backlog must contain enough work for the entire Sprint ✓ After Sprint Planning, the Sprint Backlog must be sufficient for Developers to begin work. It does not need to be fully detailed for the entire Sprint at the outset. c) The Sprint Goal is created during Sprint Planning ✓ The Sprint Goal is created during Sprint Planning and becomes the Sprint’s commitment. This is explicitly stated in the Scrum Guide 2020. d) The Sprint Plan must be approved by management before the Sprint begins — False Scrum Teams are self-managing, so the Sprint Plan does not need management approval before the Sprint begins. Đáp án đúng: b) và c) Giải thích chi tiết: Theo Scrum Guide 2020: "Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team." Điều này có nghĩa Sprint Planning không chỉ tạo ra kế hoạch thực hiện Sprint, mà còn xác lập mục tiêu Sprint và đủ thông tin để đội bắt đầu triển khai công việc. Phân tích từng đáp án: ✅ b) Sprint Backlog phải chứa đủ công việc cho Sprint: Sau Sprint Planning, Sprint Backlog phải đủ để Developers có thể bắt đầu làm việc ngay. Không cần lập kế hoạch chi tiết cho toàn bộ Sprint ngay từ đầu; Sprint Backlog có thể tiếp tục được tinh chỉnh trong suốt Sprint. Điều này phù hợp với tinh thần thích nghi của Scrum: kế hoạch có thể được làm rõ dần khi nhóm học thêm về công việc. ✅ c) Sprint Goal được tạo ra trong Sprint Planning: Theo Scrum Guide 2020, Sprint Goal được tạo ra trong Sprint Planning. Sprint Goal là một commitment quan trọng của Sprint Backlog, giúp định hướng cho toàn bộ nỗ lực của Scrum Team trong Sprint. Mục tiêu này đảm bảo các hạng mục công việc không chỉ là các task rời rạc mà cùng phục vụ một kết quả chung có ý nghĩa. ❌ a) Sai: Scrum không yêu cầu đặc tả yêu cầu đầy đủ trước khi Sprint bắt đầu. Đây là cách nghĩ thiên về waterfall, nơi mọi thứ phải được chốt hoàn toàn trước khi thực thi. Trong Scrum, Product Backlog Items chỉ cần đủ rõ để nhóm có thể bắt đầu làm việc một cách hiệu quả. ❌ d) Sai: Sprint Plan không cần được quản lý phê duyệt trước khi Sprint bắt đầu. Scrum Team là một đội tự quản lý; chính Scrum Team chịu trách nhiệm xây dựng và điều chỉnh kế hoạch Sprint. Việc phụ thuộc vào phê duyệt từ quản lý bên ngoài sẽ làm suy yếu tính tự chủ và tính linh hoạt của Scrum.

Question 32 — Self-Management and Authority of the Scrum Team The Scrum Team is self-managing and empowered. Does this mean the team has the authority to make internal decisions about who does what, when, and how? a) True ✓ Self-managing teams decide internally how to organize and execute their work b) False Management still decides task assignments and work methods Đáp án đúng: a) Đúng — Nhóm tự quản lý quyết định nội bộ về cách tổ chức và thực hiện công việc Giải thích chi tiết: Theo Scrum Guide 2020, trong một Scrum Team không có các nhóm nhỏ hay hệ thống cấp bậc nội bộ. Scrum Team là một đơn vị gắn kết gồm những người làm nghề chuyên nghiệp, tập trung vào một mục tiêu tại một thời điểm là Product Goal. Scrum Team là cross-functional, nghĩa là các thành viên có đầy đủ kỹ năng cần thiết để tạo ra giá trị trong mỗi Sprint. Quan trọng hơn, Scrum Team là self-managing, tức là họ tự quyết định nội bộ về ai làm gì, khi nào và như thế nào. Tự quản lý (self-management) có nghĩa là: Who: Developers tự phối hợp và phân công công việc với nhau, không có PM hay manager giao task theo kiểu chỉ huy từ trên xuống. When: Nhóm tự quyết định thứ tự ưu tiên và thời điểm thực hiện các công việc trong Sprint, miễn là vẫn hướng tới Sprint Goal. How: Nhóm tự chọn kỹ thuật, công cụ, cách tiếp cận và phương pháp làm việc phù hợp nhất để hoàn thành công việc. Giới hạn của tự quản lý: Tự quản lý diễn ra trong phạm vi Scrum framework, nên nhóm không thể tùy ý bỏ qua các Scrum Events hoặc các nguyên tắc cốt lõi của Scrum. WHAT cần được làm là gì được thể hiện thông qua Product Backlog và định hướng bởi Product Owner. WHY — tức mục tiêu kinh doanh và giá trị mong muốn — được tổ chức và Product Owner định hướng, còn Scrum Team tự quyết định cách thực thi để đạt mục tiêu đó. Vai trò của Scrum Master: Scrum Master không phải là người kiểm soát hay phân công công việc cho Developers. Vai trò của Scrum Master là huấn luyện, hỗ trợ và bảo vệ tính tự quản lý của Scrum Team. Scrum Master giúp tổ chức hiểu và tôn trọng ranh giới của self-management, tránh việc can thiệp quá mức làm mất đi tính chủ động của nhóm. Tóm lại, câu nói “Scrum Team tự quản lý và được trao quyền” có nghĩa là nhóm có quyền ra quyết định nội bộ về cách tổ chức công việc, nhưng vẫn hoạt động trong khuôn khổ Scrum và dưới định hướng giá trị từ Product Goal, Product Owner, và tổ chức.

Question 33 — Who Decides Sprint Duration? (Revisited) Who decides the duration of a Sprint? a) The Product Manager or PMO Not correct — PMO and Product Manager are not roles defined in Scrum. b) The Product Owner — based on release schedule Not correct — the Product Owner influences value and ordering, but does not decide Sprint length alone. c) The Scrum Master — as part of process facilitation Not correct — the Scrum Master facilitates Scrum, but does not unilaterally set Sprint duration. d) The Scrum Team collectively ✓ The Scrum Team collectively decides the Sprint duration, balancing product needs, technical feasibility, and process effectiveness. Đáp án đúng: d) Toàn bộ Scrum Team Giải thích chi tiết (mở rộng từ Câu 6): Theo Scrum Guide 2020, Scrum Guide không chỉ định một vai trò riêng lẻ nào có quyền quyết định độ dài Sprint. Tuy nhiên, nguyên tắc tự quản lý (self-managing) của Scrum Team cho thấy đây phải là một quyết định tập thể, được thống nhất bởi toàn đội thay vì áp đặt từ bên ngoài. Tại sao không phải PMO hay Product Manager: PMO và Product Manager không phải là vai trò chính thức trong Scrum. Nếu một tổ chức bên ngoài ấn định độ dài Sprint, điều đó làm suy yếu quyền tự quản lý của Scrum Team. Scrum nhấn mạnh rằng đội ngũ phải có quyền tự tổ chức để tối ưu cách làm việc của chính mình. Tại sao không phải chỉ PO hay SM: Product Owner tập trung vào business value, thứ tự ưu tiên của Product Backlog, và nhịp giao hàng phù hợp với nhu cầu sản phẩm. Scrum Master tập trung vào hiệu quả của quá trình, bảo đảm Scrum được hiểu và áp dụng đúng. Developers là những người trực tiếp thực hiện công việc, nên hiểu rõ năng lực kỹ thuật, độ phức tạp, rủi ro, và khả năng hoàn thành công việc trong một khoảng thời gian nhất định. Vì Sprint duration liên quan đồng thời đến giá trị kinh doanh, hiệu quả quy trình, và khả năng thực thi kỹ thuật, nên cần cân bằng tất cả các góc nhìn và quyết định theo tinh thần tập thể. Các yếu tố Scrum Team thường cân nhắc khi chọn Sprint duration: Mức độ phức tạp và rủi ro của sản phẩm hoặc backlog items. Tần suất cần phản hồi từ stakeholders và mức độ thay đổi của thị trường. Khả năng tạo ra một Increment có giá trị trong khung thời gian đó. Overhead của các Scrum Events so với thời gian làm việc thực tế. Nhu cầu tạo nhịp làm việc ổn định, giúp đội duy trì cadence nhất quán. Về tính nhất quán: Scrum Guide khuyến nghị Sprint có độ dài cố định. Một khi Scrum Team đã chọn độ dài Sprint phù hợp, nên giữ nguyên để tạo nhịp điệu ổn định, hỗ trợ dự đoán, phản hồi đều đặn, và cải thiện liên tục. Việc thay đổi Sprint duration quá thường xuyên có thể làm mất sự ổn định của cadence và gây khó cho việc lập kế hoạch, kiểm tra và thích nghi. Tóm lại, Sprint duration không phải do một cá nhân hay phòng ban bên ngoài quyết định. Đây là quyết định của toàn bộ Scrum Team, dựa trên sự cân bằng giữa giá trị kinh doanh, hiệu quả quy trình, và năng lực thực thi của đội, đúng với tinh thần tự quản lý của Scrum.

Question 34 — Product Owner Not Providing Enough Support The Product Owner is not present at Scrum events and is not providing sufficient support to the Developers. Who bears immediate responsibility next? 1 a) The Developers — they should continue working independently Không đúng — Developers không phải là bên chịu trách nhiệm khắc phục việc PO vắng mặt bằng cách tự thay thế vai trò của PO. 2 b) The Scrum Master ✓ — accountable for ensuring Scrum is understood and enacted Đúng — Scrum Master là người chịu trách nhiệm giúp Scrum được hiểu đúng và được thực thi đúng trong tổ chức, bao gồm việc hỗ trợ PO và tháo gỡ các trở ngại ảnh hưởng đến hiệu quả của Scrum Team. 3 c) Senior management — they should replace the Product Owner Không đúng — quản lý cấp cao không trực tiếp thay PO trong Scrum và việc này không phải là phản ứng đầu tiên theo Scrum Guide. 4 d) The stakeholders — they should fill the Product Owner's role temporarily Không đúng — stakeholders có thể cung cấp phản hồi, nhưng không thể tự động thay thế Product Owner trong vai trò chịu trách nhiệm về giá trị sản phẩm và Product Backlog. Đáp án đúng: b) Scrum Master Giải thích chi tiết: Theo Scrum Guide 2020, Scrum Master là người phục vụ Scrum Team và tổ chức bằng cách giúp mọi người hiểu Scrum, huấn luyện đội ngũ áp dụng đúng Scrum, và loại bỏ các cản trở đối với việc thực thi hiệu quả. Khi Product Owner không có mặt ở các Scrum events hoặc không hỗ trợ đủ cho Developers, Scrum Master là người phải hành động trước để khôi phục sự phối hợp và đảm bảo Scrum vẫn vận hành đúng tinh thần. Scrum Guide mô tả rõ rằng Scrum Master phục vụ Product Owner bằng cách hỗ trợ họ trong việc: tìm các kỹ thuật hiệu quả để xác định Product Goal và quản lý Product Backlog; thiết lập kế hoạch sản phẩm theo hướng thực nghiệm trong môi trường phức tạp; tạo điều kiện cho sự hợp tác với stakeholders khi cần thiết. Từ đó có thể hiểu rằng khi PO thiếu hiện diện hoặc thiếu hỗ trợ, Scrum Master không đứng ngoài quan sát mà cần chủ động can thiệp để giúp PO thực hiện đúng trách nhiệm của mình. Trách nhiệm của Scrum Master trong tình huống này: Coaching PO: Giúp Product Owner hiểu rõ vai trò, kỳ vọng và trách nhiệm của mình trong Scrum. Escalation: Nếu PO không thể hoặc không sẵn sàng thực hiện vai trò, Scrum Master cần báo cáo và leo thang vấn đề lên cấp tổ chức phù hợp. Facilitation: Tạo điều kiện để PO và Developers kết nối hiệu quả hơn, đặc biệt trong các sự kiện Scrum như Sprint Planning, Sprint Review hay Refinement. Bảo vệ nhóm: Ngăn việc Developers bị chặn tiến độ vì thiếu định hướng, thiếu quyết định hoặc thiếu phản hồi từ PO. Scrum Master phục vụ PO bằng cách: giúp PO hiểu cách quản lý Product Backlog một cách minh bạch và có thứ tự ưu tiên rõ ràng; hỗ trợ PO giao tiếp hiệu quả hơn với stakeholders; đảm bảo PO tham gia đúng mức và đúng vai trò trong các Scrum events; giúp PO tạo ra điều kiện để team ra quyết định dựa trên giá trị sản phẩm và phản hồi thực nghiệm. Lưu ý quan trọng: Scrum Master không thể thay thế Product Owner. Đây là hai accountabilities khác nhau trong Scrum. PO chịu trách nhiệm tối đa hóa giá trị của sản phẩm và quản lý Product Backlog; còn Scrum Master chịu trách nhiệm bảo đảm Scrum được hiểu và được áp dụng đúng. Vì vậy, phản ứng đúng và ngay lập tức khi PO không hỗ trợ đủ là Scrum Master cần vào cuộc, không phải tự ý giao vai trò đó cho stakeholders, Developers hay management.

Question 35 — When Is the Product Backlog Retired? When is the Product Backlog "retired"? a) When the Product Owner retires or leaves the organization Không đúng — Product Backlog gắn với sản phẩm, không phụ thuộc vào việc một cá nhân rời đi hay thay đổi vai trò. b) When the project budget is exhausted Không đúng — hết ngân sách không làm Product Backlog biến mất; backlog vẫn tồn tại nếu sản phẩm vẫn còn được duy trì hoặc xem xét tiếp tục. c) When the product itself is retired or discontinued ✓ Đáp án đúng. Product Backlog chỉ “nghỉ hưu” khi chính sản phẩm không còn tồn tại, không còn được sử dụng hoặc đã bị ngừng phát triển/vận hành. d) After every major release of the product Không đúng — sau mỗi release, Product Backlog vẫn tiếp tục tồn tại để phản ánh các nhu cầu, phản hồi và cải tiến tiếp theo. Đáp án đúng: c) Khi sản phẩm được nghỉ hưu hoặc ngừng hoạt động Giải thích chi tiết: Theo Scrum Guide 2020, Product Backlog là “an emergent, ordered list of what is needed to improve the product” và là nguồn công việc duy nhất của Scrum Team. Scrum Guide cũng nêu rõ: “The Product Backlog exists as long as the product exists.” Điều này có nghĩa là Product Backlog không gắn với một dự án tạm thời, cũng không gắn với cá nhân Product Owner, mà gắn trực tiếp với sản phẩm. Nói cách khác, chừng nào sản phẩm còn tồn tại thì Product Backlog vẫn còn tồn tại. Chỉ khi sản phẩm được nghỉ hưu, ngừng vận hành hoặc không còn được duy trì nữa thì Product Backlog mới chấm dứt vai trò của nó. Vòng đời của Product Backlog: Product Backlog gắn liền với sản phẩm, không phải với con người hay một dự án cụ thể. Khi Product Owner thay đổi, Product Backlog vẫn được bàn giao và tiếp tục được quản lý bởi Product Owner mới. Khi ngân sách tạm thời cạn, Product Backlog vẫn tồn tại; nó có thể được tiếp tục khi tổ chức có nguồn lực trở lại. Khi phát hành một release, Product Backlog không kết thúc; ngược lại, nó thường tiếp tục chứa các hạng mục mới cho phiên bản tiếp theo. Product Backlog là một “living artifact”: nó luôn được tinh chỉnh liên tục (refinement); nó phản ánh hiểu biết hiện tại tốt nhất về nhu cầu của sản phẩm; nó thay đổi theo phản hồi từ khách hàng, stakeholders và thị trường; nó không bao giờ “hoàn tất” theo nghĩa truyền thống, trừ khi chính sản phẩm không còn tồn tại. Từ góc nhìn Scrum theory, Product Backlog là một artifact mang tính evolving và adaptive. Scrum được thiết kế để làm việc trong môi trường phức tạp, nơi yêu cầu thay đổi liên tục, vì vậy backlog phải sống cùng sản phẩm để hỗ trợ việc học hỏi, kiểm tra và thích nghi. Khi sản phẩm còn có giá trị, còn được cải tiến, còn được sử dụng, thì Product Backlog vẫn là công cụ trung tâm để sắp xếp và định hướng công việc. Nguyên tắc cần nhớ: Product Backlog = Product. Sản phẩm còn tồn tại thì Product Backlog còn tồn tại. Chỉ khi sản phẩm được retired/discontinued thì Product Backlog mới thực sự được “nghỉ hưu”.

Question 36 — Can the Product Owner Delegate Attendance at Sprint Review? The Product Owner cannot send a representative (delegate) to the Sprint Review. True or False? a) True — The Product Owner must always personally attend the Sprint Review b) False ✓ — Scrum does not prohibit the PO from delegating in all circumstances Đáp án đúng: b) Sai — Scrum không cấm PO ủy quyền trong mọi trường hợp Giải thích chi tiết: Theo Scrum Guide 2020: "The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals." Phân tích: Scrum Guide không quy định cứng nhắc rằng PO phải tự thân tham dự mọi event. PO có thể ủy quyền một số trách nhiệm, nhưng không thể ủy quyền trách nhiệm (accountability). Trong thực tế, PO có thể nhờ đại diện tham dự Sprint Review trong trường hợp đặc biệt. Tuy nhiên, cần lưu ý: PO tham dự Sprint Review là best practice và được khuyến nghị mạnh mẽ. Sprint Review là cơ hội quan trọng để PO nhận feedback và điều chỉnh Product Backlog. Nếu PO thường xuyên vắng mặt, đây là một impediment cần Scrum Master hỗ trợ xử lý. Phân biệt Accountability vs. Responsibility: Accountability (trách nhiệm giải trình): Không thể ủy quyền — PO luôn chịu trách nhiệm về kết quả. Responsibility (trách nhiệm thực hiện): Có thể ủy quyền một phần.

Question 37 — Technical Conditions from the Product Owner The Product Owner adds detailed technical specifications and constraints to Product Backlog Items. Is this appropriate? a) Yes — the Product Owner should define both business and technical requirements b) No — technical decisions belong exclusively to the Developers ✓ c) Yes — but only if the PO has a technical background d) No — only the Scrum Master can add technical constraints to backlog items Đáp án đúng: b) Không — quyết định kỹ thuật thuộc về Developers Giải thích chi tiết: Theo Scrum Guide 2020, Developers là những người trong Scrum Team cam kết tạo ra bất kỳ phần nào của một usable Increment trong mỗi Sprint. Scrum Guide cũng nêu rõ rằng Developers chịu trách nhiệm tạo Sprint Backlog, duy trì chất lượng thông qua Definition of Done, điều chỉnh kế hoạch hằng ngày theo Sprint Goal, và cùng nhau chịu trách nhiệm như những chuyên gia. Điều này có nghĩa là Scrum phân tách khá rõ giữa quyết định giá trị sản phẩm và quyết định kỹ thuật: Product Owner chịu trách nhiệm tối đa hóa giá trị của sản phẩm, xác định WHAT cần làm, WHY điều đó quan trọng, và sắp xếp thứ tự ưu tiên của Product Backlog. Developers chịu trách nhiệm về HOW — lựa chọn cách triển khai, kiến trúc, công nghệ, kỹ thuật hiện thực hóa, và ước lượng công việc. Phân chia trách nhiệm rõ ràng: 🎯 Product Owner quyết định: Tính năng nào cần xây dựng Tại sao tính năng đó tạo ra giá trị Thứ tự ưu tiên của Product Backlog Items 🔧 Developers quyết định: Cách thức kỹ thuật để implement Kiến trúc, công nghệ, design patterns Ước lượng effort và cách chia nhỏ công việc Tại sao PO không nên áp đặt kỹ thuật: Điều đó làm suy giảm tính tự quản lý của Developers. PO có thể không có đủ chiều sâu kỹ thuật cho các quyết định chuyên môn. Nó làm giảm ownership và trách nhiệm của Developers đối với giải pháp kỹ thuật. Lưu ý quan trọng theo Scrum theory: PO vẫn có thể nêu ràng buộc nghiệp vụ, mục tiêu chất lượng, yêu cầu phi chức năng hoặc mức chấp nhận ở cấp sản phẩm. Tuy nhiên, việc biến chúng thành thiết kế kỹ thuật chi tiết nên do Developers chủ động quyết định trong phạm vi Sprint và trong sự cộng tác với PO khi cần làm rõ.

Question 38 — Definition of Increment What is an Increment? a) The sum of all previous Increments integrated with Done PBIs from the latest Sprint ✓ b) Only the new features completed in the current Sprint c) The total number of story points completed in a Sprint d) A document describing what was built during the Sprint Đáp án đúng: a) Tổng giá trị của tất cả Increments trước đó tích hợp với Done PBIs trong Sprint mới nhất Giải thích chi tiết: Theo Scrum Guide 2020, Increment là một bước tiến cụ thể hướng tới Product Goal. Scrum Guide nêu rõ rằng mỗi Increment phải được additive so với tất cả các Increment trước đó, được kiểm tra đầy đủ để đảm bảo các Increment hoạt động cùng nhau, và phải usable để mang lại giá trị. Định nghĩa chính xác của Increment: Increment là tích lũy (cumulative), không phải chỉ phần mới nhất được hoàn thành trong Sprint hiện tại. Mỗi Sprint có thể tạo ra ít nhất một Increment; trong thực tế có thể có nhiều Increment nếu nhóm hoàn thành được các phần đạt chuẩn. Một Increment chỉ được công nhận khi các Product Backlog Items liên quan đã đáp ứng Definition of Done. Increment phải usable — tức là có thể sử dụng được, dù Product Owner chưa quyết định release ngay. Commitment của Increment: Definition of Done Theo Scrum Theory, Definition of Done (DoD) là tiêu chuẩn chất lượng mà Increment phải đáp ứng. DoD giúp đảm bảo tính minh bạch về chất lượng và tránh việc coi một phần công việc chưa hoàn chỉnh là “xong”. Nếu một PBI chưa đáp ứng DoD, nó không được xem là Increment và không nên được đưa vào Sprint Review như một phần hoàn tất. Phân biệt với các phương án sai: b) Chỉ các tính năng mới hoàn thành trong Sprint hiện tại → sai, vì Increment phải bao gồm cả những phần đã hoàn thành từ các Sprint trước. c) Tổng story points hoàn thành → sai, vì story points là thước đo ước lượng, không phải định nghĩa của Increment. d) Một tài liệu mô tả những gì đã xây dựng → sai, vì Increment là một phần sản phẩm thực tế, không phải tài liệu. Ví dụ minh họa: Sprint 1: Increment = Feature A (Done) Sprint 2: Increment = Feature A + Feature B (Done) — tích lũy Sprint 3: Increment = Feature A + Feature B + Feature C (Done) — tiếp tục tích lũy Kết luận: Increment trong Scrum không phải là “phần mới nhất” tách rời, mà là tổng hợp tích lũy của toàn bộ phần đã Done, được xây dựng theo chất lượng thống nhất và có khả năng sử dụng được ngay.

Question 39 — Sprint Goal and Product Backlog Items Which of the following statements are true? Select all that apply. a) The Scrum Team is responsible for crafting the Sprint Goal ✓ Correct. The Sprint Goal is created during Sprint Planning by the whole Scrum Team. The Product Owner brings the Product Goal and business intent, while Developers contribute technical insight and feasibility. b) The Sprint Goal is fixed and cannot change once the Sprint begins ✓ Correct. According to the Scrum Guide, the Sprint Goal is the single objective for the Sprint and remains stable throughout the Sprint. Scrum allows flexibility in how the work is done, but the Sprint Goal itself should not be changed during the Sprint. c) Product Backlog Items selected for the Sprint can be negotiated if the Sprint Goal is preserved ✓ Correct. Scrum separates goal from scope. The selected PBIs in the Sprint Backlog may be adapted, reordered, or renegotiated as needed, provided the Sprint Goal is still protected. This is one of the key forms of flexibility in Scrum. d) The Sprint Goal is created by the Product Owner alone before Sprint Planning Incorrect. The Sprint Goal is not created by the Product Owner alone in advance. It is formed collaboratively during Sprint Planning as a shared commitment for the Sprint. Đáp án đúng: a), b), c) Giải thích chi tiết: Theo Scrum Guide 2020, Sprint Goal là “the single objective for the Sprint”. Sprint Goal cung cấp sự tập trung chung cho toàn Scrum Team và tạo ra tính nhất quán giữa các công việc trong Sprint. Dù Sprint Goal là một commitment của Developers, nó vẫn phản ánh sự phối hợp của toàn bộ Scrum Team trong Sprint Planning. Scrum cũng nhấn mạnh rằng Sprint Goal tạo ra coherence và focus, giúp nhóm làm việc như một tập thể thay vì các cá nhân thực hiện những nhiệm vụ rời rạc. Đây là lý do vì sao Sprint Backlog có thể thay đổi về chi tiết thực hiện, nhưng mục tiêu Sprint phải được bảo vệ. Phân tích từng đáp án: a) Đúng: Sprint Goal được xây dựng bởi toàn Scrum Team trong Sprint Planning. Product Owner cung cấp định hướng từ Product Goal, còn Developers cùng thảo luận để xác định mục tiêu khả thi và có giá trị. b) Đúng: Khi Sprint đã bắt đầu, Sprint Goal được xem là cố định. Scrum Guide cho phép thay đổi cách làm và điều chỉnh phạm vi công việc, nhưng không thay đổi mục tiêu đã cam kết của Sprint. c) Đúng: Các Product Backlog Items được chọn cho Sprint có thể được thương lượng lại nếu cần, miễn là Sprint Goal vẫn được giữ vững. Nói cách khác, scope linh hoạt còn goal ổn định. d) Sai: Sprint Goal không do Product Owner tự tạo một mình trước Sprint Planning. Đây là kết quả của quá trình cộng tác trong Sprint Planning, với sự tham gia của cả Scrum Team. Kết luận: Trong Scrum, Sprint Goal là trục định hướng của Sprint. Mục tiêu này được tạo ra tập thể, giữ ổn định trong suốt Sprint, còn phạm vi PBI có thể linh hoạt điều chỉnh để bảo đảm mục tiêu chung.

Question 40 — Product Backlog Management Activities Which of the following is NOT a Product Backlog management activity? a) Clearly expressing and ordering Product Backlog Items This IS a management activity. b) Ensuring the Product Backlog is transparent and visible This IS a management activity. c) Assigning Product Backlog Items to specific Developers ✓ This is NOT a Product Backlog management activity. d) Refining Product Backlog Items to be smaller and more precise This IS a management activity. Đáp án đúng: c) Giao Product Backlog Items cho Developers cụ thể — Đây KHÔNG phải hoạt động quản lý Product Backlog Giải thích chi tiết: Theo Scrum Guide 2020, Product Owner chịu trách nhiệm đối với Product Backlog management một cách hiệu quả. Scrum Guide nêu rõ rằng việc quản lý Product Backlog bao gồm: phát triển và truyền đạt rõ Product Goal, tạo và diễn đạt rõ ràng các Product Backlog Items, sắp xếp thứ tự Product Backlog Items, và đảm bảo Product Backlog minh bạch, hiển thị và dễ hiểu. Nói cách khác, Product Backlog là một danh sách sống, liên tục được làm rõ và sắp xếp để phản ánh hiểu biết mới nhất về sản phẩm. Đây là công việc thuộc về quản lý giá trị và hướng đi của sản phẩm, không phải phân công cá nhân thực hiện từng hạng mục công việc. Các hoạt động quản lý Product Backlog theo Scrum Guide: Phát triển và truyền đạt Product Goal một cách rõ ràng để định hướng cho toàn bộ Product Backlog. Tạo và diễn đạt rõ ràng các Product Backlog Items để mọi người hiểu được nội dung và ý nghĩa của từng item. Sắp xếp thứ tự ưu tiên các PBIs dựa trên giá trị, rủi ro, phụ thuộc và phản hồi từ thị trường. Đảm bảo Product Backlog minh bạch, hiển thị và dễ hiểu đối với các bên liên quan. Product Backlog Refinement, tức là tinh chỉnh các PBIs để chúng nhỏ hơn, rõ hơn và sẵn sàng hơn cho việc lập kế hoạch. Tại sao c) không phải là hoạt động quản lý Product Backlog? Giao Product Backlog Items cho Developers cụ thể là cách quản lý theo kiểu truyền thống, không phù hợp với Scrum. Trong Scrum, Developers là nhóm tự quản lý; họ tự chọn cách làm và tự tổ chức công việc trong Sprint Backlog. Product Owner quản lý “WHAT” — sản phẩm cần gì, giá trị nào cần ưu tiên — chứ không quản lý “WHO” sẽ làm việc đó. Việc chỉ định task cho từng cá nhân làm giảm tính tự chủ của Developers và đi ngược tinh thần Scrum. Kết luận: Product Backlog management tập trung vào việc làm rõ sản phẩm, tối ưu hóa thứ tự ưu tiên và đảm bảo minh bạch. Giao việc cho Developers cụ thể không phải là một hoạt động Product Backlog management; đó là ranh giới quan trọng giữa Scrum và mô hình quản lý công việc theo kiểu chỉ huy–kiểm soát.

Các Vai Trò Cốt Lõi trong Scrum Scrum chỉ có 3 vai trò trong Scrum Team: Product Owner, Scrum Master và Developers. Theo Scrum Guide 2020, đây là một đội ngũ nhỏ, gắn kết, tự quản lý và đa chức năng, cùng chịu trách nhiệm tạo ra giá trị sản phẩm. Product Owner (PO) Chịu trách nhiệm tối đa hóa giá trị sản phẩm mà Scrum Team tạo ra, theo định hướng của Product Goal. Quản lý Product Backlog: tạo ra, làm rõ, sắp xếp thứ tự và truyền đạt (communicate) các Product Backlog Items để mọi người hiểu đúng điều cần làm. Là người duy nhất quyết định thứ tự ưu tiên của Product Backlog; không cá nhân hay nhóm nào có quyền override quyết định này. Phải là một người duy nhất, không phải một ủy ban hay tập thể ra quyết định thay cho PO. Có thể ủy quyền công việc như phân tích, viết mô tả, thu thập phản hồi; nhưng không thể ủy quyền trách nhiệm (accountability) về giá trị và Product Backlog. Kết nối nhu cầu kinh doanh, người dùng và các bên liên quan để đảm bảo sản phẩm đi đúng hướng. Tham khảo: Scrum Guide 2020, Scrum.org 4 PO là người chịu trách nhiệm tối đa hóa giá trị sản phẩm và quản lý Product Backlog. Scrum Master (SM) Servant-leader: phục vụ Scrum Team, hỗ trợ Product Owner, Developers và cả tổ chức để Scrum vận hành hiệu quả. Đảm bảo Scrum được hiểu và thực hành đúng, bao gồm các sự kiện Scrum, vai trò, artefacts và các cam kết đi kèm. Loại bỏ impediments và giúp nhóm xử lý trở ngại, đồng thời bảo vệ nhóm khỏi can thiệp bên ngoài gây gián đoạn việc tạo giá trị. Không phải Project Manager: Scrum Master không giao task, không <điều phối công việc= theo kiểu chỉ huy3kiểm soát, và không có quyền lực trực tiếp lên thành viên trong nhóm. Coaching, facilitation, teaching là công cụ chính: huấn luyện tổ chức, tạo điều kiện cho thảo luận, và dạy cách áp dụng Scrum tốt hơn. Giúp cải tiến liên tục bằng cách hỗ trợ Scrum Team inspect & adapt trong Sprint và qua các sự kiện Scrum. Tham khảo: Scrum Guide 2020, Scrum.org 4 Scrum Master là người chịu trách nhiệm thiết lập sự hiểu biết về Scrum và phục vụ hiệu quả của Scrum Team. Developers Tất cả những người tạo ra Increment đều là Developers 4 không chỉ là lập trình viên, mà còn có thể gồm kiểm thử, phân tích, thiết kế, DevOps và các kỹ năng cần thiết khác. Cross-functional: có đủ năng lực để deliver Increment <Done= mà không cần phụ thuộc vào nhóm bên ngoài cho công việc cốt lõi. Tự quản lý: tự chọn công việc, tự tổ chức, tự quyết định cách làm và phối hợp trong Sprint để đạt mục tiêu Sprint. Chịu trách nhiệm về chất lượng kỹ thuật và đảm bảo công việc đáp ứng Definition of Done. Không có sub-teams hay hierarchy trong Developers; Scrum khuyến khích một nhóm cộng tác ngang hàng, cùng chịu trách nhiệm về kết quả. Quyết định phạm vi công việc hằng ngày trong Sprint Backlog dựa trên tiến độ và mục tiêu, không phải do ai đó bên ngoài áp đặt. Tham khảo: Scrum Guide 2020, Scrum.org 4 Developers là những người làm công việc tạo ra Increment và cùng chịu trách nhiệm chất lượng của Increment. Ghi nhớ: Scrum Team = PO + SM + Developers. Không có vai trò nào khác trong Scrum framework. Theo các nguồn tham chiếu chính thống như Scrum Guide 2020 và Scrum.org, việc hiểu đúng vai trò giúp tránh nhầm lẫn với mô hình quản lý dự án truyền thống, nơi có thể có quản lý tuyến trên, trưởng nhóm, hay người phân công task.

Các Sự Kiện Scrum (5 Events) Theo Scrum Guide 2020, Scrum có 5 sự kiện chính, tất cả đều là timebox để tạo nhịp làm việc ổn định, hỗ trợ inspect & adapt liên tục, và giúp Scrum Team tập trung vào việc tạo ra giá trị trong mỗi Sprint. Sprint Container Event. Timebox tối đa 1 tháng lịch, và phải nhất quán trong suốt một Sprint. Scrum Guide 2020 quy định Sprint là “container” chứa tất cả các sự kiện khác: Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective. Sprint Planning Timebox: 8 giờ cho Sprint dài 1 tháng. Đây là sự kiện khởi đầu Sprint, nơi Scrum Team thống nhất mục tiêu và kế hoạch thực hiện. Topic 1 — WHY: Vì sao Sprint này có giá trị? → xác định Sprint Goal. Topic 2 — WHAT: Chọn các Product Backlog Items (PBIs) phù hợp từ Product Backlog. Topic 3 — HOW: Lập kế hoạch triển khai thành Sprint Backlog. Toàn bộ Scrum Team tham gia: Product Owner, Scrum Master và Developers. Daily Scrum Timebox: 15 phút mỗi ngày. Đây là sự kiện dành cho Developers; Scrum Master và Product Owner có thể tham dự nhưng không bắt buộc. Mục đích là inspect tiến độ so với Sprint Goal và điều chỉnh kế hoạch cho 24 giờ tiếp theo. Daily Scrum không phải status report cho management, mà là buổi làm việc nội bộ để Developers tự quản lý và phối hợp hiệu quả hơn. Sprint Review Timebox: 4 giờ cho Sprint dài 1 tháng. Scrum Team cùng các stakeholders inspect Increment đã hoàn thành. Đây là một working session, không phải buổi demo một chiều. Mục tiêu là thu thập phản hồi, trao đổi hướng đi tiếp theo, và tạo sự hiểu biết chung. Kết quả quan trọng: Product Backlog được điều chỉnh dựa trên phản hồi và những gì đã học được. Sprint Retrospective Timebox: 3 giờ cho Sprint dài 1 tháng. Đây là event cuối cùng của Sprint. Nhóm inspect cách làm việc của mình: process, tools và relationships. Kết quả là một kế hoạch cải tiến cụ thể để áp dụng trong Sprint tiếp theo, nhằm nâng cao hiệu quả và chất lượng cộng tác.

Ba Trụ Cột của Empiricism Theo Scrum Guide 2020, Scrum dựa trên empiricism (chủ nghĩa kinh nghiệm): ra quyết định bằng cách quan sát thực tế, kiểm tra thường xuyên, rồi điều chỉnh kịp thời. Ba trụ cột Transparency, Inspection và Adaptation là nền tảng giúp Scrum Team làm việc minh bạch, học nhanh và giảm rủi ro. 1 Minh Bạch Nền tảng Quá trình, tiến độ và công việc phải hiển thị rõ ràng với tất cả người liên quan. Trong Scrum Guide 2020, các Scrum Artifacts — Product Backlog, Sprint Backlog và Increment — là những công cụ tạo transparency. Các commitments đi kèm gồm Product Goal, Sprint Goal và Definition of Done giúp mọi người hiểu cùng một mục tiêu và cùng một chuẩn chất lượng. Khi thiếu transparency, thông tin bị che khuất, quyết định dễ sai lệch và rủi ro sẽ tăng dần theo thời gian. Nói cách khác: không nhìn thấy đúng thực trạng thì không thể quản lý hiệu quả. 2 Kiểm Tra Tầng giữa Inspection là việc kiểm tra thường xuyên các artifacts, tiến độ và kết quả để phát hiện sớm sai lệch so với mục tiêu. Trong Scrum, 5 Scrum Events đều là cơ hội inspection chính thức: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective và chính Sprint như một container cho toàn bộ công việc. Inspection phải được thực hiện đủ thường xuyên để phát hiện vấn đề kịp thời, nhưng không được quá dày đặc đến mức làm gián đoạn công việc. Người thực hiện inspection cần có kỹ năng và hiểu biết về bối cảnh để nhận ra đâu là sai lệch đáng chú ý, đâu là biến động bình thường. 3 Thích Nghi Đỉnh Khi inspection cho thấy sai lệch vượt quá ngưỡng chấp nhận, Scrum Team phải adaptation ngay — nghĩa là điều chỉnh sản phẩm, kế hoạch hoặc cách làm việc để quay lại đúng hướng. Nếu biết cần điều chỉnh mà không làm, nhóm sẽ lãng phí công sức và tích lũy rủi ro cho những Sprint sau. Sprint Retrospective là cơ hội thích nghi chính thức với process, tools và team collaboration. Ngoài ra, Sprint Planning, Daily Scrum và Sprint Review cũng là những thời điểm quan trọng để thích nghi với thông tin mới vừa được phát hiện. 5 Scrum Values theo Scrum Guide 2020: Commitment — cam kết đạt mục tiêu chung; Focus — tập trung vào công việc quan trọng nhất; Openness — sẵn sàng chia sẻ sự thật và vấn đề; Respect — tôn trọng con người, vai trò và ý kiến; Courage — dám nói thật, dám xử lý vấn đề và dám thay đổi khi cần. Ba trụ cột này phụ thuộc lẫn nhau: Không có Transparency → Inspection không hiệu quả → Adaptation không chính xác.

Scrum Artifacts và Commitments Theo Scrum Guide 2020, Scrum Artifacts giúp Scrum Team làm việc minh bạch về giá trị, công việc và chất lượng. Mỗi artifact có một commitment đi kèm để làm rõ mục tiêu cần bảo vệ: Product Backlog gắn với Product Goal, Sprint Backlog gắn với Sprint Goal, và Increment gắn với Definition of Done. Ba cặp này tạo thành khung quản trị cốt lõi để Scrum Team ra quyết định rõ ràng, thích nghi nhanh và giữ chất lượng ổn định. Product Backlog → Product Goal Product Backlog là danh sách có thứ tự của tất cả những gì được cho là cần thiết để cải thiện sản phẩm. Theo Scrum Guide 2020, đây là nguồn duy nhất của công việc cho Scrum Team: mọi việc làm thêm, thay đổi hoặc ưu tiên đều phải được phản ánh ở đây. Backlog này luôn tiến hóa (emergent) theo thông tin mới, phản hồi người dùng, thay đổi thị trường và học hỏi của nhóm. Vì vậy, nó không bao giờ hoàn chỉnh; nó chỉ được làm rõ và sắp xếp lại liên tục để phục vụ tốt hơn cho sản phẩm. Product Goal là mục tiêu dài hạn của sản phẩm — tức là <why= của Product Backlog. Nó cho biết sản phẩm đang hướng tới điều gì, tại sao các mục trong backlog lại quan trọng, và tiêu chí nào xác định tiến bộ. Scrum Team chỉ theo đuổi một Product Goal tại một thời điểm để giữ sự tập trung và thống nhất. Nói ngắn gọn: Product Backlog trả lời <chúng ta có thể làm gì tiếp theo?=, còn Product Goal trả lời <chúng ta đang đi đến đâu?=. Sprint Backlog → Sprint Goal Sprint Backlog là tập hợp những gì Developers chọn để thực hiện trong Sprint hiện tại. Theo Scrum Guide 2020, nó gồm 3 phần: Sprint Goal (WHY) + các PBIs được chọn (WHAT) + kế hoạch thực hiện (HOW). Sprint Backlog thuộc sở hữu của Developers; chỉ Developers có quyền thay đổi Sprint Backlog trong Sprint. Điều này giúp nhóm duy trì trách nhiệm thực thi và linh hoạt điều chỉnh kế hoạch khi hiểu biết mới xuất hiện. Trong thực tế, Sprint Backlog được cập nhật liên tục trong Sprint để phản ánh tình hình thật: tiến độ, trở ngại, phát hiện mới, hoặc cách làm tốt hơn. Vì vậy nó là một công cụ sống, không phải tài liệu cố định. Sprint Goal là mục tiêu duy nhất của Sprint. Nó tạo coherence (sự gắn kết) và focus (sự tập trung), giúp Developers biết điều gì là quan trọng nhất khi phải đưa ra trade-off trong quá trình thực hiện. Increment → Definition of Done Increment là tổng tích lũy của tất cả các Done PBIs từ Sprint hiện tại và tất cả Sprint trước đó. Mỗi Increment phải cộng dồn vào giá trị sản phẩm và phản ánh tiến bộ thực sự, không chỉ là công việc đã làm xong một phần. Theo Scrum Guide 2020, Increment phải usable — nghĩa là có thể sử dụng được, ngay cả khi Product Owner chưa quyết định release. Đây là điểm quan trọng: <Done= trong Scrum không chỉ là hoàn thành nội bộ, mà còn là đạt đến trạng thái có giá trị và sử dụng được. Trong một Sprint, Scrum Team có thể tạo ra nhiều Increments. Mỗi Increment đạt chuẩn đều làm tăng tính sẵn sàng của sản phẩm và có thể được kiểm tra, tích hợp, hoặc phát hành nếu phù hợp. Definition of Done là tiêu chuẩn chất lượng tối thiểu mà mọi Increment phải đáp ứng. Nó giúp cả nhóm có cùng một định nghĩa về <Done=, giảm tranh cãi, tránh nợ kỹ thuật và bảo đảm chất lượng nhất quán giữa các Sprint. Điểm cần nhớ từ Scrum Guide 2020: mỗi artifact đều gắn với một commitment để tăng tính minh bạch và định hướng. Nếu không có commitment, artifact chỉ là danh sách công việc; khi có commitment, nó trở thành công cụ quản trị mục tiêu, hành động và chất lượng. Bảng tóm tắt Artifact Owner Commitment Purpose Product Backlog Product Owner Product Goal Danh sách có thứ tự tất cả những gì cần thiết để cải thiện sản phẩm và định hướng giá trị dài hạn Sprint Backlog Developers Sprint Goal Kế hoạch làm việc của Sprint, giúp nhóm tập trung vào mục tiêu chung và thích nghi khi thực hiện Increment Whole Scrum Team Definition of Done Phần sản phẩm đã hoàn thiện và usable, đảm bảo chất lượng tối thiểu trước khi release

Những Điểm Dễ Nhầm Lẫn trong Scrum Scrum Guide 2020 và các tài liệu hướng dẫn từ Scrum.org đều nhấn mạnh rằng Scrum không phải là một bộ quy trình quản lý dự án truyền thống, mà là một framework giúp đội ngũ tự quản, minh bạch, kiểm tra và thích nghi liên tục. Nhiều hiểu lầm trong thực tế xuất phát từ việc áp dụng tư duy quản lý cũ vào Scrum. Dưới đây là 6 nhầm lẫn phổ biến nhất — kèm giải thích đúng để bạn tránh áp dụng sai. 1. <Scrum Master là Project Manager= Sai: Scrum Master không giao việc cho Developers, không kiểm soát timeline theo kiểu mệnh lệnh, và không phải là người đi báo cáo tiến độ cho management. Đúng: Theo Scrum Guide 2020, Scrum Master là servant- leader cho Scrum Team và tổ chức. Vai trò này tập trung vào coaching, facilitation, gỡ bỏ trở ngại, giúp mọi người hiểu và áp dụng Scrum đúng cách. Scrum Master tạo điều kiện để nhóm làm việc hiệu quả hơn, nhưng không sở hữu công việc của Developers. Nếu cần phối hợp với stakeholder hoặc management, Scrum Master hỗ trợ tạo sự hiểu đúng về Scrum, thay vì đóng vai <người chỉ huy dự án=. 2. <Daily Scrum là status report cho management= Sai: Daily Scrum không được tổ chức để Developers báo cáo cho Scrum Master hay cho quản lý <kiểm tra=. Cách hiểu này biến một sự kiện phục vụ nhóm thành một cuộc họp giám sát. Đúng: Theo Scrum Guide 2020, Daily Scrum là sự kiện dành cho Developers. Mục đích là inspect progress toward the Sprint Goal và adapt the Sprint Backlog nếu cần để tối ưu hóa kế hoạch cho 24 giờ tiếp theo. Scrum.org cũng nhấn mạnh rằng Daily Scrum giúp Developers tự điều phối công việc, phát hiện rủi ro sớm và phối hợp tốt hơn. Vì vậy, quản lý không nên xem đây là buổi <báo cáo trạng thái=, mà nên tôn trọng tính tự quản của nhóm. 3. <Sprint Goal có thể thay đổi trong Sprint= Sai: Sprint Goal không phải là mục tiêu có thể sửa tùy ý mỗi khi có thay đổi nhỏ. Nếu thay đổi liên tục, Sprint sẽ mất hướng và giảm tính tập trung. Đúng: Sau Sprint Planning, Sprint Goal là cố định trong suốt Sprint. Theo Scrum Guide 2020, mục tiêu này tạo coherence và giúp Scrum Team ra quyết định khi có trade-off. Điều có thể thương lượng trong Sprint là scope — tức các Product Backlog Items được chọn hoặc cách thực hiện chúng. Nếu phát sinh thay đổi, Developers và Product Owner có thể cùng trao đổi để điều chỉnh phạm vi, nhưng không làm thay đổi Sprint Goal một cách tùy tiện. 4. <Product Owner viết User Stories= Sai: Scrum không quy định rằng Product Owner phải tự viết User Stories, cũng không bắt buộc PBIs phải theo một định dạng cụ thể. User Story chỉ là một cách diễn đạt phổ biến, không phải luật của Scrum. Đúng: Product Owner chịu trách nhiệm maximizing the value of the product và đặc biệt là quản lý Product Backlog: làm rõ nội dung, sắp xếp thứ tự ưu tiên và bảo đảm backlog được hiểu đúng bởi toàn đội. Theo Scrum Guide 2020, PBIs có thể được mô tả bằng nhiều hình thức khác nhau: user story, requirement, bug, spike, hypothesis, hoặc bất kỳ cách nào giúp nhóm hiểu rõ giá trị cần tạo ra. Điều quan trọng là mục đích và chất lượng của thông tin, không phải mẫu câu. 5. <Velocity là cam kết của nhóm= Sai: Velocity không phải là lời hứa cố định, không phải KPI, và càng không nên dùng để ép nhóm <phải đạt số đó=. Khi bị biến thành chỉ tiêu, velocity dễ dẫn đến việc tối ưu con số thay vì tối ưu giá trị. Đúng: Velocity là công cụ dự báo dựa trên dữ liệu lịch sử của chính team. Nó giúp nhóm ước lượng năng lực tương đối và hỗ trợ lập kế hoạch Sprint hoặc dự báo roadmap ở mức phù hợp. Theo tư duy Scrum, Sprint Goal mới là cam kết về mục tiêu của Sprint, còn velocity chỉ là một tín hiệu tham khảo. Scrum.org cũng thường nhấn mạnh: velocity hữu ích cho forecasting, nhưng không được dùng như thước đo hiệu suất cá nhân hay cam kết chất lượng. 6. <Scrum = Agile= Sai: Scrum và Agile không phải là một. Nói <Scrum = Agile= là thu hẹp cả một tư duy quản trị và phát triển phần mềm rộng lớn chỉ còn một framework duy nhất. Đúng: Agile là một tư duy/triết lý về cách tạo ra giá trị trong môi trường thay đổi. Scrum là một framework Agile cụ thể, với vai trò, sự kiện, artifact và commitment rõ ràng. Ngoài Scrum còn có nhiều cách tiếp cận khác như Kanban, XP, hay các mô hình mở rộng như SAFe. Hiểu đúng mối quan hệ này giúp bạn chọn công cụ phù hợp với bối cảnh thay vì áp dụng máy móc. Agile là nguyên lý; Scrum là một cách triển khai nguyên lý đó. Ghi nhớ nhanh: Scrum Guide 2020 đặt trọng tâm vào self-managing teams, transparency, inspection và adaptation. Nếu một thực hành khiến Scrum Team phụ thuộc vào <người quản lý= để giao việc, báo cáo, hay quyết định thay cho nhóm, rất có thể bạn đang hiểu sai Scrum. Tóm tắt đúng – sai Nhầm lẫn Sai ở điểm nào? Hiểu đúng Scrum Master là Project Manager SM không giao việc, không quản lý tiến độ kiểu command- and-control SM là servant- leader, coach, facilitator và người hỗ trợ Scrum Team Daily Scrum là status report Daily Scrum không phải buổi báo cáo cho management Là sự kiện của Developers để inspect và adapt kế hoạch 24 giờ tiếp theo Sprint Goal đổi tùy ý

Nguyên Tắc Tự Quản Lý trong Scrum Tự quản lý (self-managing) là một đặc điểm cốt lõi của Scrum Team. Theo Scrum Guide 2020, “Scrum Teams are self- managing, meaning they internally decide who does what, when, and how.” Nói cách khác, nhóm có quyền tự quyết định WHO, WHEN và HOW ở bên trong team — nhưng không tự ý quyết định WHAT cần làm. Định nghĩa chính xác Theo Scrum Guide 2020, Scrum Team là self-managing, tức là các thành viên tự quyết định nội bộ ai làm việc gì, khi nào làm và làm như thế nào. WHO: Ai phù hợp nhất để làm việc đó? WHEN: Việc nào nên làm trước, việc nào làm sau? HOW: Cách phối hợp, kỹ thuật và phương pháp thực hiện ra sao? Điểm quan trọng là tự quản lý không có nghĩa là tự đặt mục tiêu sản phẩm hay tự thay đổi định hướng kinh doanh. WHAT vẫn thuộc phạm vi do Product Owner chịu trách nhiệm quản lý thông qua Product Backlog và Product Goal. Phạm vi tự quản lý Được phép: Developers tự chọn công việc từ Sprint Backlog phù hợp với năng lực và mục tiêu của Sprint. Được phép: Nhóm tự tổ chức cách làm việc nội bộ, ví dụ cách chia nhỏ công việc, cách phối hợp và cách kiểm tra chất lượng. Được phép: Nhóm tự chọn công cụ, kỹ thuật, quy ước làm việc hoặc cách triển khai phù hợp với bối cảnh. Được phép: Nhóm tự ước lượng effort hoặc độ phức tạp để hỗ trợ lập kế hoạch và dự báo. Không được: Developers tự quyết định WHAT cần làm thay cho Product Owner. Không được: Tự thay đổi Scrum framework tùy ý, bỏ sự kiện bắt buộc hoặc vô hiệu hóa các artifact/commitment của Scrum. Không được: Để bên ngoài team áp đặt cách làm vi mô đến mức triệt tiêu tính tự quản. Nói ngắn gọn: tự quản lý là team quyết định cách làm, chứ không phải tự ý đổi mục tiêu hoặc quy tắc của Scrum. Điều kiện để tự quản lý hiệu quả Cross-functional: Scrum Team cần có đủ kỹ năng để tạo ra Increment mà không phụ thuộc quá nhiều vào bên ngoài. Được trao quyền thực sự: Tổ chức phải trao quyền thật, không chỉ nói “các bạn tự chủ” nhưng vẫn duyệt từng chi tiết. Có mục tiêu rõ ràng: Sprint Goal và Product Goal giúp nhóm biết đang tối ưu cho điều gì. Có accountability: Nhóm chịu trách nhiệm về kết quả, chất lượng và khả năng hoàn thành cam kết của Sprint. Khi bốn điều kiện này được đáp ứng, tự quản lý sẽ trở thành năng lực giúp team ra quyết định nhanh hơn, phối hợp tốt hơn và thích nghi tốt hơn với thay đổi. Vai trò của Scrum Master trong tự quản lý Theo Scrum Guide 2020, Scrum Master không phải là người “ra lệnh” hay “quản hộ” team. Vai trò đúng là tạo điều kiện để nhóm học cách tự quản lý và làm việc hiệu quả hơn. Bảo vệ nhóm khỏi các can thiệp bên ngoài làm gián đoạn Sprint hoặc phá vỡ focus. Coaching để nhóm phát triển kỹ năng tự tổ chức, tự phối hợp và tự giải quyết vấn đề. Loại bỏ impediments hoặc hỗ trợ team gỡ bỏ rào cản cản trở khả năng tự quản lý. Không giải quyết hộ mọi vấn đề, mà giúp nhóm có năng lực tự giải quyết bằng cách đúng. Nếu Scrum Master liên tục thay nhóm quyết định, team sẽ phụ thuộc vào một “người quản lý trá hình” thay vì trở thành một Scrum Team thực sự tự quản. Anti-patterns phổ biến Manager giao task trực tiếp cho Developers thay vì để team tự chọn công việc từ Sprint Backlog. Product Owner áp đặt giải pháp kỹ thuật thay vì tập trung vào giá trị, mục tiêu và thứ tự ưu tiên của Product Backlog. Scrum Master quyết định thay cho nhóm từ cách làm việc đến cách xử lý vấn đề, làm giảm tính tự chủ. “Tự quản” nhưng vẫn bị duyệt từng bước, khiến team chỉ có danh nghĩa tự chủ chứ không có quyền thực sự. Khi gặp các anti-pattern này, hãy quay lại nguyên tắc của Scrum Guide 2020: Scrum Team tự quản lý nội bộ, nhưng vẫn hoạt động trong khuôn khổ Scrum, với vai trò rõ ràng của Product Owner, Scrum Master và Developers. Ghi nhớ nhanh: Tự quản lý trong Scrum không phải là “muốn làm gì thì làm”. Đó là năng lực của Scrum Team trong việc tự quyết định cách thực hiện công việc để đạt mục tiêu chung, trong khi vẫn tôn trọng Product Goal, Sprint Goal và các nguyên tắc của Scrum Guide 2020.

Kích Thước Scrum Team Tối Ưu 10 Tối đa thành viên Scrum Team nên có 10 người hoặc ít hơn, bao gồm Product Owner, Scrum Master và Developers, để giữ cho việc phối hợp đơn giản và hiệu quả. 3 Tối thiểu Developers Nên có ít nhất 3 Developers để đảm bảo nhóm có đủ đa dạng kỹ năng, có thể hỗ trợ lẫn nhau và không phụ thuộc quá nhiều vào bên ngoài. 1 Product Owner duy nhất Mỗi sản phẩm chỉ nên có 1 Product Owner chịu trách nhiệm tối ưu hóa giá trị và quản lý Product Backlog. 1 Scrum Master duy nhất Mỗi Scrum Team có 1 Scrum Master; vai trò này có thể phục vụ nhiều team nếu bối cảnh tổ chức cho phép. Tại sao tối đa 10 người? Theo Scrum Guide 2020, một Scrum Team thường có 10 người hoặc ít hơn. Đây không phải là con số “cứng” để quản lý theo kiểu hành chính, mà là giới hạn thực tế nhằm giữ cho nhóm đủ nhỏ để giao tiếp nhanh, ra quyết định gọn và duy trì sự đồng thuận chung. Nhóm càng lớn, chi phí giao tiếp càng tăng mạnh. Với n người, số kênh giao tiếp tiềm năng là n(n-1)/2. Khi số người tăng, số mối liên hệ cần phối hợp tăng rất nhanh, khiến việc đồng bộ trở nên tốn thời gian. Khó duy trì cohesion và shared understanding. Nhóm quá đông dễ dẫn đến việc mỗi người hiểu Sprint Goal, chất lượng kỳ vọng hoặc cách làm việc theo một cách khác nhau. Daily Scrum và các sự kiện Scrum kém hiệu quả hơn. Khi có quá nhiều người, mỗi sự kiện cần nhiều thời gian hơn để cập nhật, thảo luận và chốt quyết định. Quá đông cũng làm giảm tính linh hoạt. Scrum Team sẽ khó tự tổ chức nhanh, khó xoay chuyển khi ưu tiên thay đổi hoặc khi phát sinh rủi ro bất ngờ. Nói ngắn gọn, 10 người hoặc ít hơn giúp Scrum Team giữ được nhịp làm việc nhanh, tập trung và có trách nhiệm chung rõ ràng. Tại sao tối thiểu 3 Developers?Scrum Guide 2020 không còn quy định cứng nhắc “3-9 Developers” như các phiên bản cũ, nhưng trên thực tế, ít hơn 3 Developers thường làm giảm sức mạnh của nhóm. Mục tiêu là bảo đảm nhóm có đủ năng lực để tạo ra Increment có giá trị trong mỗi Sprint. Thiếu đa dạng kỹ năng. Một nhóm quá nhỏ dễ thiếu các năng lực cần thiết như phân tích, thiết kế, lập trình, kiểm thử, DevOps hoặc nghiệp vụ. Tăng phụ thuộc bên ngoài. Khi thiếu người, team thường phải nhờ nhiều vào các nhóm khác, làm giảm khả năng tự quản và tốc độ giao hàng. Rủi ro cao khi có người nghỉ. Chỉ cần một thành viên vắng mặt là tiến độ, kiến thức hoặc năng lực thực thi có thể bị ảnh hưởng đáng kể. Giảm tương tác và sáng tạo. Ít người quá có thể làm giảm góc nhìn, ít phản biện, ít trao đổi ý tưởng và hạn chế khả năng tìm ra giải pháp tốt hơn. Vì vậy, 3 Developers trở lên thường là mức tối thiểu hợp lý để tạo ra sự cân bằng giữa đa dạng kỹ năng, khả năng cộng tác và độ bền vững của team. Khi cần nhiều hơn 10 người? Nếu khối lượng công việc hoặc phạm vi sản phẩm quá lớn, cách tiếp cận phù hợp không phải là “nới” Scrum Team vượt xa giới hạn, mà là tách thành nhiều Scrum Team nhỏ hơn. Điều này giúp giữ nguyên tính linh hoạt của Scrum trong khi vẫn mở rộng quy mô. Tách thành nhiều Scrum Team nhỏ hơn. Mỗi team vẫn giữ cấu trúc Scrum đầy đủ và duy trì quy mô nhỏ để cộng tác hiệu quả. 1. Chia sẻ cùng Product Backlog và Product Owner. Nhiều team có thể làm việc trên cùng một sản phẩm, với một Product Owner duy nhất chịu trách nhiệm tối ưu hóa giá trị. 2. Áp dụng scaling frameworks khi cần. Các khung như LeSS, Nexus hoặc SAFe có thể hỗ trợ phối hợp ở quy mô lớn hơn. 3. Tổ chức Scrum of Scrums để đồng bộ hóa. Cơ chế này giúp các team chia sẻ phụ thuộc, rủi ro và tiến độ mà không làm mất đi sự tự quản ở cấp team. 4. Điểm mấu chốt là: mở rộng quy mô bằng cách nhân bản các team nhỏ, thay vì phình to một team duy nhất đến mức khó kiểm soát. Lưu ý theo Scrum Guide 2020 Scrum Guide 2020 không còn quy định cứng “3-9 Developers”. Thay vào đó, Guide chỉ nêu rằng Scrum Team typically has 10 or fewer people. Nghĩa là trọng tâm không nằm ở một con số máy móc, mà ở việc giữ team đủ nhỏ để tối ưu giao tiếp, tự quản và tạo ra giá trị trong Sprint. Vì vậy, khi đánh giá kích thước Scrum Team, hãy ưu tiên các câu hỏi sau: team có tự tổ chức tốt không? có đủ kỹ năng để tạo Increment không? có giao tiếp hiệu quả không? Nếu câu trả lời là “không”, đó là dấu hiệu cần điều chỉnh cấu trúc team thay vì chỉ tăng người. Tóm lại: Scrum Team lý tưởng là nhỏ nhưng đủ năng lực — đủ nhỏ để phối hợp nhanh, đủ lớn để hoàn thành công việc có ý nghĩa, và đủ rõ vai trò để duy trì trách nhiệm chung theo Scrum Guide 2020.

Vòng Đời Sprint Sprint Planning Sprint Execution Sprint Review Sprint Retrospective Mỗi Sprint là một chu kỳ hoàn chỉnh từ lập kế hoạch, thực thi, kiểm tra đến cải tiến. Theo Scrum Guide 2020, Sprint là một container cho toàn bộ các sự kiện Scrum và là nơi đội ngũ tạo ra một Increment có giá trị. Điều quan trọng nhất: Sprint mới bắt đầu ngay sau khi Sprint cũ kết thúc — không có “thời gian nghỉ” giữa các Sprint. 1) Sprint Planning — Đầu SprintSprint Planning là sự kiện mở đầu Sprint, nơi Scrum Team quyết định tại sao Sprint này quan trọng, làm gì trong Sprint và làm như thế nào. Theo Scrum Guide 2020, sự kiện này được giới hạn thời gian tối đa là 8 giờ cho Sprint 1 tháng (tương đương quy đổi 2 giờ mỗi tuần Sprint). WHY — Sprint Goal: Nhóm xác định mục tiêu Sprint để thống nhất giá trị cần đạt được. Sprint Goal giúp mọi người có cùng một hướng ưu tiên trong suốt Sprint. WHAT — Product Backlog Items (PBIs): Developers và Product Owner cùng chọn các PBIs có thể hoàn thành trong Sprint, dựa trên mục tiêu Sprint, năng lực hiện có và tình hình Product Backlog. HOW — Kế hoạch thực hiện: Developers xây dựng cách làm việc cụ thể để biến các PBIs đã chọn thành Increment, bao gồm chia nhỏ công việc, nhận diện rủi ro và phối hợp kỹ thuật. Output của Sprint Planning là Sprint Goal và Sprint Backlog. Sprint Backlog gồm các PBIs đã chọn, kế hoạch để hoàn thành chúng và phần công việc cần thiết để tạo ra Increment. 2) Sprint Execution — Trong Sprint Đây là giai đoạn dài nhất của chu kỳ, nơi Developers thực hiện công việc đã cam kết để tạo ra Increment “Done” theo Definition of Done. Trong suốt Sprint, team vừa làm vừa kiểm tra và điều chỉnh cách làm để tiến gần hơn đến Sprint Goal. Daily Scrum: 15 phút mỗi ngày — đây là thời gian để Developers inspect & adapt kế hoạch cho 24 giờ tiếp theo, không phải buổi báo cáo tiến độ cho quản lý. Developers tự tổ chức và thực hiện công việc. Scrum khuyến khích team tự quyết định ai làm gì, khi nào và theo cách nào để đạt Sprint Goal. Sprint Backlog được cập nhật liên tục. Khi có thông tin mới, ước lượng mới hoặc trở ngại mới, Developers điều chỉnh Sprint Backlog để phản ánh hiện trạng thực tế. Product Owner có thể làm rõ yêu cầu để giúp team hiểu đúng PBIs, nhưng không thay đổi Sprint Goal tùy tiện trong Sprint. Không ai được thêm công việc vào Sprint nếu không có sự đồng ý của Developers. Việc thay đổi phạm vi phải được cân nhắc theo mục tiêu Sprint và năng lực còn lại của team. Nói cách khác, Sprint Execution là giai đoạn thực hiện có kiểm soát: team tập trung tạo ra giá trị, đồng thời liên tục học hỏi và điều chỉnh mà vẫn giữ ổn định Sprint Goal. 3) Sprint Review — Cuối Sprint, trước RetroSprint Review diễn ra vào cuối Sprint để xem xét Increment đã tạo ra và nhận phản hồi từ stakeholders. Theo Scrum Guide 2020, sự kiện này có timebox tối đa là 4 giờ cho Sprint 1 tháng. Inspect Increment với stakeholders. Team trình bày những gì đã hoàn thành, những gì chưa hoàn thành và giá trị đã tạo ra trong Sprint. Thu thập phản hồi thực tế. Stakeholders góp ý về hướng đi, nhu cầu mới, cơ hội mới hoặc thay đổi ưu tiên. Adapt Product Backlog dựa trên feedback. Product Owner dùng thông tin từ Review để điều chỉnh Product Backlog cho phù hợp với thực tế sản phẩm và thị trường. Output quan trọng của Sprint Review là Product Backlog đã được điều chỉnh. Đây là nơi Scrum Team và stakeholders cùng nhìn lại sản phẩm để quyết định bước tiếp theo, chứ không phải chỉ “demo cho xong”. 4) Sprint Retrospective — Cuối Sprint, sau ReviewSprint Retrospective là sự kiện cuối cùng của Sprint, diễn ra ngay sau Review, nhằm cải tiến cách làm việc của Scrum Team. Theo Scrum Guide 2020, timebox tối đa là 3 giờ cho Sprint 1 tháng. Inspect People, Processes, Tools, Interactions, DoD. Team xem xét điều gì đang hỗ trợ tốt và điều gì đang cản trở hiệu quả làm việc. Tập trung vào cải tiến cụ thể. Mục tiêu không phải là than phiền, mà là tìm hành động thiết thực để làm Sprint tiếp theo tốt hơn. Output là kế hoạch cải tiến rõ ràng. Team xác định các hành động ưu tiên cho Sprint tới, có thể là thay đổi trong quy trình, công cụ, phối hợp hoặc kỹ thuật làm việc. Ít nhất một cải tiến quan trọng nên được đưa vào Sprint Backlog của Sprint tiếp theo để bảo đảm việc cải tiến thực sự được thực hiện. Retrospective giúp Scrum Team không chỉ tạo ra sản phẩm tốt hơn, mà còn trở nên tốt hơn sau mỗi Sprint. Nguyên tắc quan trọng: Không có khoảng nghỉ giữa các Sprint Theo Scrum Guide 2020, khi một Sprint kết thúc, Sprint tiếp theo bắt đầu ngay lập tức. Điều này có nghĩa là không tồn tại “thời gian nghỉ” giữa hai Sprint để chờ đợi, làm thủ tục hay tạm ngưng nhịp làm việc. Nhịp Scrum là một dòng chảy liên tục: Planning → Execution → Review → Retrospective → Sprint mới. Tóm lại: Sprint là một vòng lặp ngắn, rõ mục tiêu và liên tục học hỏi. Nếu Planning giúp team chọn đúng việc, Execution giúp team tạo ra Increment, Review giúp team nhận phản hồi, thì Retrospective giúp team cải tiến cách làm việc để Sprint sau tốt hơn Sprint trước.

Phân Rã Dọc vs Ngang trong Scrum Trong Scrum Guide 2020, mục tiêu của mỗi Sprint là tạo ra một Increment có giá trị và usable (có thể sử dụng được). Điều đó có nghĩa là sau mỗi Sprint, Scrum Team nên tạo ra một phần sản phẩm hoàn chỉnh đủ để stakeholders có thể xem xét, phản hồi, và trong nhiều trường hợp có thể dùng ngay. Theo các Agile principles, đặc biệt là nguyên tắc deliver working software frequently và continuous attention to technical excellence, cách chia việc quan trọng không kém việc làm gì. Hai cách phổ biến là phân rã ngang và phân rã dọc. ❌ Phân Rã Ngang (Horizontal) — Anti- pattern Chia theo tầng kỹ thuật, tức là tách công việc theo lớp kiến trúc thay vì theo giá trị người dùng. Cách này thường khiến mỗi Sprint chỉ hoàn thành một phần hạ tầng nội bộ, nhưng chưa có tính năng nào dùng được trọn vẹn. Ví dụ điển hình: Sprint 1: Data Layer cho tất cả tính năng Sprint 2: Business Logic cho tất cả tính năng Sprint 3: UI Layer cho tất cả tính năng Vấn đề chính: Không tạo ra Increment có giá trị sau mỗi Sprint Stakeholders không thể sử dụng hay đánh giá kết quả một cách thực tế Vi phạm tinh thần của usable Increment trong Scrum Guide 2020 Sprint Goal dễ trở nên mơ hồ, thuần kỹ thuật và không gắn với giá trị kinh doanh Tạo ra dependencies giữa các Sprint: Sprint sau phải chờ Sprint trước hoàn tất mới tạo ra giá trị Làm phản hồi đến muộn, khiến rủi ro tích lũy và khó điều chỉnh hướng đi Hệ quả thực tế: team có thể “bận rộn” trong nhiều Sprint nhưng vẫn chưa có gì thật sự hoàn chỉnh để demo, release, hoặc học từ người dùng. Đây là cách làm dễ dẫn đến progress illusion — tưởng là đang tiến bộ nhưng giá trị chưa được chứng minh. Kết luận: Phân rã ngang thường tối ưu cho cấu trúc kỹ thuật nội bộ, nhưng không tối ưu cho mục tiêu Agile là tạo giá trị sớm, học nhanh và thích nghi liên tục. ✅ Phân Rã Dọc (Vertical) — Đúng theo Scrum Chia theo tính năng/chức năng end-to-end, nghĩa là mỗi Sprint tập trung hoàn thành một lát cắt hoàn chỉnh của sản phẩm từ dữ liệu, logic đến giao diện. Đây là cách giúp team tạo ra một Increment có thể kiểm tra, sử dụng và phản hồi ngay. Ví dụ điển hình: Sprint 1: Tính năng A hoàn chỉnh (Data + Logic + UI) Sprint 2: Tính năng B hoàn chỉnh (Data + Logic + UI) Sprint 3: Tính năng C hoàn chỉnh (Data + Logic + UI) Lợi ích: Mỗi Sprint tạo ra Increment có thể sử dụng Stakeholders nhận được giá trị sớm và liên tục Sprint Goal có ý nghĩa kinh doanh rõ ràng, dễ truyền thông và dễ ưu tiên Phản hồi sớm từ stakeholders giúp team điều chỉnh hướng đi kịp thời Giảm rủi ro tích lũy vì giả định, phụ thuộc và vấn đề kỹ thuật được phát hiện sớm hơn Phù hợp hơn với các Agile principles như thường xuyên giao sản phẩm hoạt động và thích ứng với thay đổi Kết luận: Phân rã dọc không chỉ “đẹp” về mặt Agile mà còn giúp Scrum Team học nhanh hơn, kiểm soát rủi ro tốt hơn và tạo ra giá trị kinh doanh thật sự sau mỗi Sprint. Ghi nhớ theo Scrum Guide 2020: Sprint không phải là nơi hoàn thành một mảng kỹ thuật, mà là nơi tạo ra một Increment “Done” và usable. Nếu một Sprint chưa tạo được giá trị mà người dùng/stakeholders có thể quan sát hoặc khai thác, thì team nên xem lại cách slicing công việc. Kỹ thuật hỗ trợ phân rã dọc: User Story Mapping, Story Slicing, Walking Skeleton

Quản Lý Gián Đoạn trong Sprint Theo Scrum Guide 2020, Sprint là một khoảng thời gian ngắn, cố định để tạo ra một Increment có giá trị. Vì vậy, khi có yêu cầu hoặc gián đoạn từ bên ngoài, mục tiêu không phải là “phản ứng nhanh với mọi thứ”, mà là bảo vệ Sprint Goal, giữ cho nhóm tập trung, và chỉ thay đổi khi thực sự cần thiết. Cách xử lý gián đoạn đúng chuẩn Scrum phụ thuộc vào loại gián đoạn, mức độ ảnh hưởng đến Sprint Goal, và vai trò chịu trách nhiệm. 01 Bước 1: Nhận diện loại gián đoạn Không phải mọi yêu cầu đều nên xử lý ngay trong Sprint. Trước tiên, cần xác định gián đoạn đến từ đâu và nó thuộc nhóm nào: Yêu cầu từ bên ngoài: manager, stakeholder khác, bộ phận kinh doanh, khách hàng nội bộ Bug nghiêm trọng: lỗi production, lỗi ảnh hưởng doanh thu, bảo mật, hoặc trải nghiệm người dùng Thay đổi yêu cầu từ Product Owner: PO muốn điều chỉnh ưu tiên hoặc thêm/bớt công việc Thành viên nhóm bị kéo sang dự án khác: mất năng lực của Developers trong khi Sprint vẫn đang chạy Mỗi loại có cách phản ứng khác nhau. Ví dụ, một bug production nghiêm trọng có thể là impediment cần xử lý ngay, trong khi một yêu cầu “hỗ trợ gấp” từ stakeholder thường chỉ là một interrupt cần được lọc qua cơ chế Scrum. 02 Bước 2: Đánh giá tác động đến Sprint Goal Scrum Guide 2020 nhấn mạnh rằng Sprint Goal là cam kết trung tâm của Sprint. Vì vậy, câu hỏi đầu tiên không phải là “có làm ngay được không?” mà là: Gián đoạn này có ảnh hưởng trực tiếp đến Sprint Goal không? Nó có làm mất khả năng hoàn thành các công việc đã cam kết không? Nó có tạo ra rủi ro lớn hơn nếu trì hoãn sang Sprint sau không? Nếu không ảnh hưởng đến Sprint Goal, team có thể xử lý linh hoạt trong phạm vi hợp lý, miễn là không phá vỡ nhịp Sprint. Nếu có ảnh hưởng, cần leo thang ngay cho Scrum Master và Product Owner để ra quyết định rõ ràng, thay vì để Developers tự xử lý theo cảm tính. 03 Bước 3: Xử lý theo vai trò Trong Scrum, mỗi vai trò có một trách nhiệm riêng khi gián đoạn xảy ra: Developers: thông báo cho Scrum Master và Product Owner khi có gián đoạn đáng kể; không tự ý thay đổi Sprint Backlog hoặc ưu tiên công việc theo yêu cầu bên ngoài Scrum Master: bảo vệ nhóm khỏi các tác động làm nhiễu Sprint, làm việc với người yêu cầu để làm rõ mức độ khẩn cấp, và loại bỏ impediment nếu đó thật sự là rào cản của team Product Owner: quyết định liệu có nên thêm, bỏ hoặc thay đổi Product Backlog Item (PBI) hay không; đồng thời bảo vệ Sprint Goal và tối đa hóa giá trị sản phẩm Nói ngắn gọn: Developers tập trung vào việc làm, Scrum Master tập trung vào việc bảo vệ và tháo gỡ cản trở, còn Product Owner chịu trách nhiệm ưu tiên và quyết định giá trị. 04 Bước 4: Thương lượng scope nếu cần Nếu gián đoạn buộc team phải đưa thêm công việc vào Sprint, Scrum Guide 2020 cho phép Product Owner và Developers cùng thương lượng lại phạm vi miễn là Sprint Goal vẫn được bảo toàn. Nếu thêm một việc mới, team nên xem xét bỏ một PBI khác có effort tương đương Không nên “chồng thêm” công việc mà không loại bớt việc cũ, vì sẽ làm Sprint quá tải Nếu thay đổi làm Sprint Goal không còn khả thi, cần báo ngay cho PO để xem xét phương án khác Điểm quan trọng là: scope có thể được điều chỉnh, nhưng Sprint Goal không nên bị hy sinh một cách tùy tiện. Thương lượng phạm vi phải dựa trên giá trị, năng lực thực tế của Developers, và ảnh hưởng đến Increment cuối Sprint. 05 Bước 5: Hủy Sprint, chỉ trong trường hợp cực đoan Theo Scrum Guide 2020, chỉ Product Owner mới có quyền hủy Sprint. Đây là quyết định cực đoan và chỉ nên xảy ra khi Sprint Goal trở nên lỗi thời hoàn toàn, tức là tiếp tục Sprint cũng không còn tạo ra giá trị phù hợp nữa. Hủy Sprint không phải là công cụ xử lý gián đoạn thường ngày Hủy Sprint rất tốn kém vì làm mất nhịp làm việc, tốn công tái lập kế hoạch, và ảnh hưởng tinh thần nhóm Trước khi hủy, nên cân nhắc mọi phương án khác như thương lượng scope, giảm phạm vi, hoặc chuyển việc sang Sprint sau Vì vậy, hủy Sprint là phương án cuối cùng, không phải phản xạ đầu tiên khi có áp lực từ bên ngoài. 06 Bước 6: Học hỏi trong Sprint Retrospective Gián đoạn trong Sprint không chỉ là vấn đề vận hành, mà còn là cơ hội để cải tiến hệ thống làm việc. Trong Sprint Retrospective, team nên cùng nhau phân tích: Nguyên nhân gốc rễ của gián đoạn đến từ đâu? Gián đoạn nào là do quy trình, gián đoạn nào là do giao tiếp, và gián đoạn nào là do kỳ vọng chưa rõ? Có thể làm gì để giảm số lần bị ngắt quãng trong Sprint tới? Ví dụ cải tiến có thể là: thiết lập rõ kênh liên lạc với stakeholder, thống nhất quy tắc xử lý bug production, hoặc tăng độ minh bạch của Sprint Goal để các bên liên quan hiểu khi nào nên và không nên làm gián đoạn team. Mục tiêu của Retro là giúp team giảm gián đoạn trong tương lai và duy trì khả năng tạo ra Increment ổn định, liên tục. Ghi nhớ theo Scrum Guide 2020: Developers chịu trách nhiệm quản lý Sprint Backlog trong suốt Sprint; Product Owner chịu trách nhiệm với Product Backlog và quyền hủy Sprint; Scrum Master hỗ trợ Scrum Team và giúp tổ chức hiểu Scrum. Khi có gián đoạn, hãy ưu ti

Definition of Done — Tiêu Chí Chất Lượng Definition of Done (DoD) là mô tả chính thức về trạng thái của một Increment khi nó đã đáp ứng các mức chất lượng cần thiết cho sản phẩm. Theo Scrum Guide 2020, DoD là một phần quan trọng để tạo ra minh bạch, giúp cả nhóm hiểu rõ khi nào một phần việc thực sự được xem là hoàn thành. Nói cách khác, DoD không phải là một checklist tùy ý; nó là cam kết chất lượng chung mà Scrum Team phải dựa vào để đảm bảo Increment đủ tin cậy để sử dụng, kiểm tra hoặc phát hành. Định nghĩa (Scrum Guide 2020)“The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.” Diễn giải đơn giản: DoD mô tả trạng thái “đã xong thật sự” của Increment. Một công việc chỉ được xem là Done khi nó đạt tất cả tiêu chuẩn chất lượng đã thỏa thuận, chứ không phải chỉ khi code đã viết xong hay task đã được kéo sang cột hoàn thành. Điểm quan trọng là DoD giúp team tránh tình trạng “xong trên giấy nhưng chưa xong về chất lượng”. Ai tạo ra DoD? Theo Scrum Guide 2020, Scrum Team là bên chịu trách nhiệm về DoD. Cách áp dụng cụ thể như sau: Nếu tổ chức đã có tiêu chuẩn chất lượng: Scrum Team phải tuân theo như mức tối thiểu. DoD của team không được thấp hơn tiêu chuẩn chung của tổ chức. Nếu tổ chức chưa có tiêu chuẩn rõ ràng: Scrum Team tự xây dựng DoD để phù hợp với sản phẩm, công nghệ, và mức độ rủi ro. Developers là người chịu trách nhiệm trực tiếp trong việc tuân thủ DoD mỗi khi tạo Increment. Nói ngắn gọn: DoD không phải do một cá nhân tự đặt ra. Nó là thỏa thuận chất lượng của cả Scrum Team, và Developers phải đảm bảo mọi Increment đều đáp ứng nó. Ví dụ DoD thực tế Một DoD tốt thường bao gồm các tiêu chí kiểm chứng được, ví dụ: Code được review bởi ít nhất 1 Developer khác Unit tests pass với coverage ≥ 80% Integration tests pass Code được merge vào main branch Documentation được cập nhật nếu có thay đổi ảnh hưởng đến người dùng hoặc team vận hành Performance đạt chuẩn đã định trước Security scan không có critical issues Những tiêu chí này giúp chất lượng trở nên cụ thể, đo được, và nhất quán. Nếu tiêu chí không thể kiểm tra được rõ ràng, DoD sẽ khó tạo ra sự minh bạch thật sự. DoD vs. Acceptance Criteria Hai khái niệm này thường bị nhầm lẫn, nhưng chúng phục vụ hai mục đích khác nhau: DoD: áp dụng cho TẤT CẢ Increments. Đây là tiêu chuẩn chất lượng chung cho toàn bộ sản phẩm hoặc team. Acceptance Criteria: áp dụng cho TỪNG Product Backlog Item (PBI). Đây là tiêu chí chấp nhận riêng của từng hạng mục công việc. Muốn một PBI thật sự được coi là Done, thì cả Acceptance Criteria lẫn DoD đều phải được đáp ứng. Nói cách khác, Acceptance Criteria trả lời câu hỏi “làm đúng yêu cầu chưa?”, còn DoD trả lời câu hỏi “chất lượng đã đủ chuẩn chưa?”. DoD phải tiến hóa Theo Scrum Guide 2020, Sprint Retrospective là một cơ hội quan trọng để Scrum Team xem xét và cải tiến cách làm việc, bao gồm cả DoD. Khi team học được thêm cách kiểm soát chất lượng tốt hơn, DoD nên được mở rộng để phản ánh mức kỳ vọng cao hơn. DoD có thể được thêm tiêu chí mới khi team trưởng thành hơn DoD không nên bị thu hẹp, vì điều đó làm giảm chuẩn chất lượng đã thiết lập DoD càng nghiêm ngặt hơn thì chất lượng Increment càng cao hơn Việc nâng cấp DoD không phải là làm team khó khăn hơn vô ích, mà là giúp sản phẩm ngày càng đáng tin cậy, ổn định và chuyên nghiệp hơn. Hậu quả khi không tuân thủ DoD Nếu team bỏ qua hoặc làm lỏng DoD, rủi ro chất lượng sẽ tăng rất nhanh. Những hậu quả phổ biến gồm: Technical debt tích lũy vì phần việc “xong nửa vời” bị đẩy sang tương lai Increment không đáng tin cậy, khó đưa vào sử dụng hoặc phát hành Stakeholders mất niềm tin vì “Done” không còn mang nghĩa rõ ràng Rủi ro release tăng cao do lỗi chất lượng bị phát hiện quá muộn Vì vậy, DoD không chỉ là tiêu chuẩn kỹ thuật; nó còn là công cụ bảo vệ niềm tin của sản phẩm, đội ngũ và các bên liên quan. Ghi nhớ theo Scrum Guide 2020: DoD là cam kết chất lượng chung cho Increment; Developers chịu trách nhiệm tạo Increment đáp ứng DoD; Scrum Team có thể làm DoD nghiêm ngặt hơn theo thời gian, nhưng không nên làm yếu đi. Khi chưa có DoD rõ ràng, team rất dễ tạo ra “hoàn thành giả” thay vì một Increment thực sự sẵn sàng.

Mẹo Ôn Thi Agile Scrum (PSM I / PSPO I) 📖 Đọc Scrum Guide 2020 (Bắt buộc) Scrum Guide 2020 là tài liệu chính thức, ngắn gọn và là nguồn quan trọng nhất để ôn thi PSM I / PSPO I. Tài liệu chỉ khoảng 13 trang, nhưng mỗi câu chữ đều có ý nghĩa, đặc biệt là các định nghĩa, trách nhiệm và nguyên tắc cốt lõi. Đọc ít nhất 3 lần để nắm được cấu trúc tổng thể, rồi quay lại đọc kỹ từng định nghĩa. Chú ý từng từ khóa như accountable, responsible, self-managing, empiricism, commitment. Tải miễn phí tại scrum.org/resources/scrum- guide. So sánh các thay đổi từ Scrum Guide 2017 → Scrum Guide 2020, vì đề thi có thể kiểm tra những điểm tinh chỉnh mới. Scrum.org cũng nhấn mạnh rằng người học nên bám sát Scrum Guide trước tiên, sau đó mới mở rộng sang các tài nguyên luyện thi và giải thích thực hành. 🎯 Hiểu “Why” thay vì học thuộc lòng PSM I và PSPO I không chỉ kiểm tra bạn nhớ định nghĩa, mà kiểm tra mức độ hiểu Scrum và khả năng áp dụng Scrum vào tình huống thực tế. Vì vậy, thay vì học đáp án máy móc, hãy luôn tự hỏi: “Tại sao Scrum lại quy định như vậy?” Mỗi khi đọc một quy tắc, hãy nối nó với mục tiêu của Scrum: minh bạch, kiểm tra và thích nghi. Nếu hiểu nguyên tắc, bạn có thể suy luận ra đáp án đúng ngay cả khi câu hỏi được diễn đạt theo cách rất mới. Đề thi thường đưa ra tình huống “gần đúng nhưng không đúng Scrum”; hiểu bản chất sẽ giúp bạn loại trừ các phương án gây nhiễu. Một mẹo tốt là sau mỗi chương, hãy tự diễn giải lại bằng lời của bạn: “Quy tắc này tồn tại để giải quyết vấn đề gì?” ⚠ Chú ý các “bẫy” phổ biến trong đề thi Rất nhiều câu hỏi trong đề thi được thiết kế để kiểm tra xem bạn có thật sự hiểu vai trò và nguyên tắc Scrum hay không. Một số “bẫy” xuất hiện rất thường xuyên: “Scrum Master quyết định...” → thường sai, vì Scrum Master là người huấn luyện, phục vụ và hỗ trợ Scrum Team, không phải người ra lệnh cho team. “Management phê duyệt...” → thường sai, vì Scrum Team là self-managing và tự tổ chức công việc của mình. “Release Sprint” → anti-pattern, không phải cách làm theo Scrum Guide 2020. “User Story format bắt buộc” → sai, Scrum không bắt buộc phải dùng User Story; quan trọng là Product Backlog Item phải đủ rõ để team hiểu và làm việc. Scrum Guide 2020 không mô tả các thực hành cứng nhắc kiểu “phải làm theo đúng một mẫu duy nhất”. Hãy luôn phân biệt giữa Scrum framework và các thực hành của từng tổ chức. 🔄 Làm bài thi thử (Open Assessments) Ôn thi hiệu quả nhất là kết hợp đọc lý thuyết với luyện đề. Scrum.org cung cấp các bài Open Assessments miễn phí, đây là công cụ rất hữu ích để kiểm tra mức độ sẵn sàng trước khi thi thật. Hãy đặt mục tiêu đạt 100% Scrum Open trước khi vào kỳ thi chính thức. Rèn phản xạ bằng các bộ đề như Mikhail Lapshin's PSM I practice tests, vốn được cộng đồng khuyến nghị khá nhiều. Ghi nhớ cấu trúc thi thật: 60 phút, 80 câu hỏi, cần đạt tối thiểu 85% để pass. Sau mỗi đề, không chỉ xem đáp án đúng mà còn phải phân tích vì sao các đáp án khác sai. Luyện đề đều đặn giúp bạn quen với ngôn ngữ ra đề, tốc độ xử lý và các kiểu câu hỏi tình huống thường gặp trong PSM I / PSPO I. 5 🧠 Các chủ đề trọng tâm cần nắm vững Để làm tốt bài thi, bạn cần nắm thật chắc những phần cốt lõi trong Scrum Guide 2020. Đây là các mảng kiến thức xuất hiện rất thường xuyên trong đề: 3 Roles: Product Owner, Scrum Master, Developers — hiểu rõ trách nhiệm và ranh giới của từng vai trò. 5 Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective — nhớ timebox và mục đích của từng event. 3 Artifacts: Product Backlog, Sprint Backlog, Increment — kèm theo các commitments tương ứng. 3 Pillars of Empiricism: Transparency, Inspection, Adaptation — nền tảng tư duy của Scrum. 5 Scrum Values: Commitment, Focus, Openness, Respect, Courage — thường được hỏi theo tình huống thực tế. Sprint Goal: được tạo trong Sprint Planning, do Scrum Team cùng xây dựng, và chỉ thay đổi khi thật sự cần thiết; nếu thay đổi thì phải phù hợp với mục tiêu Sprint. Nếu bạn học được các nhóm chủ đề này một cách chắc chắn, bạn sẽ có nền tảng đủ mạnh để xử lý hầu hết câu hỏi trong kỳ thi. Mẹo học nhanh: Đọc Scrum Guide 2020 trước, rồi làm Open Assessment, sau đó quay lại đọc phần mình sai. Lặp lại vòng này nhiều lần sẽ giúp bạn nhớ lâu hơn rất nhiều so với chỉ học thuộc đáp án.

Các Chủ Đề Quan Trọng Nhất (Phân Bổ Đề Thi PSM I) 35% Vai Trò & Trách Nhiệm Đây là nhóm câu hỏi xuất hiện rất thường xuyên trong PSM I. Hãy nắm rõ Product Owner, Scrum Master và Developers theo đúng Scrum Guide 2020: ai accountable cho điều gì, ai được phép quyết định gì, và giới hạn trách nhiệm của từng vai trò. PO: chịu trách nhiệm tối đa hóa product value, quản lý và sắp xếp Product Backlog, làm rõ hướng sản phẩm. SM: là servant-leader, facilitator, coach, đồng thời gỡ bỏ impediments để Scrum Team làm việc hiệu quả. Developers: là nhóm cross-functional, self-managing, và chịu trách nhiệm tạo ra Done Increment trong mỗi Sprint. Hiểu rõ ranh giới: PO không quản lý công việc hằng ngày của Developers; SM không ra lệnh cho Team; Developers tự tổ chức cách làm việc. Câu hỏi thi thường kiểm tra: ai quyết định ưu tiên, ai chốt Product Backlog Item, ai chịu trách nhiệm về chất lượng Done. 25% Scrum Events & Timeboxes 5 events là phần nền tảng trong Scrum Guide 2020 và rất hay xuất hiện trong đề thi. Cần nhớ đúng mục đích, thời lượng tối đa và ai tham dự. Sprint: khung thời gian chứa toàn bộ công việc; tối đa 1 tháng, thường ngắn hơn để tăng phản hồi. Sprint Planning: tối đa 8 giờ cho Sprint 1 tháng; tạo Sprint Goal, chọn việc, và lập kế hoạch thực hiện. Daily Scrum: tối đa 15 phút; Developers đồng bộ tiến độ và điều chỉnh kế hoạch trong 24 giờ tới. Sprint Review: tối đa 4 giờ; kiểm tra Increment, nhận phản hồi từ stakeholders, và điều chỉnh Product Backlog. Sprint Retrospective: tối đa 3 giờ; cải tiến cách làm việc, quy trình, công cụ và tương tác của Team. Trong đề thi, hãy chú ý câu hỏi về ai bắt buộc tham gia, ai có thể tham dự, và output của từng event. 20% Scrum Artifacts & Commitments Scrum Guide 2020 nhấn mạnh rằng mỗi artifact đều đi kèm một commitment để tăng transparency. Đây là nhóm kiến thức rất quan trọng vì đề thi thường hỏi mối liên kết giữa artifact, commitment và mục đích của chúng. Product Backlog ↔ Product Goal: danh sách công việc duy nhất của sản phẩm, được PO quản lý. Sprint Backlog ↔ Sprint Goal: kế hoạch cho Sprint hiện tại, do Developers sở hữu và cập nhật. Increment ↔ Definition of Done: phần tăng trưởng có giá trị, phải đáp ứng chuẩn chất lượng chung của Team. Transparency: artifact phải được nhìn thấy rõ, hiểu đúng và dùng chung ngôn ngữ giữa các vai trò. Đề thi hay kiểm tra: ai sở hữu artifact nào, commitment nào đi kèm artifact nào, và điều gì làm cho Increment “Done” thật sự. 20% Scrum Theory & Values Phần lý thuyết thường là nền để hiểu vì sao Scrum vận hành như vậy. Nếu nắm vững Empiricism, Lean thinking và 5 Scrum Values, bạn sẽ dễ loại trừ các phương án sai trong PSM I. Empiricism: ra quyết định dựa trên Transparency, Inspection và Adaptation. Lean thinking: tập trung vào điều cốt lõi, giảm lãng phí, tối ưu dòng giá trị và tránh làm quá nhiều việc không cần thiết. 5 Scrum Values: Commitment, Focus, Openness, Respect, Courage. Scrum hoạt động tốt vì nó giúp Team học nhanh từ thực tế, phản hồi sớm và cải tiến liên tục. PSM I thường hỏi theo tình huống: cách nào đúng với tinh thần Scrum, chứ không chỉ đúng về mặt định nghĩa. Gợi ý ôn thi: Theo tinh thần Scrum Guide 2020 và kinh nghiệm từ các bộ PSM I practice tests, 4 nhóm chủ đề trên là phần cần ưu tiên nhất. Nếu học chắc chúng, bạn sẽ xử lý được phần lớn câu hỏi khái niệm và tình huống trong đề. Nguồn tham khảo uy tín: Scrum Guide 2020 (scrum.org), Nexus Guide, Professional Scrum series by Ken Schwaber & Jeff Sutherland.

Scrum Values — 5 Giá Trị Cốt Lõi Lưu ý quan trọng: 5 Values này không phải quy tắc cứng — chúng là nền tảng văn hóa giúp Scrum hoạt động hiệu quả. Theo tinh thần Scrum Guide 2020, nếu thiếu Values thì Scrum rất dễ biến thành “Zombie Scrum”: vẫn có nghi thức, nhưng thiếu tinh thần thật sự của Scrum. Cam Kết (Commitment) Theo Scrum Guide 2020, Commitment là giá trị thể hiện sự tận tâm với mục tiêu chung và sẵn sàng hỗ trợ đồng đội để đạt kết quả tốt nhất. Trong Scrum, cam kết không có nghĩa là “hứa chắc sẽ xong mọi việc đã lên kế hoạch”, mà là cam kết với mục tiêu mà nhóm đang hướng tới. Cam kết đạt được Sprint Goal, Product Goal và mục tiêu của Scrum Team. Không phải cam kết hoàn thành toàn bộ tasks hay tất cả hạng mục trong kế hoạch ban đầu. Khi có thay đổi, nhóm vẫn giữ cam kết với mục tiêu, đồng thời điều chỉnh cách làm để thích nghi. Ví dụ: Developers cam kết với Sprint Goal, chứ không cam kết cứng nhắc với danh sách task cụ thể từ đầu Sprint. Dũng Cảm (Courage) Courage trong Scrum Guide 2020 là sự dám làm điều đúng đắn, ngay cả khi điều đó khó khăn, bất tiện hoặc đi ngược lại kỳ vọng ngắn hạn. Dũng cảm giúp Scrum Team đối diện vấn đề thật, nói ra rủi ro thật và ra quyết định thật thay vì né tránh. Dũng cảm nói sự thật về tình trạng công việc, kể cả khi tin xấu hoặc chưa đạt tiến độ. Dũng cảm nói “không” với yêu cầu không phù hợp với mục tiêu Sprint hoặc giá trị sản phẩm. Dũng cảm chia sẻ ý kiến trái chiều, đặt câu hỏi khó và bảo vệ chất lượng công việc. Ví dụ: Scrum Master dũng cảm bảo vệ Scrum Team khỏi áp lực bên ngoài để nhóm có thể tập trung đúng vào Sprint Goal. Tập Trung (Focus) Focus nghĩa là Scrum Team dành sự chú ý cho công việc quan trọng nhất tại thời điểm hiện tại. Scrum Guide 2020 nhấn mạnh rằng mỗi Sprint nên tạo ra sự tập trung rõ ràng thông qua Sprint Goal, để nhóm không bị kéo đi bởi quá nhiều việc cùng lúc. Tập trung vào công việc thuộc Sprint Backlog và mục tiêu của Sprint. Giảm multitasking, tránh phân tán sang các việc ngoài ưu tiên hiện tại. Sprint Goal tạo “điểm hội tụ” cho cả nhóm: mọi quyết định nên quay về việc có giúp đạt mục tiêu hay không. Ví dụ: Thành viên không tự ý làm việc ngoài Sprint Backlog khi chưa có sự đồng ý và đánh giá lại ảnh hưởng đến Sprint Goal. Cởi Mở (Openness) Openness là sẵn sàng chia sẻ thông tin một cách trung thực và minh bạch về công việc, tiến độ, trở ngại và các vấn đề đang xuất hiện. Trong Scrum Guide 2020, Transparency là điều kiện để kiểm tra và thích nghi hiệu quả; còn Openness là thái độ văn hóa giúp Transparency trở thành hành vi thực tế. Cởi mở về cả thông tin tốt lẫn thông tin xấu, không che giấu rủi ro. Chủ động nói ra vấn đề để cả nhóm cùng hiểu và cùng giải quyết. Minh bạch thông tin giúp inspection chính xác hơn và adaptation kịp thời hơn. Ví dụ: Trong Daily Scrum, thành viên thành thật chia sẻ tiến độ thực tế, thay vì báo cáo “mọi thứ ổn” khi vẫn đang gặp blockers. Tôn Trọng (Respect) Respect trong Scrum Guide 2020 có nghĩa là tôn trọng lẫn nhau như những con người có năng lực, trách nhiệm và khả năng tự tổ chức. Tôn trọng không chỉ là lịch sự trong giao tiếp, mà còn là cách nhóm ghi nhận chuyên môn, quan điểm và giới hạn của nhau để cùng làm việc hiệu quả. Tôn trọng sự khác biệt về kỹ năng, kinh nghiệm và góc nhìn giữa các thành viên. Không đổ lỗi, không công kích cá nhân, không biến vấn đề thành tranh cãi hơn-thua. Tạo môi trường an toàn để mọi người có thể nói thật, học thật và cải tiến thật. Ví dụ: Retrospective là không gian an toàn để chia sẻ điều chưa tốt mà không sợ bị phán xét.

Lời Khuyên Cuối Cùng "Scrum không phải là một phương pháp luận — đó là một framework. Nó cung cấp cấu trúc tối thiểu cần thiết để tạo ra sự minh bạch, kiểm tra và thích nghi." 🎯 Tư Duy Đúng Khi Làm Bài Thi Trong các câu hỏi theo Scrum Guide 2020, hãy ưu tiên đúng theo Scrum Guide hơn là theo thói quen làm việc ở công ty hay kinh nghiệm cá nhân. Luôn tự hỏi: "Scrum Guide nói gì?" — không phải "thực tế công ty tôi đang làm gì?" Khi có nhiều đáp án trông đều hợp lý, hãy chọn đáp án phù hợp nhất với Scrum Guide 2020. Scrum chỉ đưa ra cấu trúc tối thiểu; vì vậy đừng suy diễn thêm những quy tắc mà tài liệu không nói. Nếu kinh nghiệm thực tế mâu thuẫn với Scrum Guide, Scrum Guide luôn là chuẩn tham chiếu cho bài thi. ⚡ Những Điều Scrum KHÔNG Quy Định Scrum Guide 2020 cố ý không áp đặt nhiều chi tiết triển khai để Scrum Team có thể tự thích nghi theo bối cảnh. Đây là điểm rất dễ bị nhầm trong đề thi. Không quy định công cụ: Jira, Trello, Azure DevOps hay bất kỳ công cụ nào khác. Không quy định kỹ thuật kỹ thuật: TDD, CI/CD, pair programming, code review hay các practices phát triển phần mềm cụ thể. Không quy định định dạng PBIs: User Story, use case, task list hay bất kỳ mẫu viết nào. Không quy định cách ước lượng: Story Points, hours, T-shirt sizing hay phương pháp estimation nào. Không quy định cấu trúc tổ chức bên ngoài Scrum Team: Scrum không ép mô hình phòng ban, chức danh hay hierarchy của công ty. 📚 Tài Liệu Tham Khảo Uy Tín Nếu muốn hiểu Scrum sâu và đúng hơn, hãy ưu tiên các nguồn chính thống và những tài liệu bám sát tinh thần của Scrum Guide 2020. Scrum Guide 2020: scrum.org/resources/scrum- guide Scrum.org Blog và các Whitepapers chính thức. "Scrum: The Art of Doing Twice the Work in Half the Time" — Jeff Sutherland. "Professional Scrum Development with Azure DevOps" — Richard Hundhausen. Nexus Guide cho scaling Scrum: scrum.org/resources/nexus-guide 🏆 Sau Khi Đạt Chứng Chỉ Chứng chỉ Scrum là một cột mốc, nhưng không phải đích đến. Điều quan trọng là bạn có thể áp dụng Scrum một cách đúng đắn trong thực tế hay không. Chứng chỉ là điểm bắt đầu — không phải bằng chứng rằng bạn đã thành thạo hoàn toàn. Thực hành Scrum thực tế quan trọng hơn việc chỉ ghi nhớ câu trả lời. Hãy tiếp tục học với các lộ trình như PSM II, PSPO I, PAL-I. Tham gia cộng đồng Scrum để trao đổi, học hỏi và cập nhật góc nhìn liên tục. Chúc bạn thành công trong kỳ thi Agile Scrum! 🚀 Hãy nhớ: hiểu nguyên tắc quan trọng hơn ghi nhớ đáp án. Khi làm bài, hãy quay về các khái niệm cốt lõi trong Scrum Guide 2020: accountability, transparency, inspection và adaptation.