SCRUM

Framework phát triển sản phẩm dựa trên Agile

3.1. Scrum ra đời để giải quyết vấn đề gì?

Sau khi hiểu Agile, sẽ xuất hiện một câu hỏi:

Agile nói rằng team cần phản hồi nhanh, thích nghi và liên tục cải tiến. Nhưng làm thế nào để tổ chức công việc thực tế?

Đó là lúc Scrum trở nên hữu ích.

Scrum // framework phát triển và duy trì sản phẩm phức tạp.

Theo Scrum Guide 2020, Scrum là một framework giúp con người, team và tổ chức tạo ra giá trị thông qua các giải pháp thích ứng cho những vấn đề phức tạp.

Framework // khung làm việc.

Scrum không phải một quy trình cứng nhắc quy định từng thao tác kỹ thuật phải làm như thế nào.

Thay vào đó, Scrum cung cấp những thành phần cốt lõi để team tổ chức công việc, kiểm tra kết quả và thích nghi.

3.2. Scrum xoay quanh một vòng lặp

Product (Sản phẩm) -> Product Backlog (Danh sách công việc sản phẩm) -> Sprint Planning (Lập kế hoạch Sprint) -> Sprint (Chu kỳ làm việc) -> Increment (Phần sản phẩm hoàn thành) -> Sprint Review (Kiểm tra kết quả và thu thập phản hồi) -> Adaptation (Thích nghi và điều chỉnh)

Tiếp tục cập nhật Product Backlog và hướng tới Sprint tiếp theo.

Đây là vòng lặp Inspect → Adapt // kiểm tra → thích nghi.

Scrum dựa trên việc thường xuyên kiểm tra kết quả thực tế và điều chỉnh hướng đi dựa trên những gì team đã quan sát, học được.

3.3. Empiricism — nền tảng của Scrum

Empiricism // chủ nghĩa kinh nghiệm là cách tiếp cận đưa ra quyết định dựa trên quan sát thực tế, kinh nghiệm và những gì đã học được.

Scrum dựa trên ba trụ cột:

Transparency

Minh bạch

Thông tin quan trọng về quá trình và kết quả công việc cần được hiển thị, hiểu và chia sẻ rõ ràng.

Inspection

Kiểm tra

Team thường xuyên kiểm tra tiến độ, kết quả và các yếu tố có thể ảnh hưởng đến mục tiêu.

Adaptation

Thích nghi

Khi phát hiện những điểm không phù hợp, team điều chỉnh quy trình hoặc sản phẩm để cải thiện kết quả.

Ví dụ:

Team phát triển Product Search

↓

Kiểm tra chức năng

↓

Phát hiện kết quả tìm kiếm không chính xác

↓

Điều chỉnh logic search

↓

Kiểm tra lại

↓

Tiếp tục cải thiện

Ba trụ cột này là nền tảng để hiểu các sự kiện và thành phần của Scrum.

3.4. Ba Accountabilities trong Scrum

Accountability // trách nhiệm phải chịu trách nhiệm về một phần công việc hoặc kết quả.

Scrum có ba nhóm trách nhiệm chính:

Mày paste Word thì dùng dạng này cho sạch:

Scrum Team → Product Owner / Scrum Master / Developers

Product Owner

Product Owner (PO) // người chịu trách nhiệm tối đa hóa giá trị của sản phẩm.

PO không đơn giản chỉ là ông sếp giao task.

Một Product Owner cần quan tâm đến:

• Người dùng cần gì?
• Business cần gì?
• Điều gì tạo ra giá trị?
• Việc nào nên được ưu tiên?
• Product Backlog cần được quản lý như thế nào?

PO chịu trách nhiệm hiệu quả đối với việc quản lý Product Backlog, bao gồm việc phát triển và truyền đạt Product Goal, tạo và làm rõ các Product Backlog Items, sắp xếp thứ tự và bảo đảm Product Backlog minh bạch, dễ hiểu.

Scrum Master

Scrum Master // người hỗ trợ team hiểu và áp dụng Scrum.

Scrum Master chịu trách nhiệm giúp Scrum được thiết lập đúng theo Scrum Guide, hỗ trợ team cải thiện hiệu quả và giải quyết những trở ngại trong quá trình làm việc.

Scrum Master không đồng nghĩa với trưởng nhóm chuyên ra lệnh cho developer.

Vai trò này còn hỗ trợ tổ chức hiểu và áp dụng Scrum, thúc đẩy các hoạt động cần thiết trong Scrum Team và giúp team tập trung vào việc tạo ra Increment có giá trị.

Developers

Developers // những người trực tiếp tạo ra Increment có thể sử dụng được.

Tùy vào sản phẩm và cấu trúc team, Developers có thể gồm:

• Front-end Developer.
• Back-end Developer.
• QA Engineer.
• Designer.
• DevOps Engineer.
• Data Engineer.

