Zoho Sprints

Zoho Sprints là công cụ quản lý dự án Agile/Scrum cho team dev. Hỗ trợ backlog, sprint, user story, kanban, báo cáo tiến độ, phù hợp nhóm phần mềm nhỏ và vừa.

Lưu yêu thích

Mã giảm giá

So sánh

Đến trang Zoho Sprints

Dự án

Quét nhanh

Tạo dự án → Backlog của dự án sẽ xuất hiện để bạn thêm work item.
Admin của workspace được tự động thêm vào dự án theo mặc định (theo tài liệu Zoho Sprints).
Dùng dự án để khoanh phạm vi: board, sprint, release, báo cáo và timesheet.
Chốt sớm Scrum hay Kanban để workflow nhất quán.

1) Mục đích / Kết quả

Dự án là “container” cấp cao nhất chứa toàn bộ công việc agile của bạn. Trong Zoho Sprints, khi tạo dự án, bạn sẽ mở khóa Project Backlog để bắt đầu thêm work item và chạy sprint/board trong một phạm vi rõ ràng.

Dùng dự án để tách team, sản phẩm hoặc luồng công việc.
Đặt tên nhất quán (ví dụ: Mobile App, API Platform).
Quyết định chạy Scrum theo sprint hay Kanban theo flow cho dự án.
Định nghĩa “Done” ở cấp dự án trước khi mọi người bắt đầu kéo thả item.

2) Dành cho ai + Khi nào dùng

Tab này dành cho người thiết lập hoặc duy trì “không gian làm việc” của team. Dùng khi bạn khởi động initiative mới, tách monolith thành nhiều sản phẩm, hoặc tái tổ chức team.

Product owner: đặt phạm vi, nhịp làm việc, và sở hữu backlog.
Scrum master/PM: đảm bảo workflow nhất quán và sẵn sàng cho báo cáo.
Team lead: đồng bộ trạng thái board và kỳ vọng WIP.
Admin: kiểm tra quyền truy cập, mặc định và cài đặt đúng quy định công ty.

3) Vị trí trong điều hướng + Tab liên quan

Trong Zoho Sprints Knowledge Base, Projects là một module cấp cao cùng với Backlog, Sprints, Board, Release, Timesheet và Reports. Thiết lập dự án liên kết trực tiếp với việc tạo work item và vận hành sprint/board.

Tiếp theo: Backlog (tạo work item) → Sprints (lập kế hoạch) → Board (thực thi).
Lập kế hoạch quy mô: Release (gom sprint) + Dashboards/Reports (theo dõi).
Vận hành: Users/Workspace Settings để quản lý quyền và cấu hình mặc định.

4) Mô hình tư duy / Luồng

Theo luồng quickstart của Zoho Sprints: tạo dự án → xây product backlog → kéo vào sprint backlog → bắt đầu sprint → theo dõi trên board. Dự án là ranh giới giúp luồng này mạch lạc.

1
Tạo dự án
Kết quả: Dự án xuất hiện trong danh sách; backlog sẵn sàng.
2
Đổ work item vào backlog
Kết quả: Có item để đem đi lập kế hoạch.
3
Lập kế hoạch bằng sprints/releases
Kết quả: Kế hoạch delivery theo timebox hoặc flow liên tục.
4
Thực thi trên board + log time
Kết quả: Tiến độ rõ ràng, đo được throughput.

5) Đối tượng & Thuật ngữ

Các khái niệm cấp dự án bạn sẽ gặp lặp lại trong tài liệu.

Dự án (Project): container theo phạm vi workspace cho công việc agile.
Project Backlog: “bể ý tưởng” nơi work item bắt đầu.
Sprint / Board: các màn hình thực thi gắn với workflow của dự án.
Release: lớp lập kế hoạch có thể gom nhiều sprint (theo tài liệu release).
Workspace admin: admin được tự động thêm vào dự án theo mặc định (theo ghi chú khi tạo dự án).

6) Vòng đời (State machine)

Dự án thường đi theo vòng đời đơn giản: active → completed/archived. Nhãn cụ thể tùy governance của team; tài liệu thường tập trung nhiều hơn vào vòng đời sprint/item hơn là vòng đời dự án.

Định nghĩa khi nào dự án được xem là “active” (có work vào) vs “maintenance”.
Đặt quy tắc archive: ví dụ không còn sprint active + backlog đã triage + báo cáo đã xuất.
Nếu tổ chức yêu cầu, thêm “handoff checklist” trước khi archive.
Nếu bạn cần state machine dự án ngay trong app: Không áp dụng rõ cho tab/công cụ này (tài liệu Projects không mô tả state machine cụ thể).

7) Các “việc cần làm” cốt lõi

Người mới thường dùng Projects cho một nhóm việc lặp lại. Hãy coi đây như checklist vận hành.

Bắt đầu initiative mới: tạo dự án, set default, mời team, seed backlog.
Tách phạm vi: đưa work vào dự án riêng để tránh lẫn báo cáo.
Chuẩn hóa workflow: chốt status/WIP trước khi bắt đầu chạy.
Giữ “hygiene”: review định kỳ backlog, sprint, báo cáo, timesheet.
Đóng dự án: kết thúc/đóng sprint, tổng kết metrics, archive dự án.

8) Luồng chuẩn #1 — Tạo dự án “sẵn sàng chạy”

Theo hướng dẫn “Create and manage projects”: tạo dự án sẽ hiển thị trong trang dự án và làm Project Backlog sẵn sàng để thêm work item.

Vào khu vực Projects và bấm Create.
Nhập các thông tin bắt buộc của dự án (tên, thông tin cơ bản).
Xác nhận thành viên: workspace admin được thêm mặc định (kiểm tra có phù hợp policy nội bộ không).
Bấm Create để hoàn tất.
Mở dự án mới và xác nhận có Project Backlog.
Thêm 3–5 work item “starter” để kiểm thử setup.

Kết quả mong đợi: Dự án xuất hiện trong danh sách và Project Backlog sẵn sàng để thêm work item.

9) Luồng chuẩn #2 — Chuẩn bị dự án để báo cáo “đọc được”

Báo cáo (burndown/velocity/CFD) phụ thuộc vào việc move status và cách ước lượng nhất quán. Làm một lần cho mỗi dự án để khỏi “bẩn chart” về sau.

Thống nhất 1 kiểu workflow: Scrum theo sprint hay Kanban theo flow.
Định nghĩa ý nghĩa từng status (ví dụ: khi nào được tính là “In Progress”).
Chốt cách ước lượng (points hay count) để báo cáo đồng bộ.
Xác nhận practice trên board (ví dụ cấu hình WIP limit nếu dùng).
Chạy thử 1 “sample sprint” nhỏ với 3–5 item để test báo cáo.
Ghi lại quy ước trong một note ghim (team agreement).

Kết quả mong đợi: Team di chuyển item nhất quán và báo cáo sprint/flow dễ hiểu.

10) Điểm ra quyết định (A/B)

Dùng các quyết định này để tránh phải “đập đi làm lại” giữa chừng.

Tình huống	Nếu A…	Nếu B…
Một sản phẩm, nhiều team	Tạo 1 dự án + dùng swimlanes/filters để tách	Tạo dự án riêng nếu cần tách báo cáo/ quyền truy cập
Việc đến liên tục	Ưu tiên Kanban + kỷ luật WIP	Dùng Scrum sprint nếu cần cam kết theo timebox
Stakeholder cần ngày release	Dùng Releases để gom sprint và theo dõi tiến độ	Bỏ releases; theo dõi qua milestone ngoài Sprints
Bắt buộc time tracking	Thiết lập thói quen Timesheet từ ngày 1	Bỏ timesheet; dựa vào throughput/estimation để lập kế hoạch

11) Lỗi thường gặp (và cách tránh)

Những lỗi này hay xảy ra khi team chạy nhanh nhưng chưa chốt nền tảng.

Lỗi: Tạo quá nhiều dự án. Tránh: Bắt đầu ít thôi; chỉ tách khi báo cáo/ quyền buộc phải tách.
Lỗi: Không thống nhất ý nghĩa status. Tránh: Viết 1–2 dòng mô tả cho mỗi status và chốt với team.
Lỗi: Trộn lẫn chuẩn Scrum và Kanban. Tránh: Chọn 1 mode chính cho mỗi dự án.
Lỗi: Báo cáo khó hiểu. Tránh: Chốt points vs count trước sprint đầu tiên.
Lỗi: “Bất ngờ” về quyền. Tránh: Xác minh rule thành viên (vd. admin auto-added) ngay từ đầu.

12) Bài thực hành (10–15 phút)

Mục tiêu: tạo dự án và chứng minh chạy được end-to-end (backlog → sprint/board).

Tạo dự án mới tên Practice — Getting Started.
Mở Project Backlog và thêm 5 work item.
Tạo một sprint (hoặc kế hoạch flow đơn giản) và kéo 3 item vào đó.
Mở board và di chuyển 1 item tiến lên 1 trạng thái.
Tùy chọn: log một chút thời gian cho item đó (nếu Timesheet bật).
Ghi lại: phạm vi dự án, ý nghĩa status, và kiểu ước lượng bạn chọn.

Xác minh làm đúng: Bạn thấy dự án trong danh sách, xem được backlog, và di chuyển được ít nhất 1 status trên board mà không bị “mù quy ước”.

