Case Study 1: Độ trễ trong việc triển khai tính năng mới
Bối cảnh: Một đội phát triển một tính năng mới cho hệ thống quản lý khách hàng. Trong Sprint 3, tính năng bị trễ 5 ngày do thiếu hiểu biết về phụ thuộc dữ liệu.
Nguyên nhân:
- Không có Definition of Ready rõ ràng, story chưa được phân tích chi tiết.
- Thiếu Spike để khám phá cách truy vấn dữ liệu hiệu quả.
- Không thực hiện Planning Poker đúng cách, ước lượng quá thấp.
Giải pháp:
- Áp dụng Definition of Ready: yêu cầu mô tả chi tiết, acceptance criteria, và phụ thuộc.
- Thực hiện Spike: tạo một spike để thử nghiệm truy vấn và xác định độ phức tạp.
- Sử dụng Planning Poker với reference story để ước lượng lại, thêm 0.5 point cho rủi ro chưa biết.
- Trong Sprint Review, trình bày nguyên nhân và cách cải thiện, đưa vào Retrospective.
Case Study 2: Đánh mất độ ổn định do quá tải WIP
Bối cảnh: Đội đang làm đồng thời 8 story trong một Sprint, dẫn đến nhiều task bị treo và giảm velocity.
Nguyên nhân:
- Không giới hạn Work‑In‑Progress (WIP).
- Thiếu Daily Scrum hiệu quả, không phát hiện sớm các bottleneck.
Giải pháp:
- Áp dụng Kanban board trong Sprint, đặt giới hạn WIP (max 3 story cùng lúc).
- Tăng tần suất Daily Scrum, tập trung vào việc phát hiện và giải quyết blockers.
- Thực hiện Retrospective để điều chỉnh WIP limit cho Sprint tiếp theo.
Case Study 3: Không đáp ứng KPI thời gian phản hồi
Bối cảnh: Ứng dụng web có thời gian phản hồi trung bình 2.5s, vượt quá KPI 1s.
Nguyên nhân:
- Các story liên quan tới performance không được ưu tiên trong backlog.
- Thiếu Performance Testing trong Definition of Done.
Giải pháp:
- Đưa Performance Story lên đầu backlog, ưu tiên trong Sprint Planning.
- Định nghĩa Definition of Done bao gồm kiểm thử load và profiling.
- Sử dụng Story Points để ước lượng effort cho performance tuning.
- Theo dõi velocity và burn‑down chart để đảm bảo tiến độ.
Được chuẩn bị bởi đội SDLC Sessions – các case study thực tiễn cho Scrum.