Scrum không bắt buộc phải chia team thành các nhóm FE, BE và QA riêng biệt.

Các Developers cần có những kỹ năng phù hợp để tạo ra Increment đáp ứng Definition of Done.

3.5. Scrum Team

Một Scrum Team gồm:

Product Owner

+

Scrum Master

+

Developers

=

Scrum Team

Cả team hướng tới:

Product Goal // mục tiêu dài hạn của sản phẩm.

Theo Scrum Guide 2020, Scrum Team là một team thống nhất, có khả năng tự quản lý và chịu trách nhiệm về các hoạt động cần thiết để tạo ra Increment có giá trị trong mỗi Sprint.

Scrum Team không được thiết kế theo kiểu chia thành những team con có trách nhiệm tách biệt cứng nhắc.

3.6. Scrum Events — các sự kiện trong Scrum

Scrum có một Sprint và bốn sự kiện chính diễn ra bên trong Sprint:

Sprint

│

├── Sprint Planning

│   // Lập kế hoạch Sprint

│

├── Daily Scrum

│   // Cuộc họp hằng ngày của Developers

│

├── Sprint Review

│   // Kiểm tra kết quả Sprint

│

└── Sprint Retrospective

// Nhìn lại và cải thiện cách làm việc

Sprint là sự kiện chứa đựng tất cả các sự kiện còn lại.

Các sự kiện Scrum được thiết kế để tạo ra cơ hội thường xuyên cho việc kiểm tra và thích nghi.

3.7. Sprint — chu kỳ làm việc

Sprint // một chu kỳ làm việc có độ dài cố định, trong đó team thực hiện các hoạt động cần thiết để đạt Sprint Goal và tạo ra Increment có giá trị.

Trong Scrum:

• Sprint có độ dài cố định.
• Sprint kéo dài tối đa một tháng.
• Các Sprint liên tiếp nhau.
• Một Sprint mới bắt đầu ngay sau khi Sprint trước kết thúc.

Ví dụ team lựa chọn Sprint kéo dài hai tuần:

Sprint 2 tuần

Week 1

Week 2

Sprint Review

Kiểm tra kết quả và nhận phản hồi

Sprint Retrospective

Cải thiện cách làm việc

Sprint mới

Sprint không bắt buộc phải dài một hoặc hai tuần. Team có thể chọn độ dài phù hợp, miễn không vượt quá một tháng và duy trì độ dài nhất quán.

3.8. Sprint Planning — lập kế hoạch Sprint

Planning // lập kế hoạch.

Sprint Planning là sự kiện mở đầu Sprint, nơi Scrum Team cùng xác định mục tiêu và kế hoạch công việc.

Theo Scrum Guide 2020, Sprint Planning tập trung vào ba câu hỏi:

WHY?

Tại sao Sprint này có ý nghĩa?

Team xác định Sprint Goal // mục tiêu Sprint, giải thích vì sao Sprint này có giá trị.

WHAT?

Sprint này sẽ làm gì?

Developers lựa chọn các Product Backlog Items sẽ thực hiện trong Sprint.

HOW?

Team sẽ thực hiện như thế nào?

Developers lập kế hoạch công việc để biến các Product Backlog Items được chọn thành Increment đáp ứng Definition of Done.

Ví dụ project E-commerce:

WHY? (Tại sao?) -> Tăng khả năng tìm kiếm sản phẩm cho người dùng.

WHAT? (Cái gì?) -> Search (Tìm kiếm) -> Filter (Lọc) -> Sort (Sắp xếp)

HOW? (Như thế nào?) -> FE (Front-end) -> Search UI (Giao diện tìm kiếm) -> BE (Back-end) -> Search API (API tìm kiếm) -> DB (Database) -> Index Database (Tạo chỉ mục dữ liệu) -> Testing (Kiểm thử) -> Test Search/Filter (Kiểm thử tìm kiếm và lọc)

Đây là ví dụ minh họa cách team phân tích công việc. Trong Scrum, việc chia nhỏ và tổ chức các hoạt động kỹ thuật thuộc trách nhiệm của Developers.

3.9. Product Backlog — danh sách công việc sản phẩm

Product Backlog // danh sách công việc sản phẩm là danh sách có thứ tự các công việc cần thiết để cải thiện sản phẩm.

Product Backlog không phải một danh sách cố định được tạo ra từ đầu dự án và giữ nguyên đến khi kết thúc.

Nó liên tục thay đổi khi team thu thập thêm thông tin, nhận phản hồi và hiểu rõ hơn về sản phẩm.

Ví dụ:

PRODUCT BACKLOG

Minh họa thứ tự ưu tiên