Link tài liệu chính thức

Người dùng

Quét nhanh

Người dùng + vai trò quyết định ai có thể tạo project/sprint, sửa item và xem báo cáo.
Thành viên dự án ảnh hưởng cộng tác hằng ngày (gán việc, board, thông báo).
Chuẩn hóa kỳ vọng về vai trò trước khi mời cả tổ chức.
Nếu tài liệu không nêu ma trận quyền theo gói của bạn, hãy tự ghi lại rule nội bộ.

1) Mục đích / Kết quả

Người dùng xác định ai tham gia workspace và các dự án. Mục tiêu rất đơn giản: đúng người có thể tạo/cập nhật/theo dõi công việc mà không gây sửa nhầm hoặc bị chặn luồng.

Chỉ mời những vai trò thật sự cần cho delivery trước.
Tách “người ra quyết định” và “người thực thi” bằng quy tắc quyền.
Đảm bảo có assignee hợp lệ trước khi bắt đầu lập kế hoạch sprint.
Chốt kỳ vọng về thông báo để không bỏ lỡ cập nhật.

2) Dành cho ai + Khi nào dùng

Dùng khi onboarding team mới, thêm cộng tác viên bên ngoài, hoặc siết kiểm soát cho dự án production. Quan trọng nhất là trước khi sprint đầu tiên bắt đầu.

Admin workspace: chịu trách nhiệm mời người dùng, quyền truy cập, governance.
Lead dự án: kiểm tra membership dự án và việc phân công.
Thành viên: cập nhật item, log time, tham gia họp.
Stakeholder: có thể chỉ cần quyền xem board/báo cáo.

3) Vị trí trong điều hướng + Tab liên quan

Trong Zoho Sprints Knowledge Base, Users là một module cấp cao bên cạnh Projects và Workspace Settings. Hãy coi nó là điều kiện tiên quyết để gán backlog sạch và báo cáo chính xác.

Liên quan: Projects (membership), Board (ai được kéo item), Timesheet (ai được log/duyệt), Reports (ai được xem).
Governance: Workspace Settings / Security & Compliance (policy).

4) Mô hình tư duy / Luồng

Hãy nghĩ theo các lớp: user ở workspace → thành viên dự án → gán việc và hoạt động. Nếu ai đó không thấy/không sửa được thứ gì, hãy kiểm tra theo thứ tự các lớp này.

1
Thêm user vào workspace
Kết quả: user tồn tại trong hệ thống.
2
Cấp vai trò / phạm vi quyền
Kết quả: user có các hành động được phép.
3
Thêm vào dự án
Kết quả: user có thể tham gia dự án đó.
4
Gán item + thông báo
Kết quả: công việc chạy trơn, không bị chặn.

5) Đối tượng & Thuật ngữ

Các thuật ngữ hay dùng khi nói về quyền và onboarding.

Workspace user: người được mời vào workspace.
Project member: workspace user được thêm vào một dự án cụ thể.
Role / permission: các hành động user được phép làm.
Assignee: người chịu trách nhiệm cho một work item.
Notifications / feeds: cách mọi người nhận biết thay đổi (xem module Feed và Notification).

6) Quyền & Vai trò

Danh mục Knowledge Base có module Users, nhưng không luôn có một ma trận quyền “chuẩn duy nhất” đặt cùng chỗ như các hướng dẫn board/report. Hãy theo hướng dẫn chính thức khi có; nếu không, tự định nghĩa ma trận tối thiểu nội bộ rồi cải tiến dần.

Ma trận quyền chính thức: Không áp dụng rõ cho tab/công cụ này (không thấy một bảng quyền tổng hợp duy nhất ngay trong danh mục KB chính).
Bắt đầu với 3 tầng: Admin (setup), Lead (planning), Member (execution).
Ghi rõ ai được: tạo/sửa sprint, đổi status trên board, xem/xuất report, duyệt time log.
Chạy thử theo “least privilege” trước khi rollout toàn org.

7) Các “việc cần làm” cốt lõi

Quản lý user nên “nhàm chán” và lặp lại được. Đây là các việc bạn làm thường xuyên nhất.

Onboard: thêm user → thêm vào dự án → gán vài việc khởi động.
Offboard: gỡ quyền → chuyển người gán item → kiểm tra không còn pending approvals.
Điều chỉnh phạm vi: chuyển user giữa các dự án mà không làm hỏng báo cáo.
Audit: kiểm tra ai có quyền sửa board/report trước giai đoạn release căng.

8) Luồng chuẩn #1 — Onboard thành viên mới

Dùng khi có người join giữa sprint và cần bắt đầu đóng góp ngay hôm nay.

Thêm user vào workspace (admin thao tác).
Thêm user vào đúng dự án.
Gán 1 work item nhỏ (rủi ro thấp) để kiểm thử quyền.
Bảo họ mở board và move item tiến 1 bước (nếu được phép).
Đảm bảo họ có thể comment/attach file trong chi tiết item (theo khái niệm các tab trong item detail).
Xác nhận họ thấy thông báo (feeds/notifications).

Kết quả mong đợi: User thấy được dự án, làm được item được gán, và nhận cập nhật.

9) Luồng chuẩn #2 — Offboard an toàn (không “mồ côi” công việc)

Tránh “ghost owner” làm hỏng delivery và sai số timesheet/báo cáo.

Liệt kê các work item đang gán cho user và chuyển người gán.
Kiểm tra user có pending approvals không (vd. timesheet nếu dùng).
Xuất/ghi lại các phần sở hữu quan trọng (epics/releases nếu có).
Gỡ user khỏi dự án trước.
Gỡ hoặc vô hiệu hóa quyền workspace (admin thao tác).
Lọc nhanh trên board để xác nhận không còn item nào gán cho user đó.

Kết quả mong đợi: Không còn item/approval/trách nhiệm nào gắn với user đã offboard.

10) Điểm ra quyết định (A/B)

Các lựa chọn này ảnh hưởng tốc độ delivery và rủi ro sửa nhầm.

Tình huống	Nếu A…	Nếu B…
Stakeholder muốn theo dõi	Cấp quyền chỉ xem + trỏ họ tới Reports	Gửi export định kỳ nếu quyền bị hạn chế
Contractor tham gia 2 tuần	Giới hạn trong 1 dự án + quyền edit hạn chế	Tạo dự án riêng nếu cần tách dữ liệu
Team dùng timesheets	Đảm bảo có quyền log time + chốt người duyệt	Bỏ time logging và tập trung throughput metrics
Nhiều team chung 1 dự án	Dùng swimlanes/filters + rule ownership rõ ràng	Tách thành nhiều dự án nếu xung đột lặp lại

Lỗi thường gặp (và cách tránh)

Lỗi: Ai cũng là admin. Tránh: dùng role tối thiểu cần thiết.
Lỗi: Quên thêm user vào dự án. Tránh: kiểm tra project membership khi gán việc fail.
Lỗi: Item “mồ côi” sau offboard. Tránh: chuyển người gán trước khi gỡ.
Lỗi: Thông báo quá nhiều. Tránh: chốt event nào quan trọng (đổi status, mention, assignment).
Lỗi: Rule ownership “ngầm”. Tránh: viết ma trận role→hành động đơn giản.

Bài thực hành (10 phút)

Mục tiêu: onboard một user test và xác nhận bộ quyền tối thiểu “có thể giao hàng”.

Thêm một user test (hoặc dùng đồng đội) vào workspace.
Thêm họ vào 1 dự án.
Tạo 1 work item và gán cho họ.
Nhờ họ: mở item detail, comment, move status trên board (nếu được phép).
Kiểm tra họ thấy được ngữ cảnh sprint/release (nếu dự án có dùng).
Ghi lại cấu hình role tối thiểu giúp flow này chạy thành công.

Xác minh làm đúng: User hoàn thành được một “micro-loop” (xem item → cập nhật → move status) mà không gặp lỗi quyền.

Link tài liệu chính thức

Backlog

Quét nhanh

Backlog là nơi ghi nhận, refine và ưu tiên work item trước khi triển khai.
Trang chi tiết item được tổ chức theo các tab (mô tả, bình luận, tệp đính kèm, họp, subitems, v.v.).
Giữ backlog “sạch” giúp lập kế hoạch sprint và báo cáo dễ hơn.
Họp refinement (đặc biệt trong Kanban) dùng để ưu tiên lại/xóa/nhóm công việc.

1) Mục đích / Kết quả

Backlog là “nguồn sự thật duy nhất” cho các việc có thể làm. Kết quả mong muốn là một tập work item đã được ưu tiên và mô tả đủ rõ để kéo vào sprint backlog hoặc chạy theo luồng trên board.

Ghi nhận yêu cầu mới thành work item ngay (không mất ngữ cảnh).
Refine item để “sẵn sàng cho sprint” (rõ ràng, nhỏ, test được).
Giữ priority có ý nghĩa (top = việc tiếp theo cần làm).
Dùng các tab chi tiết item để lưu bằng chứng và quyết định.

2) Dành cho ai + Khi nào dùng

Nếu bạn là PO hoặc team lead thì dùng tab này hằng ngày; nếu là IC thì dùng vài lần/tuần. Công việc backlog diễn ra trước và trong sprint (khi có thông tin mới).

