Agile và Scrum khác nhau như thế nào?

Agile là triết lý/mindset về phát triển phần mềm linh hoạt, được định nghĩa trong Agile Manifesto 2001. Scrum là một framework cụ thể để triển khai Agile, với roles (PO, SM, Dev Team), ceremonies (Sprint Planning, Daily, Review, Retro), và artifacts (Backlog, Increment). Agile là 'cái gì', Scrum là 'làm thế nào'.

Sprint nên dài bao lâu?

Scrum Guide khuyến nghị Sprint 1-4 tuần. Phổ biến nhất là 2 tuần (14 ngày). Team mới nên bắt đầu với Sprint 2 tuần: đủ ngắn để học nhanh từ feedback, đủ dài để deliver meaningful features. Tránh Sprint 1 tuần khi mới bắt đầu — quá nhiều overhead từ ceremonies.

Team nhỏ 3-5 người có cần đủ 3 roles Scrum không?

Có, nhưng 1 người có thể đảm nhận nhiều roles. Ví dụ: Tech Lead làm Scrum Master + tham gia Dev Team. Product Manager làm Product Owner. Tuy nhiên, không nên để 1 người vừa là PO vừa là SM vì conflict of interest. Với team 3 người, thường Tech Lead = SM, PM = PO, còn lại là Dev Team.

Agile Scrum có phù hợp cho dự án không phải phần mềm không?

Có, Scrum đang được áp dụng rộng rãi ngoài phần mềm: marketing campaigns, HR onboarding, xây dựng nội dung, thiết kế sản phẩm. Nguyên tắc cốt lõi vẫn áp dụng được: chia nhỏ work, deliver thường xuyên, inspect và adapt. Tuy nhiên, cần điều chỉnh terminology và ceremonies cho phù hợp với từng lĩnh vực.

Scrum Master có cần chứng chỉ CSM không?

Chứng chỉ CSM (Certified ScrumMaster) từ Scrum Alliance hoặc PSM (Professional Scrum Master) từ Scrum.org hữu ích nhưng không bắt buộc để bắt đầu. Nhiều Scrum Master hiệu quả tự học từ sách 'Scrum Guide' (miễn phí tại Scrum.org) và thực hành thực tế. Nếu muốn làm nghề chuyên nghiệp, PSM I của Scrum.org ($150) được đánh giá cao hơn CSM.

Agile Scrum Cho Người Mới: Hướng Dẫn Thực Hành A-Z [2026]

Agile Scrum là phương pháp quản lý dự án được hơn 70% công ty phần mềm toàn cầu áp dụng — nhưng nhiều team Việt Nam vẫn đang làm sai hoàn toàn.

Hướng dẫn thực hành Agile Scrum từ A-Z: các roles, ceremonies, artifacts, và cách triển khai Scrum thực tế trong 2 tuần — kể cả khi team chưa có kinh nghiệm.

Mục lục bài viết:

1. Agile là gì? Tại sao không phải là "làm nhanh rồi xem"?
2. Scrum Framework — 3 pillars, 5 values
3. 3 Scrum Roles: Product Owner, Scrum Master, Dev Team
4. Scrum Artifacts: Product Backlog, Sprint Backlog, Increment
5. 5 Scrum Ceremonies và cách tổ chức hiệu quả
6. Triển khai Scrum thực tế trong 2 tuần đầu
7. 7 lỗi Scrum phổ biến nhất và cách tránh
8. Công cụ hỗ trợ Agile Scrum
9. Câu hỏi thường gặp (FAQ)

1. Agile Là Gì? Tại Sao Không Phải Là "Làm Nhanh Rồi Xem"?

Nhiều người nghe đến Agile và nghĩ đó là "làm không có kế hoạch, cứ làm rồi tính". Đây là hiểu lầm phổ biến nhất và nguy hiểm nhất. Agile không phải là vô tổ chức — đây là triết lý quản lý dự án có cấu trúc chặt chẽ, nhưng linh hoạt với thay đổi.

Agile Manifesto (2001) — 4 giá trị cốt lõi:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

Lưu ý: "While there is value in the items on the right, we value the items on the left more." — Không phải bỏ planning, mà là ưu tiên linh hoạt hơn cứng nhắc.

Agile vs Waterfall — sự khác biệt cốt lõi:

Tiêu chí	Waterfall	Agile
Lập kế hoạch	Chi tiết từ đầu, cố định	Rolling wave, thích nghi
Deliverable	Cuối dự án mới có sản phẩm	Mỗi sprint có increment
Feedback	Cuối dự án (quá muộn)	Mỗi 2 tuần (kịp thời)
Thay đổi yêu cầu	Khó, tốn kém	Chào đón, linh hoạt
Phù hợp nhất	Dự án xây dựng, yêu cầu cố định	Phần mềm, sáng tạo, không chắc chắn

2. Scrum Framework — Khung Làm Việc Phổ Biến Nhất Của Agile

Scrum là framework cụ thể nhất để triển khai Agile. Theo Scrum Alliance, 87% các team Agile dùng Scrum. Scrum hoạt động theo các vòng lặp ngắn (Sprint) từ 1-4 tuần, mỗi sprint tạo ra một sản phẩm có thể demo được.

3 Pillars của Scrum:

👁️

Transparency (Minh bạch)

Mọi thứ phải visible với toàn team: backlog, tiến độ, blockers. Không ai được giấu thông tin.

🔍

Inspection (Kiểm tra)

Thường xuyên inspect progress và product để phát hiện vấn đề sớm — không đợi đến cuối dự án.

🔄

Adaptation (Thích nghi)

Khi phát hiện vấn đề, điều chỉnh ngay — không cứng nhắc theo kế hoạch đã lỗi thời.

5 Values của Scrum:

💪

Commitment

Cam kết với mục tiêu Sprint

🎯

Focus

Tập trung vào Sprint Goal

🔓

Openness

Cởi mở về progress và blockers

🤝

Respect

Tôn trọng nhau, không đổ lỗi

🦁

Courage

Dũng cảm nói sự thật, raise flag sớm

3. 3 Scrum Roles — Ai Làm Gì Trong Team?

👤

Product Owner (PO)

Đại diện stakeholder, quyết định ưu tiên

Trách nhiệm chính:

• Sở hữu và quản lý Product Backlog
• Viết và ưu tiên User Stories
• Định nghĩa Sprint Goal
• Chấp nhận hoặc từ chối deliverable
• Là cầu nối giữa business và dev team

Lỗi phổ biến:

❌ PO can thiệp vào cách dev team làm việc
❌ Thay đổi Sprint Goal giữa Sprint
❌ Không sẵn sàng trả lời câu hỏi của team
❌ Backlog không được groomed thường xuyên

🛡️

Scrum Master (SM)

Servant-leader, bảo vệ team và loại bỏ blockers

Trách nhiệm chính:

• Tổ chức và faciliate các Scrum ceremonies
• Loại bỏ impediments (blockers) của team
• Coach team về Scrum practices
• Bảo vệ team khỏi external interruptions
• Giúp PO quản lý backlog hiệu quả

SM không phải là:

❌ Project Manager (không assign task)
❌ Technical Lead (không quyết định tech)
❌ Secretary (không chỉ note-taking)
❌ Boss (không có authority với team)

⚙️

Development Team

Self-organizing, cross-functional, 3-9 người

Đặc điểm:

• Cross-functional: có đủ skill để deliver
• Self-organizing: tự quyết định cách làm
• 3-9 người (7±2 là optimal)
• Không có sub-team hay hierarchy
• Cùng cam kết với Sprint Goal

Self-organizing nghĩa là:

✓ Team tự chọn task từ Sprint Backlog
✓ Team tự estimate story points
✓ Team tự quyết định technical approach
✓ Không ai assign task cho developer

4. Scrum Artifacts — 3 Artifacts Cốt Lõi

📋 Product Backlog

Danh sách tất cả những gì cần làm cho sản phẩm. PO sở hữu và ưu tiên. Luôn được cập nhật và "groomed" (làm mịn).

Mỗi item trong backlog cần có:

• User Story hoặc mô tả rõ ràng
• Acceptance Criteria
• Priority (MoSCoW hoặc số)
• Story Points estimate
• Definition of Ready

📌 Sprint Backlog

Tập hợp items từ Product Backlog được chọn vào Sprint hiện tại. Dev team sở hữu Sprint Backlog — chỉ team mới có thể thay đổi nội dung Sprint đang chạy.

Sprint Backlog bao gồm:

• Sprint Goal (1-2 câu mục tiêu)
• Danh sách Stories đã chọn
• Tasks chia nhỏ từ mỗi Story
• Hours estimate cho mỗi task