P0 (Ưu tiên cao trong ví dụ) -> Login -> Product Detail -> Checkout -> P1 (Ưu tiên tiếp theo) -> Search -> Filter -> Wishlist -> P2 (Ưu tiên thấp hơn trong ví dụ) -> AI Chatbot -> Recommendation

Trong thực tế, Product Backlog được sắp xếp theo thứ tự và có thể thay đổi liên tục. P0, P1, P2 ở đây chỉ là cách minh họa, không phải cấu trúc bắt buộc của Scrum.

3.10. Sprint Backlog — danh sách công việc của Sprint

Sprint Backlog // danh sách công việc của Sprint bao gồm:

• Sprint Goal.
• Các Product Backlog Items được lựa chọn cho Sprint.
• Kế hoạch hành động để tạo ra Increment.

Phân biệt:

Product Backlog

// Toàn bộ công việc có thể cần cho sản phẩm

↓

Lựa chọn cho Sprint

↓

Sprint Backlog

// Mục tiêu, công việc và kế hoạch của Sprint

Ví dụ:

Product Backlog

├── Login

├── Register

├── Search

├── Filter

├── Cart

├── Payment

├── AI

└── Analytics

Team chọn một số công việc phù hợp cho Sprint 1:

Sprint Backlog

├── Login

├── Register

└── Forgot password

Sprint Backlog thuộc quyền quản lý của Developers và được cập nhật trong suốt Sprint khi team học hỏi thêm về công việc.

3.11. Increment — phần sản phẩm được hoàn thành

Increment // phần gia tăng của sản phẩm là một bước tiến cụ thể hướng tới Product Goal.

Một Increment phải đáp ứng Definition of Done // định nghĩa hoàn thành.

Ví dụ, Sprint 1 phát triển:

Login

Register

Forgot password

Nếu các chức năng này đáp ứng Definition of Done và tích hợp phù hợp với những Increment trước đó, chúng có thể tạo thành một Increment.

Increment phải có khả năng sử dụng được và đáp ứng các yêu cầu chất lượng đã thống nhất.

Điều quan trọng là không phải cứ hoàn thành code của một task thì mặc nhiên có một Increment hoàn chỉnh.

3.12. Daily Scrum — cuộc họp hằng ngày

Daily Scrum // sự kiện hằng ngày của Developers, nhằm kiểm tra tiến độ hướng tới Sprint Goal và điều chỉnh Sprint Backlog khi cần thiết.

Daily Scrum:

• Diễn ra mỗi ngày làm việc của Sprint.
• Có thời lượng tối đa 15 phút.
• Dành cho Developers.
• Có thể sử dụng nhiều cách tổ chức khác nhau miễn đạt được mục tiêu.

Một ví dụ:

Dev A:

Login API xong.

 

Dev B:

Login UI xong nhưng API contract đang lệch.

 

Dev C:

Testing chưa bắt đầu.

 

Team:

→ Thống nhất sửa API contract trước.

Daily Scrum không phải buổi báo cáo cho sếp. Đây là cơ hội để Developers kiểm tra tình hình và chủ động điều chỉnh kế hoạch trong ngày tiếp theo.

3.13. Sprint Review — kiểm tra kết quả Sprint

Sprint Review // sự kiện kiểm tra kết quả Sprint và xác định những điều chỉnh cần thiết cho tương lai.

Sprint Review diễn ra vào cuối Sprint, với sự tham gia của Scrum Team và các stakeholder phù hợp.

Stakeholder // những người có lợi ích hoặc chịu ảnh hưởng từ sản phẩm.

Mục tiêu của Sprint Review không chỉ là demo sản phẩm.

Team cùng stakeholder:

• Kiểm tra Increment đã được tạo ra.
• Xem xét tiến độ hướng tới Product Goal.
• Trao đổi về những thay đổi trong môi trường, thị trường và nhu cầu.
• Thu thập phản hồi.
• Điều chỉnh Product Backlog khi cần.

Ví dụ:

Team trình bày chức năng Product Search.

Khách hàng phản hồi:

“Search được rồi nhưng user cần tìm theo brand nữa.”

Team có thể ghi nhận yêu cầu mới, xem xét mức độ ưu tiên và cập nhật Product Backlog.

Increment

// Phần sản phẩm đã hoàn thành

↓

Sprint Review

// Kiểm tra và trao đổi

↓

Feedback

// Phản hồi

↓

Adapt Product Backlog

// Điều chỉnh danh sách công việc

↓

Sprint tiếp theo

Sprint Review không phải một buổi nghiệm thu cứng nhắc để khách hàng chỉ có thể nói đạt hoặc không đạt. Đây là hoạt động cộng tác để xác định hướng phát triển tiếp theo.

3.14. Sprint Retrospective — nhìn lại và cải thiện

Sprint Retrospective // sự kiện nhìn lại cách làm việc của Scrum Team để xác định các cải tiến có thể thực hiện.

Cần phân biệt:

Sprint Review