Product owner: ưu tiên và làm rõ.
Team: bổ sung acceptance notes, tín hiệu effort và rủi ro.
QA/Design: thêm ghi chú test hoặc mockup dưới dạng attachment.
PM/Scrum master: điều phối refinement và giữ item nhỏ.

3) Vị trí trong điều hướng + Tab liên quan

Backlog là module cấp cao trong Zoho Sprints Knowledge Base và được nhắc trực tiếp trong luồng Quickstart (project → product backlog → sprint backlog → board).

Upstream: Projects (phạm vi), Users (để gán việc được).
Downstream: Sprints (lập kế hoạch), Board (thực thi), Reports (theo dõi).
Khi scale: Epics/Releases (nhóm), Meetings (nghi thức refinement).

4) Mô hình tư duy / Luồng

Backlog là một “phễu”: ghi nhận → làm rõ → ước lượng/thu nhỏ → ưu tiên → kéo vào thực thi. Bỏ qua bước nào thì execution dễ rối và report dễ sai lệch.

1
Ghi nhận
Kết quả: yêu cầu thành work item có thể theo dõi.
2
Refine
Kết quả: mô tả rõ + gợi ý acceptance + attachment.
3
Ưu tiên
Kết quả: nhóm top phản ánh kế hoạch gần hạn.
4
Kéo vào thực thi
Kết quả: item sang sprint backlog hoặc board active.

5) Đối tượng & Thuật ngữ

Thuật ngữ backlog xuất hiện xuyên suốt các module Zoho Sprints.

Work item: đơn vị công việc bạn theo dõi.
Product backlog: danh sách tổng các work item của dự án.
Sprint backlog: tập đã chọn cho một sprint (theo quickstart).
Item details: trang dạng tab cho mô tả, bình luận, đính kèm, subitems, meetings, v.v.
Backlog refinement: nghi thức họp để ưu tiên lại/xóa/nhóm/thêm item (mô tả trong Kanban guide).

6) Vòng đời (State machine)

Item backlog thường đi từ mơ hồ → sẵn sàng → đang làm → xong. Zoho Sprints tập trung vào status trên board khi thực thi; còn “độ sẵn sàng” của backlog chủ yếu là kỷ luật của team.

Tạo nhãn readiness đơn giản: Nháp → Đã refine → Sẵn sàng sprint.
Chỉ kéo Sẵn sàng sprint vào sprint backlog.
Dùng các tab item details để chứng minh readiness (acceptance notes, attachments, thảo luận).
Nếu bạn cần workflow readiness “built-in” chính thức: Không áp dụng rõ cho tab/công cụ này (không thấy state machine backlog được mô tả rõ trong các KB entry được tham chiếu).

7) Các “việc cần làm” cốt lõi

Các việc sau giữ backlog luôn dùng được cho planning và delivery.

Viết item tốt: tiêu đề + bối cảnh + hành vi mong đợi + link.
Tách phạm vi: chia item lớn thành các item nhỏ, độc lập.
Đính kèm bằng chứng: spec, ảnh chụp, meeting notes, quyết định.
Ưu tiên lại: sắp xếp theo value và risk.
Chuẩn bị đầu vào sprint: chọn tập item ready để planning.

8) Luồng chuẩn #1 — Biến một yêu cầu thành item “sẵn sàng sprint”

Dùng các tab chi tiết item để lưu thứ quan trọng, tránh việc team phải “khám phá lại” yêu cầu giữa sprint.

Tạo work item mới trong project backlog.
Thêm bối cảnh: ai cần, vì sao quan trọng, tiêu chí thành công.
Trong item details, thêm comment làm rõ edge cases.
Đính kèm tài liệu hỗ trợ (mockups/logs) ở mục attachments.
Thêm subitems nếu cần chia việc để làm song song.
Đánh dấu “ready” (theo rule/nhãn readiness của team) và đặt vào nhóm ưu tiên cao nhất.

Kết quả mong đợi: Item có thể được pick up mà không cần họp, và không gây bất ngờ khi đang làm.

9) Luồng chuẩn #2 — Chạy một vòng refinement backlog (30–45 phút)

Kanban guide mô tả họp backlog refinement như cách để ưu tiên lại, loại bỏ item lỗi thời, nhóm các việc trùng lặp và thêm work item mới.

Chọn top 15–25 item làm “batch” refinement.
Xóa/đưa vào archive các item lỗi thời (ghi lý do trong comment).
Nhóm các item trùng và giữ lại một item chuẩn (canonical).
Chia nhỏ item quá lớn cho đến khi mỗi item đủ nhỏ cho một “sprint slice”.
Ưu tiên lại theo ràng buộc hiện tại và dependencies.
Kết thúc bằng việc chốt tập “sprint-ready” cho planning.

Kết quả mong đợi: Top backlog rõ ràng, nhỏ, và có thể hành động ngay.

10) Điểm ra quyết định (A/B)

Dùng các lựa chọn này để giữ chất lượng backlog cao.

Tình huống	Nếu A…	Nếu B…
Item quá lớn	Chia thành item nhỏ hơn + subitems	Giữ ở mức epic để tracking; đừng kéo vào sprint
Yêu cầu chưa rõ	Thêm câu hỏi + ghi chú lịch họp ngắn trong item details	Hạ ưu tiên cho đến khi làm rõ
Ưu tiên mâu thuẫn	Sắp xếp lại backlog và ghi lại quyết định	Tách dự án nếu các ưu tiên không liên quan nhau
Nhiều item trùng	Gộp và link các item trùng về item chuẩn	Chỉ giữ tách riêng nếu outcome khác nhau

Lỗi thường gặp (và cách tránh)

Lỗi: Viết item kiểu “todo” không có bối cảnh. Tránh: thêm 2–3 câu nói rõ mục đích và kết quả.
Lỗi: Không có attachments/bằng chứng. Tránh: đính kèm ảnh/log sớm.
Lỗi: Kéo item chưa sẵn sàng vào sprint. Tránh: bắt buộc cổng “sprint-ready”.
Lỗi: Trùng lặp khắp nơi. Tránh: gộp mỗi tuần.
Lỗi: Không bao giờ refinement. Tránh: đặt lịch refinement định kỳ.

Bài thực hành (10–15 phút)

Mục tiêu: tạo mini-backlog và làm 3 item “sẵn sàng sprint” thật sự bằng các tab item details.

Tạo 6 backlog items mới (trộn feature/bug).
Chọn 3 item và refine: thêm mô tả, comment, và 1 attachment cho mỗi item.
Chia 1 item lớn thành 2–3 item nhỏ hơn (hoặc thêm subitems).
Chạy refinement 10 phút: sắp xếp lại top 6 theo value.
Chọn 3 item “sprint-ready” và ghi lý do.

Xác minh làm đúng: Người khác có thể đọc top 3 item và giải thích cần build gì mà không phải hỏi bạn.

Link tài liệu chính thức

Sprints

Quét nhanh

Bạn có thể tạo sprint từ Backlog; cũng có thể qua tuỳ chọn thêm nhanh (theo hướng dẫn create/manage sprints).
Có 2 chế độ tạo: tạo mới từ đầu hoặc dùng template (theo create/manage sprints).
Có thể gắn Release ngay khi tạo sprint (theo bài associate release).
Sau khi bắt đầu sprint, các item sẽ xuất hiện trên Scrum board để theo dõi (theo quickstart).

1) Mục đích / Kết quả

Sprint là đơn vị lập kế hoạch theo “timebox” để chốt một tập work item nhằm triển khai tập trung. Kết quả là có sprint backlog đã commit, board đang chạy, và đo được hiệu suất sprint qua báo cáo.

Tạo sprint để giảm chuyển ngữ cảnh.
Dùng sprint backlog để “khoá” cái cần làm trong timebox.
Theo dõi tiến độ trên board trong suốt sprint.
Đóng sprint để có báo cáo sạch (velocity/burndown/CFD).

2) Dành cho ai + Khi nào dùng

Dùng tab này khi lên kế hoạch việc sắp tới, bắt đầu sprint, hoặc cải thiện độ dự đoán của sprint. Hoạt động nhiều nhất ở giai đoạn planning và tại “ranh giới” sprint.

Scrum master/PM: tạo sprint, chạy planning, đảm bảo ngày tháng đúng.
Product owner: đặt goal và ưu tiên.
Team: commit, thực thi, cập nhật trạng thái.
Stakeholders: xem kết quả qua board và reports.

3) Vị trí trong điều hướng + Tab liên quan

Sprints là module cấp cao trong Zoho Sprints KB và gắn chặt với Backlog (nguồn item), Board (thực thi), Release (nhóm), và Reports (đo lường).

Tạo từ: Backlog (theo các bước tạo sprint bắt đầu ở “Go to Backlog”).
Thực thi trên: Board sau khi sprint bắt đầu (theo quickstart).
Đo lường ở: Dashboards và Reports (burndown/velocity/CFD, v.v.).

4) Mô hình tư duy / Luồng

Một sprint có 3 pha: tạo sprint backlog → chạy trên board → đóng sprint và rút kinh nghiệm. Tách bạch các pha để bảo vệ tính dự đoán.

1
Tạo sprint
Kết quả: có “container” sprint.
2
Chọn sprint backlog
Kết quả: item đã chọn sẵn sàng để làm.
3
Bắt đầu sprint
Kết quả: item xuất hiện trên board để theo dõi.
4
Đóng sprint
Kết quả: reports phản ánh cam kết vs hoàn thành.