🚀 Increment

Kết quả cuối mỗi Sprint — phải là sản phẩm "potentially shippable" đáp ứng Definition of Done. Không phải prototype hay demo.

Definition of Done (DoD) mẫu:

✓ Code reviewed và merged
✓ Unit tests pass (coverage >80%)
✓ Deployed to staging
✓ QA tested và sign-off
✓ Documentation updated

5. 5 Scrum Ceremonies — Tổ Chức Sao Cho Không Lãng Phí Thời Gian

Sprint Planning

Đầu Sprint | Max 8h/4 tuần sprint

Toàn team cùng nhau xác định: "Chúng ta sẽ deliver gì trong Sprint này và làm như thế nào?" PO giới thiệu top items từ Product Backlog, team estimate và chọn items phù hợp với capacity.

Agenda: (1) PO present Sprint Goal → (2) Team review top backlog items → (3) Team estimate story points → (4) Team chọn items phù hợp velocity → (5) Team break items thành tasks → (6) Commit Sprint Backlog

Daily Scrum (Daily Standup)

Hàng ngày | Đúng 15 phút

Cuộc họp ngắn hàng ngày để team đồng bộ tiến độ. Không phải báo cáo với Scrum Master — đây là cuộc họp của Dev team cho Dev team. Đứng để duy trì ngắn gọn.

3 câu hỏi truyền thống (hoặc dùng Kanban board):

1. Hôm qua tôi đã làm gì để tiến tới Sprint Goal?

2. Hôm nay tôi sẽ làm gì để tiến tới Sprint Goal?

3. Có blockers nào cản trở tôi không?

❌ Tránh: giải quyết vấn đề trong Daily — đặt lịch offline sau

Sprint Review

Cuối Sprint | Max 4h/4 tuần sprint

Team demo sản phẩm (Increment) cho stakeholders và thu thập feedback. Không phải buổi báo cáo một chiều — đây là cuộc trò chuyện để điều chỉnh Product Backlog cho Sprint tiếp theo.

Tips: Demo trực tiếp trên sản phẩm thực, không dùng slide. Mời khách hàng/end user tham dự nếu có thể. Ghi lại feedback và update backlog ngay sau buổi.

Sprint Retrospective

Sau Sprint Review | Max 3h/4 tuần sprint

Team cùng nhìn lại cách làm việc (không phải sản phẩm): điều gì tốt, điều gì chưa tốt, và cải tiến cụ thể gì cho Sprint tiếp theo. Đây là ceremony quan trọng nhất để team liên tục cải thiện.

Format phổ biến — Start/Stop/Continue:
START: Điều chúng ta nên bắt đầu làm
STOP: Điều chúng ta nên ngừng làm
CONTINUE: Điều chúng ta nên tiếp tục làm

Backlog Refinement (Grooming)

Giữa Sprint | ~10% Sprint time

PO và team cùng review, làm rõ, và estimate các items trong Product Backlog để sẵn sàng cho Sprint tiếp theo. Không phải Scrum ceremony bắt buộc nhưng cực kỳ quan trọng.

Mục tiêu: Top 2-3 Sprint worth của items luôn có đủ Acceptance Criteria và estimate để team có thể đưa vào Sprint Planning ngay mà không mất thời gian làm rõ.

6. Triển Khai Scrum Thực Tế Trong 2 Tuần Đầu

Lý thuyết một lẽ, thực hành mới quan trọng. Đây là lộ trình triển khai Scrum trong 14 ngày đầu tiên:

1-2

Ngày 1-2: Setup nền tảng

• Chọn Scrum Master và Product Owner (có thể là Tech Lead + PM)
• Tạo Product Backlog với ít nhất 20-30 items
• Viết User Stories theo format: "As a [user], I want [feature] so that [benefit]"
• Cài đặt công cụ: Jira free, ClickUp, hoặc Trello + template Scrum
• Định nghĩa Definition of Done (DoD) cho team

Ngày 3: Sprint Planning đầu tiên (2-4 giờ)

• PO present 5-10 top items với Acceptance Criteria rõ ràng
• Team estimate bằng Planning Poker (dùng ứng dụng miễn phí)
• Chọn items vừa đủ với capacity (Velocity = Story Points/Sprint)
• Sprint 1 thường chậm — không cần lo, đây là learning sprint
• Đặt Sprint Goal cụ thể, đo lường được