Product có đang tạo ra giá trị không?

Tập trung vào sản phẩm, Increment, tiến độ hướng tới Product Goal và phản hồi từ stakeholder.

Sprint Retrospective

Cách team làm việc có hiệu quả không?

Tập trung vào con người, sự tương tác, quy trình, công cụ và chất lượng công việc.

Ví dụ:

Sprint Review:

Khách hàng thích chức năng Search.

Sprint Retrospective:

Team nhận thấy quá trình Pull Request review đang diễn ra quá chậm.

Team có thể thống nhất một số cải tiến:

Sprint 1

↓

Phát hiện vấn đề

 

❌ PR review quá chậm

❌ API documentation thiếu

✅ FE/BE phối hợp tốt

↓

Retrospective

↓

Đưa ra hành động cải tiến

 

→ PR cần được review trong 24 giờ

→ BE cần document API

→ Tiếp tục duy trì cách phối hợp FE/BE

↓

Sprint 2

↓

Thử áp dụng

↓

Kiểm tra kết quả

Sprint Retrospective là một trong những cơ hội quan trọng để Scrum Team cải thiện hiệu quả làm việc liên tục.

3.15. Scrum Artifacts — ba hiện vật của Scrum

Artifact // hiện vật, thông tin hoặc sản phẩm được tạo ra và quản lý trong Scrum.

Scrum có ba Artifacts chính:

Product Backlog (Danh sách công việc sản phẩm) -> Product Goal (Cam kết) -> Lựa chọn công việc cho Sprint -> Sprint Backlog (Danh sách công việc của Sprint) -> Sprint Goal (Cam kết) -> Thực hiện trong Sprint -> Increment (Phần sản phẩm hoàn thành) -> Definition of Done (Cam kết)

Mỗi Artifact có một Commitment tương ứng:

Artifact	Commitment	Ý nghĩa
Product Backlog	Product Goal	Mục tiêu dài hạn của sản phẩm
Sprint Backlog	Sprint Goal	Mục tiêu của Sprint
Increment	Definition of Done (DoD)	Tiêu chuẩn chất lượng để xác định Increment hoàn thành

Ba Artifact này giúp tăng tính minh bạch và tạo cơ sở để kiểm tra kết quả thực tế.

3.16. Một task đi xuyên suốt Scrum như thế nào?

Bây giờ lấy ví dụ một yêu cầu từ Product Owner:

“Tao muốn khách hàng đăng nhập bằng Google.”

Một ý tưởng không có nghĩa developer lập tức bắt tay vào code. Yêu cầu cần được làm rõ, xem xét và đưa vào kế hoạch phù hợp.

Idea (Ý tưởng) -> Requirement (Yêu cầu) -> User Story (Câu chuyện người dùng) -> Acceptance Criteria (Điều kiện chấp nhận) -> Product Backlog (Danh sách công việc sản phẩm) -> Prioritization (Sắp xếp ưu tiên) -> Sprint Planning (Lập kế hoạch Sprint) -> Sprint Backlog (Danh sách công việc Sprint) -> Development (Phát triển) -> Testing (Kiểm thử) -> Increment (Phần sản phẩm hoàn thành) -> Sprint Review (Kiểm tra kết quả) -> Feedback (Phản hồi) -> Backlog Adaptation (Điều chỉnh Backlog)

Đây là một luồng minh họa để hiểu cách một yêu cầu có thể đi qua quá trình phát triển. Trong Scrum thực tế, các hoạt động làm rõ, kiểm thử và thu thập phản hồi có thể diễn ra xuyên suốt Sprint chứ không phải lúc nào cũng tách thành những bước tuần tự cứng nhắc.

3.17. User Story — câu chuyện người dùng

User Story // câu chuyện người dùng là một cách phổ biến để mô tả nhu cầu của người dùng dưới góc nhìn của chính họ.

Format thường gặp:

As a useruser, I want somethingsomething, so that benefitbenefit.

Dịch nghĩa:

Tôi là ai → Tôi muốn gì → Để làm gì.

Ví dụ trong project E-commerce:

As a customer, I want to search products, so that I can quickly find shoes I want.

// Là khách hàng, tôi muốn tìm kiếm sản phẩm để nhanh chóng tìm được đôi giày mình muốn.

Phân tích:

Thành phần	Nội dung	Giải thích
As a customer	Là khách hàng	Ai có nhu cầu?
I want to search products	Tôi muốn tìm kiếm sản phẩm	Người dùng muốn làm gì?
So that I can quickly find shoes I want	Để nhanh chóng tìm được đôi giày mình muốn	Vì sao nhu cầu này có giá trị?

User Story giúp team tập trung vào nhu cầu và giá trị thay vì chỉ mô tả một danh sách thao tác kỹ thuật.