5) Đối tượng & Thuật ngữ

Các khái niệm sprint này được nhắc lặp lại trong help chính thức.

Sprint backlog: tập work item đã chọn cho sprint (quickstart).
Template: tái sử dụng cấu trúc sprint có sẵn (create/manage sprints có nhắc).
Gắn Release: chọn release khi tạo sprint (bài associate release).
Điểm ước lượng: dùng cho burndown/velocity (docs reports).

6) Vòng đời (State machine)

Sprint thường đi theo vòng đời: planned → active → completed/closed. Board và reports chỉ “có nghĩa” khi team tôn trọng ranh giới này.

Planned: sprint tồn tại, backlog đã chọn, nhưng chưa bắt đầu.
Active: sprint đã start; item được theo dõi trên board.
Completed: sprint đã close; báo cáo tóm tắt kết quả.
Tên nhãn UI có thể khác: hãy theo UI workspace của bạn; docs nhấn mạnh hành vi (start đưa item lên board; close giúp báo cáo chuẩn).

7) Các “việc cần làm” cốt lõi

Các việc lặp lại này giúp delivery theo sprint ổn định.

Tạo sprint: tạo mới từ đầu hoặc dùng template.
Chọn item: kéo từ product backlog sang sprint backlog (quickstart).
Gắn release: liên kết sprint với release khi planning (tuỳ chọn).
Chạy sprint: cập nhật status trên board mỗi ngày.
Xem metrics: dùng burndown/velocity/CFD sau sprint (module reports).

8) Luồng chuẩn #1 — Tạo sprint (từ đầu)

Bám theo luồng “Create and manage sprints”: mở project → vào Backlog → tạo sprint.

Mở project cần làm.
Đi tới Backlog.
Nhấn Create để mở form tạo sprint.
Nhập thông tin sprint (tên, ngày, goal nếu có).
Tuỳ chọn: chọn from scratch hoặc template (nếu UI có).
Nhấn Create để lưu.

Kết quả mong đợi: Có sprint mới và sẵn sàng để chọn item vào sprint backlog.

9) Luồng chuẩn #2 — Tạo sprint và gắn với release

Theo hướng dẫn “Associate release while creating new sprint”: bạn có thể chọn release ngay trong form tạo sprint.

Mở project cần làm.
Vào Backlog và nhấn Create.
Nhập thông tin sprint.
Chọn Release cần gắn với sprint.
Nhấn Create.
Kiểm tra sprint đã xuất hiện trong các màn tracking của release đó.

Kết quả mong đợi: Sprint được tạo và liên kết với release để theo dõi xuyên sprint.

10) Điểm ra quyết định (A/B)

Các lựa chọn này ảnh hưởng trực tiếp tới dự đoán và reporting.

Tình huống	Nếu A…	Nếu B…
Cấu trúc sprint lặp lại	Dùng sprint template để tái sử dụng cấu trúc	Tạo từ đầu nếu scope thay đổi mạnh
Stakeholders theo dõi release	Gắn sprint với release	Bỏ qua nếu chỉ nội bộ
Team thay đổi giữa sprint	Điều chỉnh cam kết cẩn thận + ghi chú lại	Giữ scope ổn định; đẩy thay đổi về backlog
Báo cáo dùng points	Đảm bảo points được dùng nhất quán	Dùng báo cáo theo count nếu team không dùng points

Lỗi thường gặp (và cách tránh)

Lỗi: Start sprint khi sprint backlog chưa chốt. Tránh: chốt selection trước ngày bắt đầu.
Lỗi: Scope thay đổi hằng ngày. Tránh: đẩy thay đổi về product backlog.
Lỗi: Dùng status sai. Tránh: thống nhất ý nghĩa từng status trên board.
Lỗi: Ước lượng không nhất quán. Tránh: chọn points hoặc count và giữ cố định.
Lỗi: Không đóng sprint. Tránh: close đúng hạn để reports chính xác.

Bài thực hành (10–15 phút)

Mục tiêu: tạo sprint, (tuỳ chọn) gắn release, và chứng minh sau này có dữ liệu để báo cáo “có nghĩa”.

Tạo sprint trong project luyện tập từ Backlog.
Thêm 5 work item vào sprint backlog.
(Tuỳ chọn) Gắn sprint với release ngay khi tạo.
Start sprint và kéo 2 item đi qua ít nhất 1 status trên board.
Hoàn thành (Done) ít nhất 1 item để có dữ liệu thực.
Mở một report sprint (vd: burndown/CFD) sau khi có movement.

Xác minh làm đúng: Sprint tồn tại, item theo dõi được trên board, và reports phản ánh ít nhất một lần đổi status hoặc hoàn thành.

Link tài liệu chính thức

Board

Quét nhanh

Board là nơi xem/cập nhật/theo dõi các work item đang chạy trong sprint (theo quickstart).
Có thể đặt giới hạn WIP cho từng status; cấu hình trong Project Settings (theo manage items on board).
Swimlane giúp sắp xếp/nhóm lại item; Kanban guide mô tả các loại swimlane và cách dùng.
Kỷ luật board ảnh hưởng trực tiếp tới report như CFD (theo dõi dựa trên status).

1) Mục đích / Kết quả

Board là màn “thực thi” theo thời gian thực. Kết quả đơn giản: ai cũng thấy cái gì đang làm, cái gì bị kẹt, và cái gì đã xong—không cần họp.

Dùng status để phản ánh bước workflow thật (không mơ hồ).
Kéo/thả card hằng ngày để phản ánh đúng thực tế.
Dùng WIP limit để tránh quá tải một lane.
Dùng swimlane để nhóm việc theo người/tiêu chí khi cần.

2) Dành cho ai + Khi nào dùng

Dùng board nhiều lần mỗi ngày trong sprint đang chạy hoặc flow liên tục. Đây là nơi trung tâm cho daily/kiểm tra trạng thái/cân lại tải nhanh.

Thành viên team: di chuyển item, cập nhật chi tiết, thêm comment/đính kèm.
Lead: theo dõi WIP và gỡ blocker.
Scrum master: điều phối daily review và cải thiện flow.
Stakeholders: xem tiến độ mà không làm gián đoạn team.

3) Vị trí trong điều hướng + Tab liên quan

Board là module cấp cao trong KB và là bước thực thi sau khi start sprint (quickstart). Đây cũng là “nguồn sự thật” cho các report dựa status như CFD.

Nhận dữ liệu từ: Sprints (sprint backlog đang active) và Backlog (item được kéo vào).
Tác động tới: Reports (CFD dùng status của item).
Bị chi phối bởi: Project Settings (WIP limits được cấu hình ở đây).

4) Mô hình tư duy / Luồng

Board là trực quan hoá workflow: cột = status; card = work item; di chuyển = tiến độ. Nếu di chuyển không đúng, “sự thật” của team sẽ méo.

1
Bắt đầu sprint / kích hoạt flow
Kết quả: item xuất hiện trên board.
2
Kéo việc
Kết quả: assignee bắt đầu item có chủ đích.
3
Di chuyển status
Kết quả: board phản ánh đúng tiến độ.
4
Áp dụng WIP
Kết quả: bottleneck lộ rõ.

5) Đối tượng & Thuật ngữ

Thuật ngữ board nên thống nhất trước sprint đầu tiên.

Status/Cột: bước workflow (To Do / In Progress / Done, v.v.).
WIP limit: giới hạn min/max theo status (manage items on board).
Swimlane: chế độ nhóm item; Kanban docs mô tả các tuỳ chọn swimlane.
CFD: biểu đồ cumulative flow theo dõi tiến triển status theo thời gian.

6) Vòng đời (State machine)

Trên board, work item chuyển qua các status. Report như CFD giả định status có nghĩa và được dùng nhất quán.

Định nghĩa các chuyển trạng thái hợp lệ (vd: không nhảy To Do → Done nếu không có bằng chứng).
Dùng comment/attachment trong item details khi cần “giải trình” cho một lần chuyển.
Nếu dùng WIP limits, hãy coi nó là công cụ điều tiết flow—không phải “thành tích”.
Luật chuyển status chính thức theo project: Không áp dụng cho tab này (không có ma trận chuyển status “chuẩn chung” trong các trang board help được tham chiếu).

7) Các “việc cần làm” cốt lõi

Những thao tác board quan trọng nhất cho delivery và visibility.

Cập nhật status: di chuyển card khi công việc thay đổi.
Hạn chế quá tải: đặt WIP limits và phản ứng khi vượt ngưỡng.
Nhóm góc nhìn: dùng swimlane để tập trung (theo user, v.v.).
Phát hiện blocker: tìm card “kẹt” và escalate sớm.
Giữ ngữ cảnh: ghi quyết định trong item details để không mất context.

8) Luồng chuẩn #1 — Cấu hình và dùng WIP limits

Trang help về board nêu rằng bạn có thể đặt WIP limit theo từng status và cấu hình này nằm trong Project Settings.

Mở project và vào Project Settings.
Tìm phần cấu hình board/status (nơi định nghĩa WIP).
Với status In Progress, đặt min/max hợp lý.
Lưu lại và quay về board.
Trong daily check, nếu lane vượt max thì dừng kéo thêm việc.
“Swarm” để đẩy item đi tiếp cho tới khi WIP về ngưỡng an toàn.

