Mở đầu — vì sao bài này quan trọng
Trong ba commitment (cam kết) của Scrum — Product Goal, Sprint Goal và Definition of Done — thì Definition of Done gắn liền với một artifact mà nhiều người học PSPO I hay xem nhẹ: Increment. Họ thuộc lòng Product Backlog, nói trôi chảy về Sprint Backlog, nhưng khi gặp câu hỏi "Increment là gì và khi nào nó tồn tại?", họ lúng túng.
Đây là một trong những chủ đề mà đề thi PSPO I khai thác rất sâu, vì nó đụng đến bản chất của Scrum: chúng ta tồn tại để tạo ra giá trị, và giá trị đó được hiện thực hóa qua Increment — chứ không phải qua tài liệu, qua kế hoạch, hay qua số story point hoàn thành. Một đội Scrum chạy đủ 5 sự kiện, có đủ ba vai trò, nhưng nếu cuối Sprint không cho ra một Increment usable (có thể sử dụng được), thì về bản chất họ chưa làm Scrum đúng nghĩa.
Với vai trò Product Owner, bạn cần hiểu Increment ở mức sâu hơn người Developer thông thường, vì bạn là người chịu trách nhiệm về giá trị. Bạn quyết định Increment nào được release, bạn là người kiểm tra xem nó có thực sự hướng tới Product Goal hay không, và bạn là người đối diện với stakeholder để giải thích "đây là những gì đã hoàn thành". Trong bài này, chúng ta sẽ mổ xẻ Increment theo đúng tinh thần Scrum Guide 2020 — định nghĩa, đặc tính, mối quan hệ với Definition of Done, và cách một PO giỏi sử dụng khái niệm này trong thực tế.
Khái niệm cốt lõi
Increment là gì?
Theo Scrum Guide 2020, Increment là một bước nhảy cụ thể (concrete stepping stone) hướng tới Product Goal. Mỗi Increment được cộng dồn (additive) vào tất cả các Increment trước đó, và được kiểm chứng kỹ lưỡng để đảm bảo tất cả các Increment hoạt động cùng nhau như một thể thống nhất.
Hãy chú ý ba từ khóa trong định nghĩa này:
- Concrete stepping stone — Increment không phải là ý tưởng, không phải là kế hoạch. Nó là thứ cụ thể, hữu hình, đã được hoàn thành. Mỗi Increment là một viên đá lát đường thực sự để bạn bước tới Product Goal.
- Toward the Product Goal — Mọi Increment đều phải hướng về một đích chung là Product Goal. Đây là lý do PO cần đảm bảo Product Backlog được sắp xếp đúng: nếu thứ tự sai, các Increment sẽ đi lệch hướng.
- Additive — Increment mới cộng dồn vào những gì đã có, và phải hoạt động liền mạch với những Increment trước. Bạn không thể tạo ra một Increment "đứng riêng lẻ" làm hỏng những gì đã release.
Đặc tính quan trọng nhất: Usable (có thể sử dụng được)
Đặc tính cốt lõi của Increment là nó phải usable — có thể sử dụng được. Điều này có nghĩa là Increment phải đạt được trạng thái chất lượng đủ để có thể đưa vào sử dụng thực tế, ngay cả khi PO quyết định chưa release ra thị trường.
Để một phần công việc được coi là một phần của Increment, nó bắt buộc phải đáp ứng Definition of Done (DoD). Đây là mối quan hệ then chốt mà đề thi PSPO I rất hay hỏi:
> Công việc nào chưa đạt Definition of Done thì không được tính là một phần của Increment, không được trình bày tại Sprint Review, và phải quay trở lại Product Backlog để xử lý trong tương lai.
Nói cách khác: DoD chính là tiêu chuẩn chất lượng định nghĩa khi nào công việc trở thành một phần của Increment. Một story đã code xong nhưng chưa test, chưa tích hợp, chưa đạt DoD — thì nó không phải là Increment. Nó chỉ là công việc dở dang (work in progress).
Một Sprint có thể tạo ra nhiều Increment
Đây là điểm thay đổi quan trọng từ Scrum Guide 2020 mà nhiều người vẫn hiểu sai. Trước đây nhiều người nghĩ "mỗi Sprint cho ra đúng một Increment vào cuối Sprint". Nhưng Scrum Guide 2020 nói rõ:
> Trong một Sprint có thể tạo ra nhiều Increment. Tổng các Increment được trình bày tại Sprint Review, qua đó hỗ trợ empiricism (kinh nghiệm chủ nghĩa).
Điều này có nghĩa là ngay khi một phần công việc đạt DoD, nó đã trở thành một Increment — bạn không cần đợi đến cuối Sprint. Một đội có DevOps tốt có thể tạo ra 5, 10, thậm chí hàng chục Increment trong một Sprint. Mỗi lần một mẩu công việc đạt DoD là một Increment mới ra đời.
Increment usable nhưng không nhất thiết phải release
Đây là chỗ PO cần phân biệt rạch ròi:
- Usable (có thể sử dụng được) là yêu cầu bắt buộc của mọi Increment. Nó phải đủ chất lượng để dùng được.
- Released (đã phát hành) là một quyết định, không phải yêu cầu. Việc một Increment có được release hay không, và release khi nào, là quyết định của Product Owner.
Increment và empiricism
Tại sao Increment lại quan trọng đến mức được xem là một trong ba artifact của Scrum? Vì nó là bằng chứng vật chất để inspect (kiểm tra). Empiricism dựa trên ba trụ cột: transparency, inspection, adaptation. Increment chính là thứ cụ thể, minh bạch mà cả đội và stakeholder cùng kiểm tra tại Sprint Review, từ đó rút ra điều chỉnh cho Product Backlog.
Không có Increment thực sự usable, mọi "kiểm tra" tại Sprint Review chỉ là kiểm tra slide, kiểm tra demo giả, kiểm tra lời hứa — và empiricism sụp đổ. Đây là lý do một Increment chưa đạt DoD không bao giờ được mang ra Sprint Review.
Tình huống thực tế
Tình huống 1 — Đội fintech tại TP.HCM và bài học "code xong không phải là Done"
Một startup fintech ở Quận 1, TP.HCM (gọi là VíNhanh) có một đội Scrum 7 người làm tính năng "chuyển tiền liên ngân hàng tức thời". Vào ngày cuối Sprint, Developer báo với PO: "Bọn em code xong tính năng rồi, demo được luôn." PO mừng rỡ, mời 3 đại diện ngân hàng đối tác và sếp đến Sprint Review.
Tại buổi review, demo chạy ngon trên môi trường máy của lập trình viên. Nhưng khi một đối tác hỏi "Tính năng này đã chạy trên môi trường staging tích hợp với core banking chưa? Đã qua security review chưa? Đã test với case số tiền lớn chưa?", thì câu trả lời là "chưa". Định nghĩa Done của VíNhanh yêu cầu: code review, test tự động pass, deploy lên staging, qua security scan. Tính năng này mới chỉ chạy local.
Diễn giải: Phần công việc đó chưa đạt DoD, nên về mặt Scrum, nó chưa phải là một Increment. PO đã mang một thứ chưa phải Increment ra Sprint Review, tạo kỳ vọng sai cho stakeholder. Hậu quả: Sprint sau bị áp lực vì đối tác tưởng tính năng "đã xong" và lên kế hoạch tích hợp, trong khi thực tế còn 40% công việc.
Bài học rút ra: "Code xong" không bao giờ đồng nghĩa với "Done". Increment chỉ tồn tại khi công việc đạt Definition of Done. PO phải bảo vệ ranh giới này quyết liệt — đừng để áp lực thời gian khiến bạn trình bày work-in-progress như thể đó là Increment hoàn chỉnh.
Tình huống 2 — Sàn TMĐT Đông Nam Á và sức mạnh của "nhiều Increment trong một Sprint"
Một sàn thương mại điện tử khu vực Đông Nam Á (giả định tên Lazo) có đội platform xây dựng tính năng "voucher theo địa lý". Đội này đầu tư mạnh vào CI/CD: mỗi khi một pull request đạt DoD (review xong, test pass, tự động deploy), code được đẩy thẳng lên production qua feature flag (cờ tính năng để bật/tắt mà không cần deploy lại).
Trong một Sprint hai tuần, đội tạo ra 11 Increment: từ API tính khoảng cách, đến logic áp voucher, đến giao diện hiển thị. Mỗi Increment đều usable và đã ở trên production, nhưng PO chưa bật feature flag cho người dùng cuối. Đến khi đủ toàn bộ luồng, PO mới bật flag để release đồng loạt cho thị trường Việt Nam và Thái Lan vào đúng dịp khuyến mãi 12/12.
Diễn giải: Đây là minh họa hoàn hảo cho hai điểm Scrum Guide 2020: (1) một Sprint có thể có nhiều Increment, và (2) usable không đồng nghĩa với released. 11 Increment đều đạt DoD, đều có thể sử dụng, nhưng quyết định khi nào bật cho người dùng là thẩm quyền của PO — và PO chọn thời điểm tối ưu cho kinh doanh.
Bài học rút ra: Increment usable cho phép PO có quyền linh hoạt về thời điểm release. Tách biệt "hoàn thành về mặt kỹ thuật" (usable, đạt DoD) khỏi "phát hành ra thị trường" (release) cho bạn đòn bẩy chiến lược cực lớn. Đây là tư duy của một PO trưởng thành.
Tình huống 3 — Công ty gia công phần mềm tại Đà Nẵng và bẫy "Increment tích lũy không hoạt động cùng nhau"
Một công ty outsourcing ở Đà Nẵng làm dự án cho khách hàng Nhật. Đội có thói quen mỗi Sprint hoàn thành một module độc lập, demo cho khách, rồi chuyển sang module tiếp theo mà không tích hợp lại với những gì đã làm. Sau 6 Sprint, mỗi module riêng lẻ đều "đạt DoD" theo cách họ định nghĩa, đều demo đẹp.
Nhưng đến Sprint 7, khi khách yêu cầu một bản build hoàn chỉnh để UAT, đội phát hiện các module xung đột với nhau: module thanh toán dùng phiên bản thư viện khác module đặt hàng, dữ liệu không khớp định dạng. Việc "ghép" lại tốn thêm 3 Sprint ngoài kế hoạch.
Diễn giải: Đội đã bỏ qua đặc tính additive và "hoạt động cùng nhau như một thể thống nhất" của Increment. Mỗi Increment phải được kiểm chứng để cộng dồn liền mạch với tất cả Increment trước đó. Một DoD lành mạnh phải bao gồm cả việc tích hợp vào tổng thể — chứ không chỉ "module này chạy được một mình".
Bài học rút ra: Increment không phải là những hòn đảo riêng lẻ. Nó là viên đá lát cộng dồn trên con đường hướng tới Product Goal. PO cần làm việc với đội để đảm bảo DoD bao hàm tính tích hợp, tránh "nợ tích hợp" tích tụ thành khủng hoảng.
Hướng dẫn từng bước
Dưới đây là cách một Product Owner làm việc đúng với khái niệm Increment trong thực tế:
Bước 1 — Thống nhất Definition of Done với cả đội. Vì Increment được định nghĩa bởi DoD, việc đầu tiên là cùng Developers xác lập một DoD rõ ràng, bao gồm cả tiêu chí tích hợp và chất lượng. Không có DoD chung, khái niệm Increment trở nên mơ hồ. (Bài 14 đi sâu về DoD — ở đây ta chỉ cần biết nó là tiêu chuẩn định nghĩa Increment.)
Bước 2 — Sắp xếp Product Backlog hướng tới Product Goal. Vì mỗi Increment là bước nhảy tới Product Goal, hãy đảm bảo thứ tự backlog tạo ra một chuỗi Increment có ý nghĩa, mỗi cái xây trên cái trước. Đừng để các hạng mục rời rạc tạo ra Increment lệch hướng.
Bước 3 — Trong Sprint, khuyến khích tạo Increment liên tục. Đừng đợi tới cuối Sprint mới có một "cú Done lớn". Hãy thúc đẩy văn hóa hoàn thành từng mẩu công việc đạt DoD sớm và thường xuyên. Mỗi mẩu Done là một Increment, giảm rủi ro dồn toa cuối Sprint.
Bước 4 — Kiểm tra tính usable, không chỉ tính "xong tính năng". Trước Sprint Review, với mỗi hạng mục bạn định trình bày, hãy tự hỏi: "Cái này đã thực sự đạt DoD và usable chưa? Hay mới chỉ code xong?" Chỉ những gì đã là Increment thật mới được mang ra review.
Bước 5 — Tại Sprint Review, trình bày tổng các Increment. Trình bày những gì đã đạt DoD, để stakeholder inspect và cùng adapt Product Backlog. Những gì chưa đạt DoD thì trung thực đưa trở lại backlog.
Bước 6 — Ra quyết định release. Sau khi có Increment usable, bạn — với tư cách PO — quyết định release khi nào: ngay lập tức, gộp lại, hay chờ thời điểm thị trường. Đây là thẩm quyền và trách nhiệm của bạn.
Lỗi thường gặp & mẹo
Lỗi 1 — Đồng nhất "cuối Sprint" với "thời điểm có Increment". Nhiều người tin Increment chỉ xuất hiện vào cuối Sprint. Sai. Increment xuất hiện ngay khi công việc đạt DoD, và một Sprint có thể có nhiều Increment.
Lỗi 2 — Coi Sprint Review là nơi "tạo ra" Increment. Sprint Review trình bày Increment đã có sẵn, chứ không phải nơi sản sinh ra nó. Increment được tạo ra trong quá trình làm việc của Sprint, khi đạt DoD.
Lỗi 3 — Nhầm "usable" với "released". Usable là yêu cầu bắt buộc; released là quyết định của PO. Đề thi PSPO I rất hay gài bẫy ở đây: một Increment có thể usable mà không bao giờ được release, và điều đó hoàn toàn hợp lệ.
Lỗi 4 — Mang work-in-progress ra Sprint Review. Công việc chưa đạt DoD không phải Increment, không được trình bày như đã hoàn thành. Đưa nó trở lại Product Backlog.
Lỗi 5 — Nghĩ rằng Scrum Guide bắt buộc release mỗi Sprint. Scrum Guide không yêu cầu release mỗi Sprint. Nó yêu cầu Increment phải usable. Quyết định release là của PO, dựa trên giá trị và bối cảnh kinh doanh.
Mẹo ghi nhớ cho phòng thi: Hãy gắn chặt ba mệnh đề này với nhau — "Increment đạt DoD thì mới là Increment", "một Sprint có thể nhiều Increment", "usable là bắt buộc, released là tùy PO quyết". Phần lớn câu hỏi về Increment xoay quanh ba ý này.
Mẹo thực hành: Khi xây dựng DoD cùng đội, hãy đưa cả tiêu chí "tích hợp vào tổng thể và không phá vỡ những Increment trước" vào DoD. Điều này phòng tránh bẫy "nợ tích hợp" như tình huống 3.
Bài tập thực hành
- Phân biệt Increment thật và giả. Lấy Sprint gần nhất của đội bạn (hoặc một tình huống bạn hình dung). Liệt kê 5 hạng mục đã "làm trong Sprint". Với mỗi hạng mục, đánh dấu: đã đạt DoD chưa? Nếu chưa, nó không phải Increment — nó phải quay lại Product Backlog. Đếm xem thực sự bạn có bao nhiêu Increment.
- Tách usable khỏi released. Viết ra một kịch bản trong đó đội bạn tạo ra 3 Increment usable trong một Sprint, nhưng vì lý do kinh doanh, bạn chỉ release 1 và giữ lại 2. Nêu rõ lý do release/giữ lại cho từng cái. Bài tập này rèn tư duy "quyết định release là của PO".
- Tự kiểm tra DoD. Viết Definition of Done hiện tại của đội bạn ra giấy. Tự hỏi: nếu một story đạt đủ các tiêu chí này, nó có thực sự "usable" và "cộng dồn liền mạch với những gì đã có" không? Nếu không, hãy đề xuất bổ sung tiêu chí còn thiếu (ví dụ: tích hợp, security, performance).
- Câu hỏi luyện thi: "Một đội hoàn thành 4 hạng mục đạt DoD trong Sprint, nhưng PO quyết định không release bất kỳ cái nào ra production. Đội này có vi phạm Scrum không?" Hãy tự trả lời và giải thích. (Gợi ý: không vi phạm — Increment phải usable, nhưng release là quyết định của PO.)
Tóm tắt
- Increment là một bước nhảy cụ thể (concrete stepping stone) hướng tới Product Goal, được cộng dồn (additive) vào các Increment trước và hoạt động cùng chúng như một thể thống nhất.
- Đặc tính cốt lõi là usable — Increment phải đủ chất lượng để sử dụng được. Để là một phần của Increment, công việc bắt buộc phải đạt Definition of Done.
- Công việc chưa đạt DoD thì không phải Increment, không được trình bày tại Sprint Review, và quay lại Product Backlog.
- Một Sprint có thể tạo ra nhiều Increment. Increment ra đời ngay khi công việc đạt DoD, không cần đợi cuối Sprint.
- Usable là bắt buộc; released là quyết định của Product Owner. Increment phải sẵn sàng dùng, nhưng việc release khi nào thuộc thẩm quyền PO.
- Increment là bằng chứng vật chất cho empiricism — thứ minh bạch để inspect tại Sprint Review và làm cơ sở để adapt Product Backlog.