Lưu ý: User Story là một kỹ thuật mô tả yêu cầu phổ biến trong Agile, không phải một cấu trúc bắt buộc được quy định trong Scrum Guide.

3.18. Acceptance Criteria — điều kiện chấp nhận

Acceptance Criteria // điều kiện chấp nhận là các điều kiện cụ thể để xác định một yêu cầu đã đáp ứng những mong đợi được đặt ra hay chưa.

Ví dụ, User Story:

Khách hàng muốn tìm kiếm sản phẩm.

Một cách mô tả điều kiện chấp nhận phổ biến là sử dụng cấu trúc Given – When – Then.

• Given // với điều kiện ban đầu.
• When // khi xảy ra một hành động.
• Then // kết quả mong đợi.

Ví dụ:

Given

// Với điều kiện ban đầu

 

User đang ở trang Product

 

When

// Khi

 

User nhập “Nike”

 

Then

// Thì

 

Hệ thống chỉ hiển thị

những sản phẩm phù hợp

Một số điều kiện khác:

– Không có kết quả → hiển thị empty state

– Search không phân biệt hoa thường

– Có thể xóa keyword

– Kết quả phản hồi trong thời gian hợp lý

Acceptance Criteria giúp developer và người yêu cầu có cùng cách hiểu về kết quả mong đợi.

Cần phân biệt Acceptance Criteria với Definition of Done:

• Acceptance Criteria mô tả những điều kiện mà một yêu cầu cụ thể cần đáp ứng.
• Definition of Done mô tả tiêu chuẩn chất lượng chung mà Increment phải đáp ứng.

3.19. Epic, Feature, Task và Bug

Trong quá trình quản lý công việc, team thường gặp những thuật ngữ sau:

Thuật ngữ	Giải thích	Ví dụ
Epic	Nhóm công việc hoặc chức năng lớn, có thể cần nhiều phần nhỏ để hoàn thành	Authentication
Feature	Một chức năng hoặc khả năng cụ thể của sản phẩm	Đăng nhập bằng Google
User Story	Mô tả nhu cầu của người dùng	Khách hàng muốn đăng nhập nhanh bằng Google
Task	Công việc cụ thể cần thực hiện	Tạo Google OAuth callback
Bug	Lỗi khiến phần mềm hoạt động không đúng mong đợi	Đăng nhập Google bị lỗi khi callback

Các thuật ngữ này thường được sử dụng trong Jira và nhiều công cụ quản lý dự án khác.

Không có một cấu trúc phân cấp Epic → Feature → User Story → Task bắt buộc áp dụng cho tất cả team. Cách tổ chức có thể khác nhau tùy quy trình quản lý công việc.

3.20. Backlog Refinement — làm rõ Product Backlog

Backlog Refinement // hoạt động làm rõ Product Backlog là quá trình chia nhỏ, làm rõ, ước lượng và sắp xếp lại các Product Backlog Items khi cần.

Ví dụ:

Ban đầu, Product Backlog có một mục:

Product Search

// Tìm kiếm sản phẩm

Team nhận thấy công việc quá lớn và cần được làm rõ.

Sau khi Refinement:

Product Search

│

├── Search UI

│   // Giao diện tìm kiếm

│

├── Search API

│   // API tìm kiếm

│

├── Search by name

│   // Tìm theo tên

│

├── Search by brand

│   // Tìm theo thương hiệu

│

└── Search testing

// Kiểm thử chức năng tìm kiếm

Team cũng có thể thảo luận thêm về Acceptance Criteria, phụ thuộc kỹ thuật và độ lớn tương đối của từng mục.

Backlog Refinement là một hoạt động liên tục, không phải một sự kiện Scrum chính thức có thời lượng cố định trong Scrum Guide.

3.21. Estimation — ước lượng công việc

Estimation // ước lượng là hoạt động đánh giá độ lớn, độ phức tạp hoặc công sức cần thiết để hoàn thành một công việc.

Trong phát triển phần mềm, việc ước lượng có thể hỗ trợ team:

• Lập kế hoạch.
• Đánh giá khối lượng công việc.
• Phát hiện những nhiệm vụ quá lớn hoặc chưa rõ ràng.
• Trao đổi về độ phức tạp và rủi ro.
• Xác định khả năng thực hiện trong Sprint.

Ước lượng không đồng nghĩa với cam kết chắc chắn về thời gian hoàn thành.

Story Point

Story Point // điểm câu chuyện là một đơn vị ước lượng tương đối được nhiều team sử dụng để đánh giá độ lớn của User Story.

Story Point thường phản ánh nhiều yếu tố như:

• Độ phức tạp.
• Khối lượng công việc.
• Mức độ không chắc chắn.
• Những rủi ro liên quan.

Ví dụ minh họa:

User Story	Story Point
Hiển thị tên sản phẩm	1
Tìm kiếm theo tên	3
Tìm kiếm và lọc nhiều điều kiện	5
Tích hợp thanh toán trực tuyến	8