Kết quả mong đợi: Team tránh nhồi quá nhiều việc vào một lane và thấy bottleneck sớm.

9) Luồng chuẩn #2 — Dùng swimlanes để tập trung daily review

Kanban guide mô tả swimlanes như một cách lọc/nhóm lại board. Tips cộng đồng cũng hay chọn swimlane trực tiếp trên UI board.

Mở board của sprint/flow đang active.
Bật Swimlane từ cụm điều khiển board (thường ở trên/phải).
Chọn loại swimlane phù hợp hôm nay (vd: theo user).
Quét các item bị kẹt theo từng lane (không move, không comment).
Chọn 1–2 blocker và giao “next action” trong comment.
Tắt swimlane để quay lại view mặc định khi xong.

Kết quả mong đợi: Daily review nhanh và actionable hơn vì board được nhóm theo logic.

10) Điểm ra quyết định (A/B)

Các lựa chọn này giúp board giữ “tín hiệu” sạch.

Tình huống	Nếu A…	Nếu B…
Lane vượt WIP max	Dừng kéo; swarm để gỡ kẹt	Tăng WIP chỉ khi capacity thực sự tăng
Khó quét/đọc board	Dùng swimlane + filter để nhóm	Tách thành project/board khác nếu bản chất khác nhau
Ý nghĩa status bị lệch	Định nghĩa lại status và truyền thông quy tắc	Thêm quy ước “Blocked” nếu đó mới là vấn đề
Report nhìn sai	Audit kỷ luật di chuyển status	Chuyển report sang count-based nếu points không nhất quán

Lỗi thường gặp (và cách tránh)

Lỗi: Di chuyển card quá trễ. Tránh: move ngay khi công việc đổi trạng thái, không đợi cuối ngày.
Lỗi: Bỏ qua WIP limits. Tránh: coi việc vượt WIP là “sự kiện của cả team”.
Lỗi: Quá nhiều status. Tránh: giữ workflow đơn giản nhưng có ý nghĩa.
Lỗi: Blocker không có ghi chú. Tránh: comment rõ next action và owner.
Lỗi: Dùng swimlane tuỳ hứng. Tránh: chuẩn hoá lúc nào dùng (daily review, triage).

Bài thực hành (10–15 phút)

Mục tiêu: làm board “có ích thấy rõ” cho team nhỏ, với 1 luật WIP và 1 thói quen swimlane.

Chọn một sprint đang active (hoặc tạo sprint nhỏ) có 5 item.
Đặt WIP max cho In Progress = 2.
Di chuyển 3 item vào In Progress và quan sát vi phạm giới hạn.
Đẩy 1 item đi tiếp (về phía Done) để giảm xuống dưới ngưỡng.
Bật swimlane theo user và làm review 5 phút.
Viết 1 câu “team agreement”: khi vượt WIP thì làm gì?

Xác minh làm đúng: Board làm lộ quá tải rõ ràng và team biết cách sửa bằng WIP + review tập trung.

Link tài liệu chính thức

Release

Quét nhanh

Release giúp lập kế hoạch và quản lý các đợt phát hành (mô tả module trong KB).
Bạn có thể gắn sprint vào release ngay khi tạo sprint.
Release Board cho view dạng cột theo sprint, các work item được căn thẳng hàng bên dưới (theo bài viết release board).
Dùng release khi stakeholder quan tâm “ship phiên bản” qua nhiều sprint.

1) Mục đích / Kết quả

Release gom nhiều sprint lại để theo dõi tiến độ hướng tới một phiên bản hoặc milestone. Kết quả là có “tầm nhìn cấp release” bổ sung cho việc thực thi cấp sprint.

Dùng release để truyền thông “những gì sẽ ship cùng nhau”.
Theo dõi tiến độ xuyên nhiều sprint trong một view.
Giảm rối cho stakeholder khi việc kéo dài qua nhiều sprint.
Căn báo cáo và cách quét board theo phạm vi release.

2) Dành cho ai + Khi nào dùng

Dùng release khi bạn có milestone roadmap, bản cập nhật phiên bản, hoặc “bundle” tính năng có deadline bên ngoài. Đặc biệt hữu ích khi giao hàng qua nhiều sprint.

Product/PM: định nghĩa scope và mốc thời gian release.
Team lead: map các sprint với outcome của release.
Stakeholder: xem tiến độ release mà không phải đào từng sprint.
QA/Release manager: phối hợp readiness và checklist cutover.

3) Vị trí trong điều hướng + Tab liên quan

Release là module top-level trong KB. Nó gắn chặt nhất với Sprints (gắn release lúc tạo sprint) và Board (thực thi). Reports và timesheets là tín hiệu hỗ trợ.

Liên kết từ: Sprints (associate release khi tạo sprint).
Xem trong: Release Board (tiến độ xuyên các sprint).
Đo lường bởi: Reports (hiệu năng sprint vẫn quan trọng bên trong release).

4) Mô hình tư duy / Luồng

Release là “lát cắt portfolio”: định nghĩa scope → gắn sprints → theo dõi tiến độ → chốt. Đừng coi release là bản sao của sprint; nó là lớp bọc cho nhiều sprint.

1
Định nghĩa release
Kết quả: có một “container” release.
2
Gắn các sprint
Kết quả: sprint được map vào release.
3
Theo dõi qua release board
Kết quả: nhìn tiến độ xuyên các sprint.
4
Chốt release
Kết quả: có tóm tắt và bài học.

5) Đối tượng & Thuật ngữ

Các khái niệm release hay gặp trong trang tài liệu chính thức.

Release: gói công việc được lên kế hoạch theo thời gian.
Release board: view dạng cột của tất cả sprint, work item được căn dưới tương ứng (theo release board).
Gắn sprint với release: chọn release ngay trong form tạo sprint (theo associate release).
Filters: release board hỗ trợ lọc để xem item (bài release board có nhắc filters).

6) Vòng đời (State machine)

Release thường đi từ planned → in progress → shipped/closed. Docs nhấn mạnh theo dõi tiến độ qua release board hơn là áp một state machine cứng.

Gọi là “planned” khi đã có scope nhưng chưa bắt đầu thực thi.
Gọi là “in progress” khi ít nhất một sprint liên kết đang active.
Gọi là “shipped” khi đạt tiêu chí release và hoàn tất các bước kiểm tra.
Nếu bạn cần state release “built-in” trong Zoho Sprints: Không áp dụng cho tab này (không thấy state machine release rõ ràng trong các trang release help được tham chiếu).

7) Các “việc cần làm” cốt lõi

Giữ release đơn giản: định nghĩa, gắn, theo dõi, truyền thông.

Tạo release: định nghĩa version/milestone và scope.
Gắn sprint: link sprint mới ngay lúc tạo.
Theo dõi tiến độ: dùng release board để xem item xuyên nhiều sprint.
Truyền thông trạng thái: tóm tắt cái gì rủi ro và cái gì đã ship.
Retrospect: rút kinh nghiệm ở cấp release, không chỉ từng sprint.

8) Luồng chuẩn #1 — Gắn sprint vào release khi lập kế hoạch

Các bước chính thức cho thấy bạn chọn release ngay khi tạo sprint từ Backlog.

Mở project và vào Backlog.
Nhấn Create để mở form tạo sprint.
Nhập thông tin sprint.
Chọn Release mục tiêu trong form.
Nhấn Create.
Xác nhận sprint xuất hiện trong ngữ cảnh theo dõi của release.

Kết quả mong đợi: Kế hoạch sprint tự động gắn vào milestone release.

9) Luồng chuẩn #2 — Dùng release board để phát hiện rủi ro

Release board được thiết kế để theo dõi tiến độ work item xuyên tất cả sprint trong một release và có hỗ trợ filters.

Mở release và vào Release Board.
Quét các cột để thấy từng sprint và work item được căn dưới.
Áp filter để tập trung vào item ưu tiên cao hoặc đang rủi ro.
Nhận diện sprint có nhiều “in-progress” hoặc nhiều blocker.
Click vào item details để kiểm tra next action đã được ghi chưa.
Viết nhanh 1 status note cho release: cái gì on track vs at risk.

Kết quả mong đợi: Bạn giải thích “sức khoẻ release” trong 2 phút bằng một view.

10) Điểm ra quyết định (A/B)

Các lựa chọn này giúp release planning hữu ích (không thành thủ tục).

Tình huống	Nếu A…	Nếu B…
Công việc kéo dài 3+ sprint	Tạo release và gắn các sprint	Bỏ release nếu chỉ nội bộ và rất ngắn
Stakeholder cần một view duy nhất	Dùng release board làm “artifact” status mặc định	Chỉ dùng sprint board nếu scope cực nhỏ
Scope thay đổi liên tục	Chốt scope tối thiểu + đẩy phần thêm sang release sau	Hoãn tạo release tới khi ưu tiên ổn định
Nhiều sản phẩm chung một ngày ship	Tạo release riêng theo từng sản phẩm	Chỉ tạo 1 release nếu yêu cầu báo cáo cho phép trộn

Lỗi thường gặp (và cách tránh)

