Đáp án đúng: C. Acceptance test được viết cho và cùng với khách hàng, nên phải dùng ngôn ngữ của NGƯỜI DÙNG và nghiệp vụ, không dùng ngôn ngữ hệ thống. Vì vậy "system-centric language" không thuộc các thành phần then chốt — nó là thứ cần tránh. A các bước trình diễn, B các điều kiện lỗi cần xử lý, và D tiêu chí chấp nhận rõ ràng đều là thành phần thật: có bước để diễn lại, có tình huống lỗi để chắc hệ thống không vỡ, và có tiêu chí để phán xét đạt hay không đạt.

Đáp án đúng: B. Đây là nghịch lý đặc trưng của XP: khi thứ gì đó gây đau thì hãy làm nó thường xuyên hơn cho tới khi hết đau. Phản hồi tới nhiều hơn khả năng xử lý thường là dấu hiệu mỗi lô phản hồi quá lớn vì khoảng cách giữa các lần quá dài; tăng tần suất khiến mỗi lô nhỏ lại và xử lý được ngay, đồng thời buộc nhóm cải tiến quy trình tiếp nhận. A giảm tần suất chỉ dồn phản hồi thành lô to hơn, khiến vấn đề trầm trọng thêm. C bỏ qua phản hồi là vứt đi thông tin quý nhất. D tăng ca không giải quyết nguyên nhân và tạo lãng phí kiểu Lean.

Đáp án đúng: C. Phần thứ hai của Sprint Planning trả lời câu "làm thế nào": nhóm phân rã từng hạng mục backlog đã chọn thành các đầu việc kỹ thuật cụ thể và ước lượng chúng, để kiểm chứng lại rằng khối lượng cam kết thực sự vừa với năng lực sprint. A sắp xếp ưu tiên là việc của Product Owner với Product Backlog, làm TRƯỚC buổi planning. B giao việc cho quản lý đi ngược nguyên tắc nhóm tự tổ chức — thành viên tự nhận việc. D dự báo ngày phát hành là bài toán ở tầm release, không phải mục đích của việc chia task.

Đáp án đúng: B. Sprint Backlog được nhóm phát triển tạo ra ngay trong buổi Sprint Planning: chọn hạng mục từ Product Backlog theo thứ tự ưu tiên và năng lực, rồi phân rã thành các đầu việc. Nó là sản phẩm đầu ra của buổi họp đó. A sai vì sprint backlog gắn với từng sprint chứ không lập một lần cho cả dự án. C backlog refinement là nơi làm mịn PRODUCT Backlog, không tạo Sprint Backlog. D sai: sprint backlog được CẬP NHẬT hằng ngày trong sprint, nhưng thời điểm TẠO thì cố định là buổi planning.

Đáp án đúng: A. Ba chữ C của user story do Ron Jeffries đặt ra: Card (tấm thẻ ghi ngắn gọn story, chỉ vừa đủ để nhớ), Conversation (cuộc trao đổi giữa nhóm và khách hàng để làm rõ chi tiết — phần quan trọng nhất), và Confirmation (tiêu chí chấp nhận để xác nhận story đã xong). B, C, D đều là các bộ ba chữ C bịa ra để gây nhiễu. Ý nghĩa của mô hình này là user story không phải một đặc tả viết sẵn mà là lời hứa cho một cuộc trò chuyện.

Đáp án đúng: C. Burndown Chart trong sprint thể hiện lượng công việc CÒN LẠI đối chiếu với thời gian: trục tung là phần chưa xong (giờ hoặc story point), trục hoành là các ngày của sprint, đường thực tế so với đường lý tưởng cho biết nhóm đang bám kịp hay tụt lại. A mô tả biểu đồ burn-up (công việc tích luỹ đã hoàn thành). B danh sách tính năng đề xuất là Product Backlog. D số bug chưa xử lý là chỉ số chất lượng riêng, có thể vẽ biểu đồ riêng nhưng không phải nội dung của burndown.

Đáp án đúng: A. Sprint Retrospective là sự kiện cuối sprint dành riêng cho việc nhóm tự soi lại CÁCH LÀM VIỆC của mình: điều gì chạy tốt, điều gì vướng, và chọn ra cải tiến cụ thể áp dụng ngay ở sprint sau. Nó tập trung vào quy trình và con người, không vào sản phẩm. B lập kế hoạch sprint kế tiếp là việc của Sprint Planning. C thảo luận phản hồi về sản phẩm với Product Owner và các bên liên quan là việc của Sprint Review. D tăng gắn kết các bên liên quan không phải mục đích của một sự kiện nội bộ nhóm. ⚠ Bản đề in đáp án C. Chốt A vì C mô tả đúng Sprint Review chứ không phải Retrospective — hai sự kiện này khác nhau ở đối tượng soi xét: Review soi sản phẩm, Retrospective soi quy trình.

Đáp án đúng: D. Burndown chart trả lời được cả ba: nhìn tung độ tại ngày hiện tại biết còn bao nhiêu việc; so đường thực tế với đường lý tưởng biết có kịp mục tiêu sprint không; nhìn độ dốc qua nhiều ngày thấy xu hướng tiến triển (phẳng nhiều ngày là dấu hiệu tắc nghẽn). A, B, C mỗi phương án chỉ nêu một trong ba công dụng nên đều chưa đủ. Đây là dạng câu có phương án bao trùm: kiểm tra từng mục con, cả ba đều đúng thì chọn "All of the above".

Đáp án đúng: B. Agile cần vòng phản hồi ngắn và khả năng thay đổi mà không sợ vỡ. Continuous integration kèm bộ unit test tự động đáp ứng đúng điều đó: mỗi lần commit là chạy lại toàn bộ test, lỗi hồi quy lộ ra trong vài phút thay vì vài tuần, nhờ vậy nhóm dám refactor liên tục. A dồn kiểm thử về cuối là mô hình Waterfall. C hồi quy thủ công mỗi lần phát hành thì không theo kịp nhịp sprint và rất dễ bỏ sót. D né tài liệu chẳng liên quan gì tới cách kiểm thử, và Agile cũng không chủ trương bỏ tài liệu.

Đáp án đúng: A, C, D. Daily standup 15 phút phục vụ ba việc: nhóm tự lập kế hoạch cho ngày làm việc, phối hợp với nhau về những phần công việc giao thoa, và cùng nắm tình hình tiến độ hướng tới Sprint Goal. B sai ở một chữ: "overlooking obstacles" nghĩa là BỎ QUA vật cản, trong khi mục đích thật của standup là NÊU RA vật cản (raising impediments) để Scrum Master gỡ. Đây là bẫy chữ nghĩa — nếu đọc lướt thành "overlook = xem xét" thì chọn nhầm ngay.

Đáp án đúng: A. Scrum chỉ có ba vai trò (accountability): Product Owner, Scrum Master và Developers (nhóm phát triển). Project Manager KHÔNG nằm trong đó — các trách nhiệm truyền thống của vai trò này được phân tán: quản trị phạm vi và giá trị về Product Owner, gỡ vướng và bảo vệ quy trình về Scrum Master, còn lập kế hoạch và phân công về chính nhóm tự tổ chức. B, C, D đều là ba vai trò thật của Scrum, nên không phải đáp án của câu hỏi phủ định này.