- Tiêu chí chấp nhận cấp dự án và cấp hạng mục · Acceptance Criteria: Project vs Story Level
- Tập điều kiện phải được đáp ứng trước khi sản phẩm bàn giao được chấp nhận. Ở cấp dự án, tiêu chí chấp nhận nằm trong tuyên bố phạm vi và dùng trong quy trình Xác nhận phạm vi; trong Agile, mỗi câu chuyện người dùng có tiêu chí chấp nhận riêng, cụ thể, kiểm thử được. Khác với Định nghĩa hoàn thành (DoD) áp dụng chung cho mọi hạng mục, tiêu chí chấp nhận gắn với từng hạng mục.
- Cú pháp Given–When–Then · Given–When–Then (Gherkin)
- Mẫu viết kịch bản chấp nhận dùng trong BDD: Given (cho trước) — bối cảnh, trạng thái ban đầu; When (khi) — sự kiện hoặc hành động; Then (thì) — kết quả quan sát được. Có thể nối thêm bằng And/But. Ngôn ngữ Gherkin của công cụ Cucumber chuẩn hoá cú pháp này để kịch bản vừa đọc được bởi người nghiệp vụ vừa chạy được như kiểm thử tự động.
- Định nghĩa sẵn sàng · Definition of Ready (DoR)
- Danh sách tiêu chí mà một hạng mục trong danh sách tồn đọng (backlog) phải đáp ứng trước khi đội nhận đưa vào sprint, ví dụ: mô tả rõ, có tiêu chí chấp nhận, đã ước lượng và không còn phụ thuộc chặn.
- Công việc chưa hoàn thành · Undone Work
- Hạng mục chưa đáp ứng Định nghĩa hoàn thành thì không được phát hành và cũng không được trình bày ở Sprint Review như một phần kết quả; khi Sprint kết thúc, hạng mục đó quay lại Product Backlog để PO cân nhắc thứ tự trong tương lai. Không có khái niệm “xong 90%” hay “xong nhưng chưa kiểm thử” trong Scrum; tích luỹ công việc chưa xong tạo ra nợ kỹ thuật và làm sai lệch dự báo.
- Sprint làm cứng · Hardening Sprint
- Sprint dành riêng để kiểm thử tích hợp, sửa lỗi, ổn định trước khi phát hành, sau nhiều Sprint “làm tính năng”. Đây là dấu hiệu Định nghĩa hoàn thành quá yếu: công việc chưa thật sự xong trong từng Sprint nên rủi ro bị dồn lại cuối. Theo Scrum Guide, mỗi Phần tăng trưởng phải dùng được; cách khắc phục là tăng dần độ chặt của DoD, tự động hoá kiểm thử và tích hợp liên tục.
- Nợ kỹ thuật · Technical Debt
- Chi phí làm lại trong tương lai phát sinh khi chọn giải pháp nhanh, tạm thay cho giải pháp tốt hơn nhưng tốn thời gian hơn. Giống nợ tài chính, nợ kỹ thuật có "lãi": mỗi thay đổi sau đó chậm và rủi ro hơn. Cần được nhìn thấy (ghi vào backlog), ưu tiên và trả dần, không để tích tụ.
- Lỗi lọt · Escaped Defects
- Lỗi không được phát hiện trong quá trình phát triển và kiểm thử của đội mà chỉ lộ ra sau khi đã bàn giao, thường do người dùng hoặc bộ phận vận hành báo. Số lỗi lọt (hoặc tỷ lệ so với tổng số lỗi tìm thấy) là chỉ số chất lượng quan trọng trong agile vì nó phản ánh độ hiệu quả của Definition of Done và kiểm thử. Khi chỉ số này tăng, đội nên phân tích nguyên nhân gốc ở buổi cải tiến thay vì chỉ sửa từng lỗi.
- Tái cấu trúc mã · Refactoring
- Cải thiện cấu trúc bên trong của mã nguồn mà không thay đổi hành vi bên ngoài, ví dụ tách hàm dài, đặt lại tên, loại bỏ trùng lặp. Làm thường xuyên với bước nhỏ, được bảo vệ bởi kiểm thử tự động, để giữ mã dễ hiểu, dễ thay đổi và trả dần nợ kỹ thuật.