Lỗi: Xem release như sprint #0. Tránh: chỉ dùng để có visibility xuyên nhiều sprint.
Lỗi: Không gắn sprint vào release. Tránh: link ngay lúc tạo sprint.
Lỗi: Không định nghĩa scope. Tránh: ghi rõ in/out.
Lỗi: Không tận dụng filter release board. Tránh: lọc theo rủi ro và ưu tiên mỗi tuần.
Lỗi: Không closeout. Tránh: chốt cái gì ship + cái gì trượt.

Bài thực hành (10–15 phút)

Mục tiêu: tạo một release nhỏ, gắn 2 sprint, và kiểm tra release board kể được “câu chuyện” mạch lạc.

Tạo release tên Practice v0.1.
Tạo Sprint A và gắn vào release ngay trong lúc tạo.
Tạo Sprint B và gắn tương tự.
Thêm 3 item vào Sprint A và 3 item vào Sprint B.
Mở release board và xác nhận thấy cả hai sprint và item được căn thẳng hàng.
Áp một filter (priority/assignee nếu có) để demo cách quét rủi ro tập trung.

Xác minh làm đúng: Một view cho thấy tiến độ xuyên nhiều sprint và bạn phát hiện rủi ro nhanh.

Link tài liệu chính thức

Timesheet

Quét nhanh

Module Timesheet giúp theo dõi giờ billable/non-billable và phê duyệt time log (trang Zoho Sprints).
Báo cáo timesheet tóm tắt giờ đã log và đưa ra insight (các trang About timesheet + Timesheet report).
Nên quyết định sớm: bạn theo dõi thời gian để tính tiền, dự báo, hay chỉ để học cải thiện?
Dữ liệu thời gian chỉ có giá trị nếu log đều và có review.

1) Mục đích / Kết quả

Timesheet cho phép team ghi lại số giờ đã bỏ ra cho công việc và phân tách billable vs non-billable. Kết quả là nhìn rõ effort, quy trình phê duyệt (nếu dùng), và có báo cáo phục vụ lập kế hoạch sau này.

Theo dõi thời gian theo từng work item để hiểu chi phí/effort.
Dùng billable vs non-billable để tách công việc khách hàng.
Review log hàng tuần để dữ liệu sạch.
Dùng report để phát hiện pattern vượt giờ và sai lệch kế hoạch.

2) Dành cho ai + Khi nào dùng

Dùng khi tổ chức yêu cầu tracking thời gian hoặc khi bạn muốn dữ liệu effort chuẩn để cải thiện planning. Hiệu quả nhất khi có routine (log hằng ngày + review hằng tuần).

Thành viên: log thời gian đều đặn.
Lead/Manager: review và approve log (nếu plan có phê duyệt).
Finance/Operations: dùng báo cáo billable.
PM: đối chiếu pattern thời gian với estimation và tốc độ giao hàng.

3) Vị trí trong điều hướng + Tab liên quan

Timesheet là module top-level trong KB và liên kết tự nhiên với Board (thực thi), Reports (timesheet reports), và Users (ai được log/approve).

Liên quan: Dashboards and Reports → Timesheet Reports.
Đầu vào: work items và hoạt động trong luồng sprint/board.
Quản trị: role/permission (nếu có cơ chế approve).

4) Mô hình tư duy / Luồng

Dữ liệu Timesheet chỉ đáng giá nếu chạy đúng vòng lặp: log → review → approve (tuỳ chọn) → report → cải thiện. Đừng log chỉ để “lưu con số”.

1
Log thời gian
Kết quả: giờ được ghi theo item/nhóm.
2
Review
Kết quả: sửa lỗi rõ ràng sớm.
3
Phê duyệt (nếu dùng)
Kết quả: dataset đáng tin để tính tiền/báo cáo.
4
Báo cáo
Kết quả: insight làm thay đổi planning/hành vi.

5) Đối tượng & Thuật ngữ

Các khái niệm Timesheet hay gặp trong tài liệu Zoho Sprints.

Billable / non-billable: phân loại giờ (trang Timesheet Zoho Sprints).
Phê duyệt time log: nhấn mạnh duyệt một chạm (trang Timesheet Zoho Sprints).
Timesheet reports: nhiều report để theo dõi giờ đã log (KB timesheet report).
Timesheet module: theo dõi thời lượng để tăng hiệu suất team (trang Timesheet Zoho Sprints).

6) Quyền & Vai trò

Một số tổ chức cần phê duyệt; số khác chỉ cần log cá nhân. Nếu workspace/plan có approvals, hãy định nghĩa ai duyệt và duyệt theo nhịp nào.

Bảng quyền chi tiết cho phê duyệt timesheet: Không áp dụng cho tab này (không thấy bảng quyền tổng hợp trong các trang KB timesheet được tham chiếu).
Chỉ định người chịu trách nhiệm review timesheet (team lead/manager).
Quy định tần suất log tối thiểu (khuyến nghị hằng ngày nếu bắt buộc).
Đặt rule cho log trễ (ví dụ: trong 48 giờ).

7) Các “việc cần làm” cốt lõi

Timesheet là chuyện “đều đặn”. Giữ các việc nhỏ và lặp lại được.

Log thời gian: ghi giờ theo work item hoặc category.
Tách billable/non-billable: giúp báo cáo tài chính sạch.
Review hằng tuần: sửa trùng, thiếu ngày, sai category.
Phê duyệt (nếu dùng): ký xác nhận để report đáng tin.
Dùng report: so giờ đã log với outcome sprint và kỳ vọng.

8) Luồng chuẩn #1 — Routine log thời gian hằng ngày

Routine nhẹ giúp tránh “quên sạch” cuối tuần.

Cuối ngày, liệt kê 2–4 work item bạn đã chạm.
Log thời gian cho từng item trong Timesheet.
Đánh dấu billable/non-billable đúng.
Ghi note ngắn nếu công việc bất thường (rework, incident).
Kiểm tra tổng giờ có hợp lý trước khi lưu.
Lặp lại mỗi ngày để dữ liệu ổn định.

Kết quả mong đợi: Timesheet phản ánh effort thật, ít phải sửa lại.

9) Luồng chuẩn #2 — Review hằng tuần + rút insight

KB có nhắc timesheet reports cung cấp insight cho planning tương lai. Review tuần biến log thành bài học.

Mở timesheet reports theo tuần.
Quét các ngày thiếu hoặc tổng giờ bất thường.
Kiểm tra lại tách billable/non-billable.
Xác định các work item/category tốn thời gian nhất.
Viết 1–2 action note (vd: giảm rework, cải thiện estimation, chỉnh WIP).
Nếu có approvals, approve/lock tuần sau khi review.

Kết quả mong đợi: Bạn giải thích được thời gian đi đâu và điều chỉnh planning/quy trình.

10) Điểm ra quyết định (A/B)

Chọn mô hình phù hợp với mục tiêu tracking thời gian.

Tình huống	Nếu A…	Nếu B…
Bắt buộc tính tiền khách hàng	Ép phân loại billable + phê duyệt	Bỏ approve chỉ khi finance chấp nhận log “tự tin cậy”
Team product nội bộ	Track để học (không để “soi”)	Bỏ timesheet; tập trung throughput metric
Mọi người hay quên log	Nghi thức 5 phút mỗi ngày + nhắc nhở	Log dồn theo tuần (độ chính xác thấp hơn)
Quá tốn công admin	Chỉ log ở item/category quan trọng	Log chi tiết theo item nếu cần costing chính xác

Lỗi thường gặp (và cách tránh)

Lỗi: Dồn log vào thứ Sáu. Tránh: log hằng ngày.
Lỗi: Không có category. Tránh: tối thiểu billable vs non-billable.
Lỗi: Không review. Tránh: audit 10 phút mỗi tuần.
Lỗi: Dùng timesheet để “phạt”. Tránh: dùng dữ liệu cho planning và cải thiện.
Lỗi: Bỏ qua report. Tránh: nối insight thời gian với quyết định backlog/sprint.

Bài thực hành (10–15 phút)

Mục tiêu: tạo dataset nhỏ và rút 1 insight từ timesheet report.

Chọn 3 work item bạn vừa làm (hoặc tạo 3 item mẫu).
Log 15–30 phút cho mỗi item (trộn billable/non-billable).
Mở view timesheet report.
Xác nhận tổng giờ khớp với dữ liệu bạn nhập.
Viết 1 insight: category nào ăn nhiều thời gian nhất và vì sao?
Chọn 1 điều chỉnh (vd: giảm WIP, refine backlog sớm hơn).

Xác minh làm đúng: Report hiển thị giờ bạn đã log và bạn nêu được 1 bài học có thể hành động.

Link tài liệu chính thức

Dashboards and Reports

Quét nhanh

Báo cáo phân tích hiệu suất sprint theo định lượng và hỗ trợ dự đoán/điều chỉnh (About report).
Sprint reports gồm: velocity, burndown, burnup, CFD, latency (About report).
Cách xem burndown: module Report → View by Sprint Report → Report type Burndown (Sprint burndown chart).
CFD theo dõi tiến độ work item theo status trên sprint board (CFD).

1) Mục đích / Kết quả

Dashboards và Reports biến hoạt động trên board thành insight. Kết quả là dự báo tốt hơn, phát hiện sớm điểm nghẽn, và cải thiện đo lường được trong estimation và flow.