Đây chỉ là ví dụ. Không có quy đổi cố định giữa Story Point và số giờ làm việc.

Planning Poker

Planning Poker // phương pháp ước lượng theo nhóm.

Các thành viên cùng đánh giá độ lớn của User Story bằng những thẻ có giá trị quy ước, thường theo dãy Fibonacci hoặc các dãy tương tự.

Ví dụ:

Story:

Tích hợp đăng nhập Google

 

Developer A: 3

Developer B: 5

Developer C: 8

Khi kết quả chênh lệch, team thảo luận về các giả định, độ phức tạp và rủi ro trước khi tiếp tục ước lượng.

Mục tiêu không phải ép mọi người đưa ra cùng một con số ngay từ đầu, mà là tạo cơ hội để làm rõ sự khác biệt trong cách hiểu công việc.

3.22. Velocity — tốc độ hoàn thành công việc

Velocity // tốc độ hoàn thành công việc là lượng công việc mà team hoàn thành trong một Sprint, thường được đo bằng Story Point nếu team sử dụng phương pháp ước lượng này.

Tuy nhiên:

• Velocity không phải chỉ số đo năng suất cá nhân.
• Không nên dùng để so sánh trực tiếp hai team có cách ước lượng khác nhau.
• Velocity không phải mục tiêu bắt buộc phải tăng qua từng Sprint.
• Velocity không được quy định là một thành phần bắt buộc của Scrum.

3.23. Burndown Chart — biểu đồ công việc còn lại

Burndown Chart // biểu đồ thể hiện lượng công việc còn lại theo thời gian.

Biểu đồ này thường được dùng để theo dõi tiến độ của Sprint hoặc dự án.

Ví dụ, team có 40 Story Point trong Sprint:

Ngày 1: 40 điểm còn lại

Ngày 2: 35 điểm còn lại

Ngày 3: 32 điểm còn lại

Ngày 4: 28 điểm còn lại

Ngày 5: 20 điểm còn lại

Chia sẻ

Tùy chọn biểu đồ

Burndown Chart minh họa

Số Story Point còn lại qua các ngày trong Sprint.

Biểu đồ giúp team quan sát lượng công việc còn lại và nhận biết những thay đổi trong tiến độ.

Tuy nhiên, Burndown Chart không phải công cụ bắt buộc của Scrum. Team có thể dùng những cách trực quan hóa khác để kiểm tra tiến độ.

3.24. Product Goal và Sprint Goal

Hai khái niệm này giúp kết nối mục tiêu dài hạn của sản phẩm với công việc trong từng Sprint.

Product Goal // mục tiêu sản phẩm là trạng thái tương lai mà sản phẩm hướng tới.

Ví dụ:

Xây dựng nền tảng bán giày trực tuyến cho phép khách hàng tìm kiếm, lựa chọn và mua sản phẩm thuận tiện.

Sprint Goal // mục tiêu Sprint là mục tiêu thống nhất của Sprint, giúp team tập trung vào một kết quả có ý nghĩa.

Ví dụ:

Giúp khách hàng tìm kiếm và lọc sản phẩm theo tên và thương hiệu.

Có thể hình dung:

Product Goal

// Mục tiêu dài hạn

↓

Sprint Goal 1

// Mục tiêu Sprint 1

↓

Sprint Goal 2

// Mục tiêu Sprint 2

↓

Sprint Goal 3

// Mục tiêu Sprint 3

↓

Tiến gần hơn đến Product Goal

Sprint Goal không phải danh sách task. Nó thể hiện mục đích chung của Sprint và giúp Developers linh hoạt điều chỉnh kế hoạch khi cần.

3.25. Definition of Done — định nghĩa hoàn thành

Definition of Done (DoD) // định nghĩa hoàn thành là mô tả chính thức về trạng thái chất lượng mà một Increment phải đáp ứng.

Ví dụ, team E-commerce thống nhất DoD như sau:

Definition of Done

 

[ ] Code đã được hoàn thành

[ ] Đã thực hiện Code Review

[ ] Đã vượt qua các bài kiểm thử cần thiết

[ ] Đáp ứng Acceptance Criteria

[ ] Không còn lỗi nghiêm trọng chưa xử lý

[ ] Đã tích hợp vào hệ thống

[ ] Đáp ứng các tiêu chuẩn chất lượng chung

Đây là ví dụ về một DoD có thể được điều chỉnh theo sản phẩm và team, không phải một checklist bắt buộc giống nhau cho mọi dự án.

DoD giúp cả team có cùng cách hiểu về chất lượng và trạng thái hoàn thành.

3.26. Technical Debt — nợ kỹ thuật

