Tóm tắt nhanh
Sprint planning là buổi team quyết định sprint này sẽ đạt mục tiêu gì và chọn backlog nào để làm. Với developer Việt Nam, điểm quan trọng là không chỉ nghe rồi nhận task. Bạn cần hiểu sprint goal, acceptance criteria, estimate, capacity, dependency và risk trước khi sprint bắt đầu.
Bài này giúp bạn vào planning tự tin hơn trong team Nhật. Nếu chưa quen báo rủi ro và deadline, đọc thêm quản lý deadline trong dự án Nhật.
Sprint planning là gì?
スプリントプランニング là meeting đầu sprint. Team thường bàn:
- Nội dung
- Sprint goal
- Câu hỏi cần trả lời
- Sprint này muốn đạt kết quả gì?
- Nội dung
- Backlog
- Câu hỏi cần trả lời
- Story/task nào được chọn?
- Nội dung
- Acceptance criteria
- Câu hỏi cần trả lời
- Khi nào story được xem là xong?
- Nội dung
- Estimate
- Câu hỏi cần trả lời
- Mỗi story mất khoảng bao nhiêu effort?
- Nội dung
- Capacity
- Câu hỏi cần trả lời
- Team có bao nhiêu thời gian thực tế?
- Nội dung
- Dependency
- Câu hỏi cần trả lời
- Có phụ thuộc người khác, API, design, khách hàng không?
- Nội dung
- Risk
- Câu hỏi cần trả lời
- Có điểm nào có thể làm sprint trễ không?
Trong team Nhật, planning tốt thường có 認識合わせ rất kỹ. Không phải để làm chậm, mà để tránh vào giữa sprint mới phát hiện scope khác nhau.
Developer nên chuẩn bị trước planning
Trước meeting, hãy đọc backlog và note những điểm chưa rõ:
- Story nào có acceptance criteria chưa rõ
- Story nào cần spec hoặc design bổ sung
- Story nào có ảnh hưởng API, DB, batch, permission
- Story nào cần test dữ liệu đặc biệt
- Story nào phụ thuộc người khác
- Story nào estimate khó vì chưa điều tra
Nếu bạn chỉ đọc backlog trong meeting, khó đặt câu hỏi tốt. Đọc trước 15 phút có thể giúp sprint tiết kiệm nhiều giờ.
Estimate nên nói thế nào?
Khi estimate, đừng chỉ nói số. Nếu có uncertainty, hãy nói lý do:
- Tình huống
- Estimate được
- Câu tiếng Nhật
- この内容であれば2日程度で対応可能です。
- Tình huống
- Cần điều tra trước
- Câu tiếng Nhật
- 影響範囲が不明なため、先に調査が必要です。
- Tình huống
- Scope chưa rõ
- Câu tiếng Nhật
- 完了条件を確認してから見積もりたいです。
- Tình huống
- Có risk
- Câu tiếng Nhật
- API仕様が未確定のため、遅延リスクがあります。
Estimate trong Scrum không phải lời hứa tuyệt đối. Nhưng bạn cần minh bạch về giả định và rủi ro.
Developer Việt Nam dễ hiểu sai điểm nào?
1. "Planning là PM chia việc"
Trong Scrum, development team cũng tham gia quyết định lượng việc có thể cam kết. Nếu capacity không đủ, cần nói sớm.
2. "Không rõ vẫn estimate cho nhanh"
Estimate khi chưa rõ scope dễ làm sprint fail. Hãy nói rõ phần chưa rõ và đề xuất spike hoặc investigation task.
3. "Story point là ngày công"
Story point thường biểu thị độ phức tạp tương đối, không phải ngày công trực tiếp. Mỗi team có cách dùng khác nhau, nên cần hỏi convention của team.
4. "Chọn nhiều backlog càng tốt"
Sprint tốt không phải là nhồi nhiều việc, mà là đạt goal và có chất lượng. Quá tải làm daily và review mất giá trị.
Câu tiếng Nhật nên nhớ
- 日本語
- スプリントゴールを確認したいです。
- かな
- すぷりんとごーるをかくにんしたいです
- Nghĩa tiếng Việt
- Tôi muốn xác nhận sprint goal.
- Dùng khi nào
- Planning
- 日本語
- 完了条件を確認させてください。
- かな
- かんりょうじょうけんをかくにんさせてください
- Nghĩa tiếng Việt
- Cho tôi xác nhận điều kiện hoàn thành.
- Dùng khi nào
- Story chưa rõ
- 日本語
- 見積もりは3ポイントです。
- かな
- みつもりはさんぽいんとです
- Nghĩa tiếng Việt
- Estimate là 3 point.
- Dùng khi nào
- Planning poker
- 日本語
- 先に調査が必要です。
- かな
- さきにちょうさがひつようです
- Nghĩa tiếng Việt
- Cần điều tra trước.
- Dùng khi nào
- Không đủ thông tin
- 日本語
- このスプリントでは難しいと思います。
- かな
- このすぷりんとではむずかしいとおもいます
- Nghĩa tiếng Việt
- Tôi nghĩ khó trong sprint này.
- Dùng khi nào
- Capacity/risk
- 日本語
- 優先度を調整したいです。
- かな
- ゆうせんどをちょうせいしたいです
- Nghĩa tiếng Việt
- Tôi muốn điều chỉnh priority.
- Dùng khi nào
- Khi quá tải
Checklist trước khi kết thúc planning
- Sprint goal có rõ không?
- Mỗi story có acceptance criteria không?
- Estimate dựa trên giả định nào?
- Capacity đã trừ ngày nghỉ, meeting, support chưa?
- Dependency và risk đã ghi lại chưa?
- Task investigation có được tách riêng nếu cần không?
Học tiếp trên JLPTVN
Đọc tiếp backlog và user story, Definition of Done trong Scrum Nhật, estimate story point. Luyện câu tại ticket và progress.
Sau khi đọc, làm bài luyện IT và lưu câu sai ở Review để quay lại đúng điểm yếu.
FAQ
Sprint planning nên kéo dài bao lâu?
Tùy sprint length và độ phức tạp backlog. Quan trọng là meeting đủ để team hiểu goal, scope và risk, không phải càng dài càng tốt.
Nếu PO muốn đưa quá nhiều việc vào sprint thì sao?
Hãy nói bằng capacity và risk cụ thể. Ví dụ task A, B, C đều cần review và test nên sprint này khó đảm bảo chất lượng.
Có nên estimate task chưa rõ không?
Nên tách spike hoặc investigation trước. Nếu vẫn phải estimate, hãy ghi rõ giả định.