Dùng report để học và cải tiến, không phải để đổ lỗi.
So sánh khối lượng cam kết vs hoàn thành (velocity).
Theo dõi xu hướng “còn lại bao nhiêu việc” theo thời gian (burndown).
Phân tích sức khoẻ luồng theo trạng thái (CFD).

2) Dành cho ai + Khi nào dùng

Dùng report trong lúc lập kế hoạch sprint, check-in giữa sprint, và retrospective. Lead dùng để nhìn trend; team dùng để tinh chỉnh quy trình.

Team: kiểm tra flow giữa sprint và học trong retro.
Scrum master/PM: cải thiện planning và tính dự đoán.
Leads: theo dõi capacity và bottleneck.
Stakeholders: tín hiệu tiến độ và rủi ro ở mức tổng quan.

3) Vị trí trong điều hướng + Tab liên quan

Reports là module top-level trong KB và phụ thuộc dữ liệu tạo ra từ Sprints, Board và Timesheet. Nếu dữ liệu thực thi không nhất quán, report sẽ dễ gây hiểu sai.

Đầu vào: dịch chuyển status trong sprint (board), sprint đã đóng, estimation points.
Liên quan: Timesheet Reports cho insight về time-tracking.
Kết hợp tốt nhất: dùng report song song với retrospective.

4) Mô hình tư duy / Luồng

Reports là vòng lặp phản hồi: thực thi nhất quán → thu dữ liệu → trực quan hoá → quyết định → đổi hành vi. Vòng lặp sẽ “gãy” nếu status/estimation không kỷ luật.

1
Thực thi
Kết quả: status và hoàn thành phản ánh đúng thực tế.
2
Đo lường
Kết quả: đường biểu đồ phản ánh trend thật.
3
Diễn giải
Kết quả: thấy bottleneck hoặc lệch estimation.
4
Cải tiến
Kết quả: thay đổi quy trình giảm lãng phí sprint sau.

5) Đối tượng & Thuật ngữ

Các loại sprint report được nêu trong KB.

Velocity report: so cam kết vs hoàn thành theo estimation points (Velocity chart).
Burndown chart: xu hướng lượng việc còn lại; có thể xem theo points hoặc count (Burndown chart).
CFD: hiển thị tiến độ theo status; phụ thuộc status (CFD).
Latency: được nhắc như một loại sprint report (About report).

6) Vòng đời (State machine)

Reports thường phụ thuộc vòng đời sprint (planned/active/completed) và chuyển trạng thái work item. Hãy coi “đóng sprint” là bước cực quan trọng để report tóm tắt đúng khoảng thời gian.

Chỉ so sánh velocity giữa các sprint đã đóng/hoàn tất.
Chỉ diễn giải CFD khi team dùng status nhất quán trên board.
Khi đổi workflow statuses, ghi chú ngày đổi — so trend trước/sau có thể lệch.
Nếu bạn cần một đặc tả vòng đời report thống nhất: Không áp dụng cho tab này (docs mô tả loại report + cách xem, không có lifecycle spec chung).

7) Các “việc cần làm” cốt lõi

Các job về report giúp cải thiện delivery nhanh nhất.

Xem burndown: kiểm tra trend có khớp tiến độ kỳ vọng không.
Review velocity: so cam kết vs hoàn thành qua các sprint đã đóng.
Dùng CFD: phát hiện bottleneck khi việc bị dồn ở một status.
Chia sẻ insight: tóm tắt trong ghi chú retro.
Chỉnh planning: đổi scope, WIP, hoặc refinement dựa trên phát hiện.

8) Luồng chuẩn #1 — Xem sprint burndown chart

Theo bước chính thức: vào module Report, chọn View by Sprint Report, chọn Burndown, rồi chọn xem theo points/count.

Vào module Report.
Chọn View by là Sprint Report.
Chọn Report type là Burndown.
Xác nhận cách đọc trục (X = ngày, Y = estimation points) như mô tả.
Chuyển giữa chế độ point và count nếu cần.
Ghi 1 nhận xét: bạn đang ở trên/dưới đường ideal?

Kết quả mong đợi: Thấy trend lý tưởng vs thực tế và phát hiện rủi ro sớm trong sprint.

9) Luồng chuẩn #2 — Dùng CFD để tìm bottleneck

CFD theo dõi tiến độ theo status của item trên sprint board. Bạn dùng nó để thấy “chỗ nào đang bị dồn việc”.

Mở báo cáo Cumulative Flow Diagram (CFD) của một sprint.
Xác định dải status nào đang “phình to” theo thời gian.
Gắn dải đó với bước workflow thật (vd: review/testing).
Kiểm tra board xem có vượt WIP hoặc item bị block ở status đó không.
Chọn hành động: giảm intake, tăng capacity, hoặc đơn giản hoá bước đó.
Kiểm tra lại CFD sau 2–3 ngày để xem có cải thiện không.

Kết quả mong đợi: Gọi tên được status nghẽn và có hành động cụ thể để giảm nghẽn.

10) Điểm ra quyết định (A/B)

Report có thể làm team rối nếu dùng thiếu bối cảnh. Hãy quyết rõ các điểm sau.

Tình huống	Nếu A…	Nếu B…
Team dùng estimation points	Dùng velocity + burndown theo points	Dùng view theo count cho tới khi points ổn định
Board statuses mới đổi gần đây	Ghi chú ngày đổi; diễn giải trend cẩn thận	Trì hoãn so sánh giữa giai đoạn cũ/mới
Stakeholders muốn xem tiến độ	Chia sẻ snapshot burndown + giải thích ngắn	Chia sẻ release board nếu scope nhiều sprint
Dữ liệu có vẻ sai	Audit thói quen move status và đóng sprint	Tạm dừng report cho tới khi kỷ luật tốt hơn

Lỗi thường gặp (và cách tránh)

Lỗi: Dùng report như đánh giá hiệu suất cá nhân. Tránh: dùng để cải tiến quy trình.
Lỗi: Đổi status tuỳ tiện giữa sprint. Tránh: nếu có thể, đổi ở ranh giới sprint.
Lỗi: Không đóng sprint. Tránh: đóng đều để velocity so sánh được.
Lỗi: “Chốt” theo một biểu đồ duy nhất. Tránh: dùng burndown + CFD cùng nhau.
Lỗi: Bỏ qua hành vi nền tảng. Tránh: sửa kỷ luật board trước khi “sửa biểu đồ”.

Bài thực hành (10–15 phút)

Mục tiêu: tạo đủ hoạt động để burndown và CFD có ý nghĩa.

Chọn một sprint có ít nhất 5 items (hoặc tạo sprint practice).
Đảm bảo items có estimation points (hoặc chọn view theo count).
Di chuyển 2 items tiến lên 1 status mỗi ngày trong 2 ngày (hoặc mô phỏng nhanh bằng vài lần move).
Đóng ít nhất 1 item để tạo tín hiệu “done”.
Xem burndown và ghi 1 quan sát rủi ro.
Xem CFD và chỉ ra 1 status có dấu hiệu nghẽn.

Xác minh làm đúng: Cả hai chart đều có thay đổi (không phẳng) và bạn giải thích được hành vi trên board đã gây ra biến động đó.

Link tài liệu chính thức

Cài đặt Workspace

Quét nhanh

Cài đặt Workspace là một module KB top-level dùng để cấu hình hành vi ở cấp workspace.
Giới hạn WIP của Board được cấu hình trong Project Settings (theo tài liệu board), thường chịu sự quản trị bởi chính sách admin workspace/project.
Thiết lập mặc định sớm: vai trò, trang mở đầu và các quy tắc nhất quán để giảm ma sát.
Nếu một setting không được tài liệu hoá rõ cho gói của bạn, hãy coi là “Không áp dụng” và không tự suy diễn hành vi.

1) Mục đích / Kết quả

Workspace Settings là nơi bạn đặt “lan can” và mặc định áp dụng xuyên suốt các project. Kết quả là sự nhất quán: ít bất ngờ, ít lỗi quyền, và báo cáo sạch hơn.

Thiết lập quy ước toàn workspace (đặt tên, vai trò, mặc định).
Chọn thứ người dùng nhìn thấy đầu tiên (landing nếu có).
Đảm bảo setting hỗ trợ kiểu vận hành bạn chọn (Scrum/Kanban).
Giảm việc “tái phát minh” theo từng project bằng cách ghi lại mặc định.

2) Dành cho ai + Khi nào dùng

Chủ yếu dành cho admin và team lead. Dùng trong giai đoạn setup ban đầu, khi thêm nhiều project, hoặc sau khi lặp lại vấn đề quy trình (như quá tải WIP hay báo cáo không nhất quán).

Workspace admin: sở hữu setting toàn cục và governance.
Project lead: căn chỉnh setting cấp project theo quy tắc workspace.
Security/compliance: kiểm tra khớp chính sách (xem module Security & Compliance).
Ops: xác thực tích hợp và luồng admin (nếu dùng).

3) Vị trí trong điều hướng + Tab liên quan

Workspace Settings xuất hiện như module KB top-level bên cạnh Customization, Layout and Rules, Data Administration và Security & Compliance.

Liên quan: Projects (áp dụng mặc định), Users (vai trò), Board (WIP qua project settings), Reports (tính nhất quán dữ liệu).
Governance gần kề: Customization / Layout and Rules cho field và form.

4) Mô hình tư duy / Luồng