4-12

Ngày 4-12: Sprint execution

• Daily Standup 9h30 sáng, đứng, đúng 15 phút
• Scrum Master ghi lại blockers và giải quyết trong ngày
• Update board sau mỗi task hoàn thành (To Do → In Progress → Done)
• Giữa sprint: Backlog Refinement 1-2 giờ để groom Sprint 2
• Track burndown chart hàng ngày

13-14

Ngày 13-14: Sprint Review và Retrospective

• Sprint Review: demo Increment cho stakeholders (30-60 phút)
• Thu thập feedback, update Product Backlog
• Retrospective: Start/Stop/Continue với toàn team (60-90 phút)
• Chọn 1-2 improvement action items cụ thể cho Sprint 2
• Celebrate! Bất kể kết quả, đây là bước đầu tiên đúng hướng

7. 7 Lỗi Scrum Phổ Biến Nhất Tại Việt Nam

1. "Scrumfall" — Scrum giả

Dùng Sprint nhưng vẫn lập kế hoạch toàn bộ dự án từ đầu, không thay đổi backlog dựa trên feedback. Bề ngoài là Agile, bên trong vẫn Waterfall.

2. Daily Standup = Status report

Khi mỗi người báo cáo cho Scrum Master/Manager thay vì đồng bộ với team. Daily thành buổi kiểm tra → team ghét, thường xuyên cancel.

3. Sprint không có Goal rõ ràng

"Sprint này làm feature A, B, C, D, E" không phải Sprint Goal. Goal phải mô tả giá trị business: "Cho phép user đăng ký và login được" — đo lường được, có ý nghĩa.

4. Scrum Master = Project Manager

SM assign task, theo dõi deadline, và đưa ra quyết định technical. Điều này phá hủy sự self-organization của team và tạo dependency vào 1 người.

5. Bỏ qua Retrospective

"Bận quá, thôi bỏ Retro Sprint này" — xảy ra liên tục. Team mất cơ hội cải thiện, tích lũy "technical debt" trong process dẫn đến team dysfunction.

6. Thay đổi Sprint Backlog giữa chừng

Manager liên tục thêm task urgent vào Sprint đang chạy. Điều này phá hủy Sprint commitment và team không bao giờ hoàn thành đúng kế hoạch.

7. Estimate không thực tế, không có buffer

Team estimate "lý tưởng" không tính đến meetings, bug fixes, và interruptions. Rule thực tế: 60-70% capacity tối đa, còn lại cho unexpected work. Sprint đầu tiên hãy lấy 50% capacity để học Scrum process.

8. Công Cụ Hỗ Trợ Agile Scrum

Phần mềm PM có Agile

Jira — tốt nhất cho dev team
ClickUp — tốt, giá rẻ hơn
Azure DevOps — Microsoft ecosystem
Linear — đơn giản, dành cho dev

Planning Poker

PlanningPoker.com — miễn phí
Scrum Poker Online — dễ dùng
Jira built-in — nếu dùng Jira
Thẻ bài thật — team offline

Retrospective Tools

Miro / Mural — virtual whiteboard
EasyRetro — chuyên biệt Retro
Metro Retro — gamified Retro
Google Jamboard — miễn phí

Template Scrum Board Google Sheets — Miễn Phí

Không cần Jira để bắt đầu. Template Scrum board Google Sheets của SheetStore bao gồm: Product Backlog, Sprint Board, Burndown Chart tự động, và Velocity tracking. Phù hợp team nhỏ muốn học Scrum mà không cần cài thêm phần mềm.

Xem template Scrum → So sánh PM tools

9. Câu Hỏi Thường Gặp (FAQ)

Sprint 1 nên chọn bao nhiêu story points?

Sprint đầu tiên không có velocity history — hãy lấy 50-60% capacity của team. Ví dụ team 5 người, Sprint 2 tuần = 50 working days → chọn items tương đương ~30 ngày công. Sprint 1 thường underperform vì phải học process — đừng lo, sau 3-4 sprints velocity sẽ ổn định.

Có phải Agile không cần tài liệu không?

Không! Agile Manifesto nói "working software over comprehensive documentation" — không phải "no documentation". Vẫn cần tài liệu, nhưng tập trung vào documentation thực sự có giá trị: User Stories, Acceptance Criteria, API docs, Architecture decisions. Bỏ bớt tài liệu không ai đọc như 200-trang spec document.