Technical Debt // nợ kỹ thuật là những hệ quả phát sinh khi team lựa chọn giải pháp kỹ thuật tạm thời hoặc chưa tối ưu, khiến công việc sửa đổi và bảo trì về sau có thể tốn thêm chi phí.

Ví dụ:

Cần hoàn thành tính năng gấp

↓

Viết code tạm thời

↓

Chức năng chạy được

↓

Không refactor

// Không tái cấu trúc code

↓

Code ngày càng khó bảo trì

↓

Những thay đổi sau này tốn nhiều thời gian hơn

Technical Debt không phải lúc nào cũng là lỗi. Một số quyết định đánh đổi có thể hợp lý trong bối cảnh cụ thể, miễn là team hiểu rõ hệ quả và có kế hoạch xử lý phù hợp.

Tuy nhiên, nếu nợ kỹ thuật tích lũy quá nhiều, khả năng thay đổi và phát triển sản phẩm có thể suy giảm.

3.27. Từ Scrum đến công việc Front-end và Full-stack thực tế

Đây là phần nối những kiến thức Agile và Scrum với các công cụ, quy trình mà developer thường sử dụng.

Giả sử team nhận yêu cầu:

Khách hàng muốn đăng nhập bằng Google.

Một luồng công việc minh họa:

User Story (Mô tả nhu cầu người dùng) -> Epic / Feature / Task / Bug (Tổ chức và chia nhỏ công việc) -> Backlog Refinement (Làm rõ yêu cầu và các công việc) -> Story Point (Ước lượng độ lớn tương đối) -> Planning Poker (Thảo luận và ước lượng theo nhóm) -> Sprint Planning (Chọn mục tiêu và lập kế hoạch Sprint) -> Jira (Theo dõi và quản lý công việc) -> Git Branch (Tạo nhánh phát triển) -> Commit (Ghi nhận thay đổi mã nguồn) -> Pull Request (Đề nghị tích hợp code và yêu cầu review) -> Code Review (Kiểm tra mã nguồn) -> CI (Tự động build và kiểm thử) -> Testing (Kiểm thử chức năng và chất lượng) -> CD (Chuẩn bị hoặc tự động triển khai) -> Deployment (Đưa ứng dụng lên môi trường triển khai) -> Production (Môi trường chạy thực tế) -> Monitoring (Theo dõi hệ thống) -> Analytics (Phân tích dữ liệu sử dụng) -> Customer Feedback (Thu thập phản hồi khách hàng) -> Product Backlog (Cập nhật và điều chỉnh công việc)

Các thuật ngữ kỹ thuật cần hiểu rõ:

Git

Git // hệ thống quản lý phiên bản phân tán, giúp theo dõi lịch sử thay đổi của mã nguồn và hỗ trợ nhiều developer cùng làm việc.

GitHub

GitHub // nền tảng lưu trữ repository Git và hỗ trợ cộng tác trong quá trình phát triển phần mềm.

Branch

Branch // nhánh là một dòng phát triển độc lập trong repository Git.

Ví dụ:

main

│

├── feature/google-login

│

├── feature/product-search

│

└── fix/login-error

Mỗi nhánh có thể được sử dụng để phát triển một tính năng hoặc sửa một lỗi mà không phải trực tiếp thay đổi nhánh chính.

Commit

Commit // bản ghi thay đổi là một mốc ghi nhận những thay đổi trong repository Git.

Ví dụ:

git add .

git commit -m “feat: add Google login”

Pull Request

Pull Request (PR) // yêu cầu tích hợp là đề nghị đưa các thay đổi từ một nhánh vào nhánh khác để kiểm tra, thảo luận và tích hợp.

Ví dụ:

feature/google-login

↓

Pull Request

↓

Code Review

↓

CI checks

↓

Merge

↓

main

Code Review

Code Review // đánh giá mã nguồn là quá trình thành viên khác kiểm tra code trước khi tích hợp.

Mục đích có thể bao gồm:

• Phát hiện lỗi.
• Kiểm tra logic.
• Cải thiện khả năng đọc và bảo trì code.
• Kiểm tra các tiêu chuẩn kỹ thuật.
• Chia sẻ kiến thức trong team.

CI — Continuous Integration

CI (Continuous Integration) // tích hợp liên tục là hoạt động thường xuyên tích hợp những thay đổi mã nguồn vào hệ thống chung, thường đi kèm với việc tự động build và kiểm thử.

Ví dụ:

Developer push code

↓

GitHub Actions

↓

Install dependencies

↓

Build

↓

Run tests

↓

Report results

CD — Continuous Delivery / Continuous Deployment

CD có thể mang hai ý nghĩa:

• Continuous Delivery // phân phối liên tục: tự động hóa việc kiểm tra và chuẩn bị phần mềm để có thể phát hành.
• Continuous Deployment // triển khai liên tục: tự động đưa những thay đổi đáp ứng điều kiện vào môi trường triển khai, thường là production.

