Mở đầu — vì sao bài này quan trọng
Bạn đã từng dự một buổi Sprint Review mà cả đội hào hứng khoe "tụi em làm xong hết rồi", nhưng khi khách hàng hỏi "vậy giờ tôi dùng được chưa?" thì cả phòng im lặng chưa? Code đã viết xong, nhưng chưa test. Tính năng đã chạy, nhưng "chỉ chạy trên máy em thôi". Backend đã ráp, nhưng frontend còn dang dở. Đó chính là khoảnh khắc một Sprint trông như đã hoàn thành nhưng thực ra chẳng tạo ra giá trị nào có thể giao tới tay người dùng.
Gốc rễ của tình huống này nằm ở việc đội Scrum chưa hiểu đúng về Increment — sản phẩm gia tăng, thứ deliverable thực sự mà mỗi Sprint phải tạo ra. Increment không phải là "đống việc đã làm". Increment là một bước tiến cụ thể, hữu dụng, có thể bàn giao được hướng tới Product Goal.
Là một Product Owner, bạn không quản lý dòng code. Bạn quản lý giá trị. Mà giá trị chỉ trở thành hiện thực khi nó nằm trong một Increment đủ chất lượng để có thể tung ra thị trường. Nếu bạn không hiểu Increment là gì, bạn sẽ chấp nhận những "thành phẩm" nửa vời, ký duyệt những thứ không dùng được, và cuối cùng đánh mất niềm tin của stakeholder. Bài học này giúp bạn nắm chắc khái niệm cốt lõi nhất trong toàn bộ hệ thống artifact của Scrum — thứ quyết định Sprint của bạn có thực sự "ra được gì" hay không.
Khái niệm cốt lõi
Increment là gì
Theo Scrum Guide, Increment là một bước đệm cụ thể (concrete stepping stone) hướng tới Product Goal. Mỗi Increment cộng dồn vào tất cả các Increment trước đó, và được kiểm chứng kỹ lưỡng để đảm bảo rằng tất cả chúng hợp lại vẫn hoạt động trơn tru với nhau.
Hãy chú ý hai vế quan trọng trong định nghĩa này:
- "Bước đệm cụ thể": Increment không phải là một ý tưởng, một bản thiết kế, hay một lời hứa. Nó là thứ có thật, sờ được, dùng được. Một bước chân vững chắc trên con đường đi tới mục tiêu sản phẩm.
- "Cộng dồn (sum of all completed items)": Increment không chỉ là phần việc bạn làm trong Sprint này. Nó là tổng của Sprint này cộng với toàn bộ những Increment đã hoàn thành trước đó. Sản phẩm là một thực thể liên tục lớn dần, chứ không phải các mảnh rời rạc.
Một Sprint có thể tạo ra nhiều Increment
Đây là điểm nhiều người hiểu sai. Họ nghĩ "một Sprint = một Increment". Thực ra, trong một Sprint, đội có thể tạo ra nhiều Increment. Mỗi khi một Product Backlog Item đạt Definition of Done, một Increment mới ra đời ngay lúc đó. Bạn không cần đợi tới cuối Sprint, cũng không cần đợi tới Sprint Review.
Ví dụ: trong một Sprint hai tuần, đội của bạn hoàn thành tính năng "đăng nhập bằng Google" vào ngày thứ 4, hoàn thành "quên mật khẩu" vào ngày thứ 7, và "đổi mật khẩu" vào ngày thứ 9. Vậy là bạn đã có ba Increment trước cả buổi Review. Mỗi cái, về lý thuyết, đều có thể tung ra ngay.
Sprint Review không phải là cánh cổng để "phát hành" Increment
Điều này cực kỳ quan trọng với vai trò PO. Một Increment có thể được giao (delivered) tới stakeholder bất cứ lúc nào, không cần chờ tới Sprint Review. Sprint Review là nơi để cùng nhau kiểm tra và thích nghi (inspect & adapt), thảo luận về hướng đi tiếp theo — chứ không phải là điều kiện bắt buộc để được phép phát hành.
Quyết định khi nào đưa Increment ra thị trường là quyết định của Product Owner, dựa trên giá trị kinh doanh, sự sẵn sàng của thị trường, và chiến lược release. Scrum tách bạch rõ: tạo ra Increment dùng được là việc của đội mỗi Sprint; còn phát hành nó là quyền và trách nhiệm của PO.
Định nghĩa "Done" gắn chặt với Increment
Một công việc không thể được coi là một phần của Increment cho tới khi nó đáp ứng Definition of Done (DoD) — định nghĩa hoàn thành. DoD là tiêu chuẩn chất lượng chính thức mô tả trạng thái của Increment khi nó đạt mức "hữu dụng cho sản phẩm".
Nếu một Product Backlog Item không đạt DoD, nó không được đưa vào Increment, không được trình bày ở Sprint Review, và quay trở lại Product Backlog để cân nhắc trong tương lai. Không có khái niệm "hoàn thành 90%". Trong Scrum, hoặc là Done, hoặc là chưa. DoD chính là tấm khiên bảo vệ chất lượng của Increment.
Đặc tính bắt buộc: Usable — phải dùng được
Đặc tính sống còn của Increment là tính usable (hữu dụng / có thể sử dụng được). Một Increment phải ở trạng thái có thể bàn giao — "shippable". Nó phải hoạt động đầy đủ, đã được kiểm thử, tích hợp với các phần trước đó, và sẵn sàng tạo giá trị nếu PO quyết định phát hành.
Điều này loại bỏ thẳng tay căn bệnh kinh điển "works on my machine" — "nó chạy được trên máy của em". Một tính năng chỉ chạy trên máy lập trình viên, chưa merge vào nhánh chính, chưa qua môi trường staging, chưa được kiểm thử thực sự — thì không phải là một Increment. Đó chỉ là việc đang dang dở.
Usable cũng có nghĩa là Increment phải đứng vững một cách độc lập về mặt chất lượng. Nó không được làm hỏng những phần đã chạy trước đó. Đây là lý do vì sao việc tích hợp và kiểm thử hồi quy (regression) là một phần không thể tách rời của việc tạo ra Increment.
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "Increment trên giấy"
Hãy tưởng tượng một đội phát triển tính năng tại một sàn thương mại điện tử lớn của Việt Nam như Tiki. Đội nhận nhiệm vụ xây dựng tính năng "mua trước trả sau" (Buy Now Pay Later) cho Sprint hai tuần.
Tới buổi Sprint Review, lập trình viên trình diễn: người dùng chọn sản phẩm, bấm "trả sau", màn hình hiện ra lịch thanh toán đẹp mắt. Cả phòng vỗ tay. PO chuẩn bị ghi nhận đây là Increment hoàn chỉnh.
Nhưng PO tinh ý hỏi một câu: "Khi khách bấm xác nhận, hệ thống có thực sự gọi sang đối tác tài chính để duyệt khoản vay chưa?" Câu trả lời là: "Phần đó tụi em hard-code dữ liệu giả để demo, API thật chưa nối." Tệ hơn, tính năng này mới chạy trên môi trường dev của một bạn, chưa merge, chưa qua staging.
Bài học: Cái mà đội trình diễn không phải là một Increment. Nó là một bản mô phỏng (mock) trông giống Increment. Nó không usable — không thể đưa cho một khách hàng thật dùng. Một PO giỏi phải phân biệt được "demo trông đẹp" và "Increment thật". Nếu PO ký duyệt thứ này như đã Done, đội sẽ gánh một khoản nợ kỹ thuật khổng lồ, và stakeholder sẽ tưởng tính năng sắp ra mắt trong khi thực tế còn xa.
Tình huống 2 — Startup fintech và sức mạnh của Increment dùng được sớm
Một startup ví điện tử giả định tại TP.HCM, tạm gọi là "PayViet", đang xây tính năng nạp tiền từ thẻ ngân hàng. Thay vì cố nhồi toàn bộ tính năng "nạp từ mọi ngân hàng" vào một Sprint, PO chia nhỏ: Sprint này chỉ làm "nạp tiền từ Vietcombank", đạt DoD đầy đủ — code, test, tích hợp cổng thanh toán thật, qua kiểm thử bảo mật.
Tới giữa Sprint, tính năng "nạp từ Vietcombank" đạt Done. Đây là một Increment usable hoàn chỉnh. PO quyết định không chờ Sprint Review mà bật tính năng này cho 5% người dùng ngay (canary release). Trong vòng 3 ngày, đội thu được dữ liệu thật: tỷ lệ nạp thành công 92%, và phát hiện một lỗi timeout xảy ra với 8% giao dịch trên 5 triệu đồng.
Bài học: Vì Increment thực sự usable và có thể giao bất cứ lúc nào, PO đã rút ngắn vòng phản hồi từ "vài tuần" xuống "vài ngày". Họ phát hiện vấn đề thật trên người dùng thật trước khi mở rộng ra toàn bộ ngân hàng. Đây chính là giá trị chiến lược của việc hiểu rằng Increment không bị giam trong lịch Sprint Review.
Tình huống 3 — Đội ngoài (outsourcing) và sự cộng dồn của Increment
Một công ty gia công phần mềm ở Đà Nẵng làm dự án cho khách hàng Nhật. Mỗi Sprint, họ giao một "Increment". Nhưng có một vấn đề: ở Sprint 5, tính năng "lọc đơn hàng" mới làm xong khiến tính năng "xuất báo cáo" của Sprint 3 bị lỗi — báo cáo xuất ra thiếu mất các đơn đã lọc.
Khách hàng Nhật phản ứng gay gắt: "Các bạn nói Sprint 3 đã Done, sao giờ lại hỏng?"
Bài học: Đội đã quên rằng Increment là tổng của tất cả các phần đã hoàn thành, và mỗi Increment mới phải được kiểm chứng để đảm bảo toàn bộ vẫn hoạt động cùng nhau. Họ chỉ test tính năng mới của Sprint 5 mà bỏ qua kiểm thử hồi quy. Một Increment đúng nghĩa phải đảm bảo tính toàn vẹn của cả sản phẩm, không chỉ phần mới thêm. Sau sự cố này, đội bổ sung "kiểm thử hồi quy đạt 100%" vào DoD, và biến việc tích hợp liên tục thành tiêu chuẩn bắt buộc.
Hướng dẫn từng bước
Dưới đây là cách một Product Owner đảm bảo mỗi Sprint tạo ra Increment thật sự có giá trị.
Bước 1 — Cùng đội thống nhất Definition of Done rõ ràng. Trước khi nói về Increment, hãy chắc chắn cả đội đồng thuận về DoD: code đã review, đã test (unit + integration), đã merge vào nhánh chính, đã qua staging, đáp ứng tiêu chí bảo mật và hiệu năng. DoD là thước đo để biết một thứ có được tính vào Increment hay không.
Bước 2 — Khi refinement và planning, hãy chia nhỏ công việc sao cho mỗi item có thể "Done" độc lập. Một item quá lớn không thể đạt DoD trong một Sprint sẽ luôn nằm dang dở. Hãy ưu tiên những lát cắt mỏng nhưng dùng được (thin vertical slice) thay vì những khối lớn nửa vời.
Bước 3 — Trong Sprint, theo dõi từng item đạt Done. Mỗi khi một item chạm DoD, ghi nhận rằng một Increment mới vừa ra đời. Đừng đợi tới cuối Sprint mới kiểm tra trạng thái hoàn thành của mọi thứ một lượt.
Bước 4 — Yêu cầu tích hợp và kiểm thử hồi quy liên tục. Đảm bảo phần mới không phá vỡ phần cũ. Increment mới phải hòa hợp với toàn bộ Increment trước đó. Đây là điều kiện để Increment thực sự "usable".
Bước 5 — Tại Sprint Review, chỉ trình bày những gì đã đạt DoD. Không demo thứ chưa Done. Không dùng dữ liệu giả để "làm đẹp". Sự trung thực ở đây bảo vệ niềm tin của stakeholder.
Bước 6 — Quyết định thời điểm phát hành dựa trên giá trị, không dựa trên lịch Sprint. Nếu một Increment đã sẵn sàng và thị trường cần nó, hãy phát hành. Nếu chưa phải lúc, hãy giữ lại — nhưng đó là lựa chọn chiến lược của bạn, không phải vì sản phẩm chưa sẵn sàng.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm "việc đã làm" với "Increment". Nhiều đội liệt kê những gì họ đã code và gọi đó là Increment. Sai. Increment là phần sản phẩm dùng được, đạt DoD. Mẹo: hỏi câu thần chú "Nếu tôi phát hành nó ngay bây giờ cho khách thật, có ổn không?". Nếu câu trả lời là "chưa, vì còn...", thì đó chưa phải Increment.
Lỗi 2 — Chấp nhận "works on my machine". Tính năng chỉ chạy ở môi trường local của lập trình viên không phải Increment. Mẹo: đưa "đã chạy được trên môi trường tích hợp/staging" vào DoD như một điều kiện cứng.
Lỗi 3 — Coi Sprint Review là cổng phát hành. Một số PO nghĩ phải qua Review mới được tung Increment. Mẹo: nhớ rằng Increment có thể giao bất cứ lúc nào nó đạt Done; Review chỉ để inspect & adapt.
Lỗi 4 — Quên tính cộng dồn, bỏ kiểm thử hồi quy. Increment mới làm hỏng Increment cũ là tai họa thường gặp. Mẹo: tự động hóa kiểm thử hồi quy và tích hợp liên tục để mỗi Increment luôn đảm bảo cả sản phẩm còn nguyên vẹn.
Lỗi 5 — Nhồi quá nhiều vào một item lớn, không bao giờ Done. Mẹo: chia nhỏ thành lát cắt dọc dùng được. Thà có một tính năng nhỏ hoàn chỉnh còn hơn một tính năng lớn dang dở mãi.
Mẹo vàng cho PO: Đừng bao giờ báo cáo tiến độ với cấp trên bằng số phần trăm code đã viết. Hãy báo cáo bằng số Increment đã đạt Done và sẵn sàng phát hành. Đó mới là ngôn ngữ của giá trị.
Bài tập thực hành
- Phân biệt Increment thật và giả. Lấy ba Product Backlog Item gần nhất của đội bạn (hoặc một dự án giả định). Với mỗi item, tự trả lời: "Nếu phát hành ngay bây giờ cho khách hàng thật, nó có usable không?" Ghi rõ thứ còn thiếu để item trở thành một Increment đúng nghĩa.
- Soi lại Definition of Done. Viết ra DoD hiện tại của đội bạn. Kiểm tra xem nó có bao gồm: code review, kiểm thử, tích hợp vào nhánh chính, qua môi trường staging, kiểm thử hồi quy không. Bổ sung những điều kiện còn thiếu để đảm bảo Increment luôn usable.
- Tình huống ra quyết định. Đội bạn hoàn thành tính năng "thanh toán bằng QR" vào ngày thứ 6 của Sprint hai tuần, đạt DoD đầy đủ. Sprint Review còn 4 ngày nữa mới diễn ra. Bạn sẽ phát hành ngay hay chờ? Hãy viết ra ba yếu tố bạn cân nhắc để ra quyết định, và lập luận cho lựa chọn của mình.
- Mô phỏng sự cố cộng dồn. Hãy nghĩ về một lần (hoặc tưởng tượng một lần) tính năng mới làm hỏng tính năng cũ trong sản phẩm bạn từng làm. Điều gì trong DoD hoặc quy trình lẽ ra đã ngăn được sự cố đó? Viết một đề xuất cải tiến ngắn.
Tóm tắt
Increment là deliverable thực sự của mỗi Sprint — một bước đệm cụ thể, dùng được, hướng tới Product Goal. Hãy ghi nhớ những điểm cốt lõi:
- Increment là tổng của tất cả các phần đã hoàn thành, không chỉ phần làm trong Sprint này. Mỗi Increment phải tích hợp được với toàn bộ phần trước đó.
- Một Sprint có thể tạo ra nhiều Increment. Mỗi item đạt Definition of Done là một Increment mới ra đời.
- Increment phải usable — shippable, hoạt động đầy đủ, đã kiểm thử, sẵn sàng tạo giá trị. Loại bỏ tư duy "works on my machine".
- Definition of Done là tiêu chuẩn quyết định một thứ có được tính vào Increment hay không. Không có "hoàn thành 90%".
- Increment có thể được giao bất cứ lúc nào, không cần chờ Sprint Review. Quyết định thời điểm phát hành là quyền và trách nhiệm chiến lược của Product Owner.