Cài đặt workspace nên được coi như cấu hình sản phẩm: xác định mục tiêu → đặt mặc định → test bằng pilot project → rollout.

1
Xác định mục tiêu
Kết quả: rõ bạn đang tối ưu cho điều gì.
2
Đặt mặc định
Kết quả: trạng thái khởi đầu nhất quán cho project/user.
3
Pilot
Kết quả: kiểm chứng setting trong 1 project.
4
Rollout
Kết quả: áp dụng cho các team với ít gián đoạn.

5) Đối tượng & Thuật ngữ

Các khái niệm cấp workspace thường liên kết sang module khác.

Landing preferences: có thể đặt Global View làm trang mở đầu qua Profile Customization (ghi chú trong bài Global View, liên quan settings).
Project settings: nơi định nghĩa WIP limits (bài Board).
Defaults: template, quy ước và quy tắc xuyên project mà bạn chuẩn hoá.
Governance: kỳ vọng về vai trò và quyền truy cập.

6) Vòng đời (State machine)

Thay đổi setting có vòng đời: đề xuất → thử nghiệm → áp dụng → audit. Đây là vòng đời quản trị nội bộ, không phải state machine trong app.

Đề xuất thay đổi với lý do rõ ràng (vd: quá tải WIP, report không nhất quán).
Test trong pilot project trong 1 chu kỳ sprint.
Rollout kèm changelog ngắn và hành vi sẽ khác gì.
Audit sau 2 tuần để xác nhận có cải thiện.

7) Các “việc cần làm” cốt lõi

Giữ việc cấu hình workspace tập trung vào ổn định và rõ ràng.

Đặt mặc định governance: ai được tạo project/sprint, ai duyệt time.
Chuẩn hoá luật board: chiến lược WIP và hướng dẫn ý nghĩa status.
Giảm ma sát: chọn mặc định phù hợp đa số team.
Hỗ trợ reporting: kỳ vọng thống nhất về estimation và dùng status.
Tài liệu hoá: viết 1 trang “chúng ta dùng Zoho Sprints thế nào”.

8) Luồng chuẩn #1 — Thiết lập baseline cho workspace (pilot trước)

Cách an toàn khi tài liệu rải ở nhiều module và bạn muốn tránh làm “vỡ” thói quen của team.

Liệt kê quyết định baseline: Scrum vs Kanban, kiểu estimation, triết lý WIP.
Chọn 1 pilot project và áp baseline ở đó.
Cấu hình các project settings cần cho kỷ luật board (vd: WIP limits).
Chạy 1 sprint (hoặc 1 tuần flow) với pilot team.
Kiểm tra report (burndown/CFD) xem có dễ diễn giải không.
Công bố baseline thành một chuẩn nội bộ ngắn.

Kết quả mong đợi: Bạn có baseline đã được kiểm chứng để project mới theo mà không lo hỗn loạn.

9) Luồng chuẩn #2 — Đặt Global View làm trang mở đầu (nếu muốn)

Bài Global View có ghi chú rằng bạn có thể đặt Global View làm landing page qua Profile Customization trong Settings. Dùng cách này để người dùng có điểm bắt đầu “tổng quan”.

Mở Global View và xác nhận các view mặc định hữu ích.
Vào Settings → Profile Customization (như bài Global View nhắc).
Đặt Global View làm landing page.
Nhờ 1–2 user kiểm chứng trải nghiệm mở đầu mới.
Tài liệu hoá: khi nào dùng Global View vs trang project.
Rollout khuyến nghị cho cả workspace.

Kết quả mong đợi: Người dùng bắt đầu từ một view tổng hợp và điều hướng tới việc nhanh hơn.

10) Điểm ra quyết định (A/B)

Chốt rõ các lựa chọn cấp workspace để giảm mơ hồ.

Tình huống	Nếu A…	Nếu B…
Nhiều user mới tham gia	Chuẩn hoá landing page + baseline rules đơn giản	Để từng team tự cấu hình (rủi ro: không nhất quán)
Team kêu quá tải WIP	Áp hướng dẫn WIP limit + enforce ở pilot	Bỏ WIP; tập trung kỷ luật refinement
Report khó so sánh	Chuẩn hoá estimation (points vs count)	Cho phép trộn (chấp nhận so sánh cross-team yếu)
Cần governance	Định nghĩa role matrix và ownership	Giữ “phi chính thức” (rủi ro: bất ngờ về quyền)

Lỗi thường gặp (và cách tránh)

Lỗi: Đổi rule mỗi tuần. Tránh: theo nhịp pilot → rollout.
Lỗi: Không có baseline được ghi lại. Tránh: viết chuẩn 1 trang.
Lỗi: Over-configure quá sớm. Tránh: bắt đầu tối giản rồi lặp cải tiến.
Lỗi: Bỏ qua trải nghiệm người dùng. Tránh: test landing/navigation với user thật.
Lỗi: Coi setting là “set and forget”. Tránh: audit theo quý.

Bài thực hành (10–15 phút)

Mục tiêu: xác định một baseline cho workspace và kiểm chứng ở 1 pilot project mà không phá workflow.

Viết 3 baseline rules: kiểu estimation, ý nghĩa status, cách dùng WIP.
Chọn 1 pilot project và cấu hình project settings theo baseline (vd: WIP limit).
Chạy mini sprint với 5 items và di chuyển status nhất quán.
Mở report (burndown/CFD) và xem có khớp thực tế không.
Điều chỉnh baseline 1 lần (tối đa) dựa trên bài học pilot.
Công bố baseline cho team.

Xác minh làm đúng: Một thành viên mới có thể vào pilot project và làm theo baseline mà không phải hỏi “dùng cái này kiểu gì?”.

Your favorites

Dự án

1) Mục đích / Kết quả

2) Dành cho ai + Khi nào dùng

3) Vị trí trong điều hướng + Tab liên quan

4) Mô hình tư duy / Luồng

5) Đối tượng & Thuật ngữ

6) Vòng đời (State machine)

7) Các “việc cần làm” cốt lõi

8) Luồng chuẩn #1 — Tạo dự án “sẵn sàng chạy”

9) Luồng chuẩn #2 — Chuẩn bị dự án để báo cáo “đọc được”

10) Điểm ra quyết định (A/B)

11) Lỗi thường gặp (và cách tránh)

12) Bài thực hành (10–15 phút)

Link tài liệu chính thức

Người dùng

1) Mục đích / Kết quả

2) Dành cho ai + Khi nào dùng

3) Vị trí trong điều hướng + Tab liên quan

4) Mô hình tư duy / Luồng

5) Đối tượng & Thuật ngữ

6) Quyền & Vai trò

7) Các “việc cần làm” cốt lõi

8) Luồng chuẩn #1 — Onboard thành viên mới

9) Luồng chuẩn #2 — Offboard an toàn (không “mồ côi” công việc)

10) Điểm ra quyết định (A/B)

Lỗi thường gặp (và cách tránh)

Bài thực hành (10 phút)

Link tài liệu chính thức

Backlog

1) Mục đích / Kết quả

2) Dành cho ai + Khi nào dùng

3) Vị trí trong điều hướng + Tab liên quan

4) Mô hình tư duy / Luồng

5) Đối tượng & Thuật ngữ

6) Vòng đời (State machine)

7) Các “việc cần làm” cốt lõi

8) Luồng chuẩn #1 — Biến một yêu cầu thành item “sẵn sàng sprint”

9) Luồng chuẩn #2 — Chạy một vòng refinement backlog (30–45 phút)

10) Điểm ra quyết định (A/B)

Lỗi thường gặp (và cách tránh)

Bài thực hành (10–15 phút)

Link tài liệu chính thức

Sprints

1) Mục đích / Kết quả

2) Dành cho ai + Khi nào dùng

3) Vị trí trong điều hướng + Tab liên quan

4) Mô hình tư duy / Luồng

5) Đối tượng & Thuật ngữ

6) Vòng đời (State machine)

7) Các “việc cần làm” cốt lõi

8) Luồng chuẩn #1 — Tạo sprint (từ đầu)

9) Luồng chuẩn #2 — Tạo sprint và gắn với release

10) Điểm ra quyết định (A/B)

Lỗi thường gặp (và cách tránh)

Bài thực hành (10–15 phút)

Link tài liệu chính thức

Board

1) Mục đích / Kết quả

2) Dành cho ai + Khi nào dùng

3) Vị trí trong điều hướng + Tab liên quan

4) Mô hình tư duy / Luồng

5) Đối tượng & Thuật ngữ

6) Vòng đời (State machine)

7) Các “việc cần làm” cốt lõi

8) Luồng chuẩn #1 — Cấu hình và dùng WIP limits

9) Luồng chuẩn #2 — Dùng swimlanes để tập trung daily review

10) Điểm ra quyết định (A/B)

Lỗi thường gặp (và cách tránh)

Bài thực hành (10–15 phút)

Link tài liệu chính thức

Release

1) Mục đích / Kết quả

2) Dành cho ai + Khi nào dùng

3) Vị trí trong điều hướng + Tab liên quan

4) Mô hình tư duy / Luồng

5) Đối tượng & Thuật ngữ

6) Vòng đời (State machine)

7) Các “việc cần làm” cốt lõi

8) Luồng chuẩn #1 — Gắn sprint vào release khi lập kế hoạch