Hai khái niệm có liên quan nhưng không hoàn toàn giống nhau.

Deployment

Deployment // triển khai là quá trình đưa ứng dụng hoặc phiên bản phần mềm lên một môi trường để sử dụng.

Ví dụ:

Local

// Môi trường máy cá nhân

↓

Development

// Môi trường phát triển

↓

Staging

// Môi trường kiểm thử trước production

↓

Production

// Môi trường thực tế

Production

Production // môi trường thực tế là nơi ứng dụng được vận hành để phục vụ người dùng thật.

Đưa code lên production không có nghĩa quá trình phát triển đã kết thúc. Team còn cần theo dõi, bảo trì, sửa lỗi và tiếp tục cải tiến.

Monitoring

Monitoring // giám sát hệ thống là hoạt động theo dõi tình trạng vận hành của ứng dụng.

Ví dụ:

• Tỷ lệ lỗi.
• Thời gian phản hồi API.
• Mức sử dụng tài nguyên.
• Trạng thái server.
• Những sự cố ảnh hưởng đến người dùng.

Analytics

Analytics // phân tích dữ liệu là quá trình thu thập và phân tích thông tin nhằm hiểu cách người dùng tương tác với sản phẩm.

Ví dụ:

User truy cập Product Search

↓

Ghi nhận sự kiện

↓

Phân tích hành vi

↓

Phát hiện người dùng ít sử dụng Filter

↓

Team xem xét nguyên nhân

↓

Cải thiện chức năng

3.28. Scrum trong một dự án E-commerce hoàn chỉnh

Cuối cùng, ghép toàn bộ kiến thức lại bằng một dự án minh họa.

Product — sản phẩm

E-commerce Platform // nền tảng thương mại điện tử.

E-commerce Platform

Cấu trúc chức năng minh họa

Epic: Authentication

Nhóm chức năng xác thực

Login

Register

Forgot password

Epic: Product

Nhóm chức năng sản phẩm

Product list

Product detail

Search / filter

Epic: Cart

Nhóm chức năng giỏ hàng

Add to cart

Update quantity

Checkout

Epic: AI

Nhóm chức năng AI

AI chatbot

Product recommendation

Analytics

Product Goal — mục tiêu sản phẩm

Xây dựng nền tảng bán giày trực tuyến cho phép khách hàng tìm kiếm, lựa chọn và mua sản phẩm.

Product Backlog — danh sách công việc sản phẩm

Team xây dựng danh sách các yêu cầu có thể cần thực hiện:

Product Backlog

 

Epic: Authentication

├── Login

├── Register

└── Forgot password

 

Epic: Product

├── Product list

├── Product detail

├── Search

└── Filter

 

Epic: Cart

├── Add to cart

├── Update quantity

└── Checkout

 

Epic: AI

├── AI chatbot

├── Product recommendation

└── Analytics

Sprint 1 — đăng ký và đăng nhập

Sprint Goal:

Khách hàng có thể tạo tài khoản và đăng nhập vào hệ thống.

Sprint Backlog:

User Story:

“Là khách hàng,

tôi muốn đăng ký tài khoản

để sử dụng hệ thống.”

 

Tasks:

├── Create register UI

├── Create register API

├── Validate input

├── Hash password

├── Save user

└── Test register

Trong Sprint này, team có thể phân công và phối hợp các công việc FE, BE, DB và Testing để tạo ra Increment.

Sprint Review

Team trình bày chức năng đã hoàn thành, kiểm tra kết quả và trao đổi với stakeholder.

Ví dụ, khách hàng đề xuất bổ sung đăng nhập Google.

Team ghi nhận phản hồi và cập nhật Product Backlog nếu phù hợp.

Sprint Retrospective

Team nhìn lại quá trình làm việc và nhận thấy:

• API contract chưa được thống nhất từ đầu.
• PR review mất nhiều thời gian.
• FE và BE phối hợp tốt khi cùng kiểm tra API.

Team quyết định cải thiện quy trình thống nhất API contract và rút ngắn thời gian review.

Sprint 2 — tìm kiếm sản phẩm

Sprint Goal:

Giúp khách hàng tìm kiếm sản phẩm theo tên và thương hiệu.

Sprint Backlog minh họa:

User Story:

“Là khách hàng,

tôi muốn tìm kiếm sản phẩm

để nhanh chóng tìm được đôi giày mình muốn.”

 

Tasks:

├── Create search UI

├── Create search API

├── Search by product name

├── Search by brand

├── Add database index

└── Test search

Kết thúc Sprint, team kiểm tra Increment và thu thập phản hồi để điều chỉnh Product Backlog.

Những Sprint tiếp theo có thể tập trung vào giỏ hàng, thanh toán, AI chatbot và các chức năng khác tùy theo ưu tiên và thông tin thực tế.