Phỏng Vấn IT Project Manager & Scrum Master: 10 Câu Hỏi Về Quản Lý Tiến Độ - Sprint Lỡ Deadline Thì Sao?
Mục lục bài viết
Tại Sao Nhà Tuyển Dụng Luôn Hỏi Về Quản Lý Tiến Độ?
Bạn đang chuẩn bị cho vị trí IT Project Manager hoặc Scrum Master? Hãy tưởng tượng: buổi phỏng vấn bắt đầu, interviewer nhìn thẳng vào bạn và hỏi: "Sprint của team vừa lỡ deadline 3 ngày, bạn xử lý thế nào?" Tim đập nhanh, mồ hôi chảy, và bạn biết rằng câu trả lời quyết định bạn có được offer hay không.
Đó chính là lý do bạn cần chuẩn bị kỹ lưỡng trước khi bước vào phòng phỏng vấn. Quản lý tiến độ không chỉ là kỹ năng cứng, nó là thước đo khả năng lãnh đạo, tư duy hệ thống và bản lĩnh của một PM/Scrum Master thực thụ.
👉 Luyện phỏng vấn IT PM & Scrum Master ngay trên X Interview
Bài viết này tổng hợp 10 câu hỏi phỏng vấn IT Project Manager và Scrum Master phổ biến nhất về quản lý tiến độ, kèm theo gợi ý trả lời chi tiết giúp bạn tự tin vượt qua vòng phỏng vấn.
1. Câu Hỏi Về Sprint Planning Và Ước Lượng
1. Bạn sẽ làm gì khi sprint bị lỡ deadline?
Đây là câu hỏi kinh điển mà mọi interviewer đều đặt ra cho vị trí PM hoặc Scrum Master. Câu trả lời tốt cần thể hiện tư duy phản biện và khả năng xử lý tình huống thực tế.
Cách trả lời hiệu quả:
Bước 1: Xác định nguyên nhân gốc rễ (Root Cause Analysis). Không đổ lỗi cho ai, hãy phân tích khách quan. Có phải do ước lượng sai? Do yêu cầu thay đổi giữa sprint? Do blocker kỹ thuật không được phát hiện sớm?
Bước 2: Đánh giá tác động. Các task nào đang bị ảnh hưởng? Mức độ ảnh hưởng đến stakeholder và release plan là gì?
Bước 3: Đưa ra giải pháp cụ thể. Nếu sprint đã lỡ, họp lại với team để xác định scope còn lại có thể hoàn thành. Thương lượng với Product Owner về priority. Nếu cần, giảm scope nhưng giữ chất lượng.
Bước 4: Retrospective và cải tiến. Sau sprint, tổ chức retro để rút kinh nghiệm, cập nhật Definition of Done, điều chỉnh cách ước lượng cho sprint tiếp theo.
Điểm mấu chốt: interviewer muốn nghe bạn xử lý tình huống có phương pháp, không hoảng loạn, và luôn hướng đến cải tiến liên tục.
2. Bạn ước lượng story point như thế nào cho một dự án mới?
Câu này kiểm tra kinh nghiệm thực tế của bạn với Agile estimation. Câu trả lời tốt nên bao gồm:
Planning Poker: Đây là kỹ thuật phổ biến nhất. Mỗi thành viên team đưa ra estimate độc lập bằng story point (Fibonacci sequence: 1, 2, 3, 5, 8, 13...). Khi có sự khác biệt lớn, team thảo luận để hiểu góc nhìn khác nhau, sau đó vote lại.
T-shirt Sizing: Phù hợp cho giai đoạn đầu khi chưa có đủ thông tin. Phân loại task thành XS, S, M, L, XL để có cái nhìn tổng quan nhanh.
Relative Estimation: So sánh task mới với task đã hoàn thành trước đó. Nếu task A mất 5 story point, task B phức tạp hơn khoảng 1.5 lần thì ước lượng 8 point.
Velocity Tracking: Theo dõi số story point team hoàn thành trong mỗi sprint để dự báo capacity cho sprint tiếp theo. Đây là dữ liệu quan trọng nhất để ước lượng chính xác.
👉 Thực hành trả lời câu hỏi Agile estimation trên X Interview
3. Làm thế nào để quản lý backlog hiệu quả khi có quá nhiều yêu cầu từ nhiều phía?
Quản lý backlog là kỹ năng cốt lõi của PM và Product Owner, nhưng Scrum Master cũng cần hiểu rõ để hỗ trợ team.
Prioritize bằng MoSCoW Method: Phân loại yêu cầu thành Must have, Should have, Could have, Won't have. Đây là framework đơn giản nhưng cực kỳ hiệu quả.
Sử dụng Value vs Effort Matrix: Đánh giá mỗi yêu cầu dựa trên giá trị kinh doanh (business value) và nỗ lực thực hiện (effort). Ưu tiên những task có giá trị cao, effort thấp.
Regular Backlog Refinement: Họp với team mỗi tuần 1 lần để review, estimate và sắp xếp lại backlog. Điều này giúp backlog luôn sạch và cập nhật.
Stakeholder Alignment: Tổ chức meeting riêng với từng stakeholder để hiểu rõ yêu cầu của họ, sau đó tổng hợp và trình bày cho team với priority rõ ràng.
Ràng buộc bằng dữ liệu: Không ưu tiên theo cảm tính hay ai nói to hơn. Sử dụng dữ liệu về user impact, revenue impact và technical debt để đưa ra quyết định khách quan.
2. Câu Hỏi Về Stakeholder Communication
4. Bạn xử lý thế nào khi stakeholder thay đổi yêu cầu giữa sprint?
Đây là tình huống xảy ra ở hầu hết dự án thực tế. Câu trả lời của bạn cần thể hiện sự cân bằng giữa linh hoạt và kỷ luật Scrum.
Trước tiên, lắng nghe và hiểu lý do thay đổi. Có thể stakeholder có thông tin mới mà team chưa biết. Không nên từ chối ngay lập tức.
Đánh giá tác động: Thay đổi này ảnh hưởng thế nào đến sprint goal? Có task nào phải dừng lại? Có blocker nào phát sinh?
Thương lượng với Product Owner: Đây là trách nhiệm của PO, nhưng Scrum Master cần facilitate cuộc thảo luận. Nếu thay đổi là cần thiết, một task khác có cùng priority cần được loại ra khỏi sprint.
Nếu thay đổi quá lớn: Đề xuất hủy sprint hiện tại và planning lại. Đây là quyết định nghiêm trọng nhưng đôi khi cần thiết.
Thông báo cho team một cách minh bạch: Giải thích lý do thay đổi, tác động đến sprint goal, và kế hoạch mới. Team cần hiểu context để đồng lòng thực hiện.
5. Làm sao để báo cáo tiến độ dự án cho ban lãnh đạo một cách hiệu quả?
Ban lãnh đạo không cần biết chi tiết từng task. Họ cần cái nhìn tổng quan: dự án có đúng tiến độ không, có rủi ro gì, và cần resource gì thêm.
Sử dụng Burn-down Chart: Đây là công cụ trực quan nhất để thể hiện tiến độ sprint. Ban lãnh đạo có thể thấy ngay team đang ahead hay behind schedule.
RAG Status Report: Đánh giá dự án theo Red/Amber/Green. Đơn giản, dễ hiểu, phù hợp cho báo cáo hàng tuần.
Elevator Pitch Format: Tóm tắt dự án trong 30 giây: Mục tiêu là gì, tiến độ hiện tại, rủi ro chính, hành động tiếp theo.
Dashboard tự động: Nếu có thể, thiết lập dashboard real-time với Jira, Azure DevOps hoặc Trello. Ban lãnh đạo có thể tự kiểm tra bất cứ lúc nào.
👉 Luyện trả lời câu hỏi stakeholder management trên X Interview
6. Bạn sẽ làm gì khi team không đồng ý với priority mà Product Owner đặt ra?
Xung đột giữa team và PO là điều bình thường trong Agile. Scrum Master cần đóng vai trò mediator.
Tạo không gian thảo luận an toàn: Tổ chức meeting riêng, không có áp lực, để team và PO trình bày quan điểm.
Sử dụng dữ liệu: Yêu cầu cả hai bên đưa ra lý do cụ thể, không chỉ cảm tính. PO cần giải thích business value, team cần giải thích technical constraints.
Thử nghiệm nhỏ: Nếu không thể thống nhất, đề xuất thử nghiệm trong 1 sprint với priority của PO, sau đó đánh giá kết quả thực tế.
Tôn trọng quyết định cuối cùng của PO: Theo Scrum framework, PO có quyền quyết định priority. Tuy nhiên, Scrum Master cần đảm bảo PO hiểu rõ quan điểm của team trước khi đưa ra quyết định.
3. Câu Hỏi Về Agile/Scrum Framework
7. Scrum và Kanban khác nhau như thế nào, và khi nào bạn chọn phương pháp nào?
Câu này kiểm tra kiến thức nền tảng về Agile methodology.
Scrum:
- Có sprint cố định (thường 2-4 tuần)
- Có các ceremony: Sprint Planning, Daily Standup, Sprint Review, Retrospective
- Có roles cố định: Product Owner, Scrum Master, Development Team
- Phù hợp cho dự án có scope rõ ràng, cần deliver thường xuyên
Kanban:
- Không có sprint, công việc liên tục (continuous flow)
- Giới hạn Work In Progress (WIP) để đảm bảo focus
- Visualize workflow bằng Kanban board
- Phù hợp cho support team, maintenance, hoặc dự án có yêu cầu thay đổi liên tục
Khi nào chọn Scrum: Dự án phát triển sản phẩm mới, team cần rhythm và structure, stakeholder muốn thấy deliverable mỗi sprint.
Khi nào chọn Kanban: Team vận hành, sửa lỗi, dự án không có deadline cố định, hoặc team mới chuyển từ Waterfall sang Agile.
ScrumBan: Kết hợp cả hai, sử dụng sprint nhưng vẫn áp dụng Kanban principles. Phù hợp cho team đang transition.
👉 Ôn luyện kiến thức Agile và Scrum framework trên X Interview
8. Bạn đo lường hiệu quả của team như thế nào trong Agile?
Đo lường hiệu quả team không chỉ là đếm story point. Cần nhìn nhiều chiều.
Velocity: Số story point hoàn thành mỗi sprint. Theo dõi trend qua 3-5 sprint để có dự báo chính xác. Lưu ý: velocity dùng để dự báo, không dùng để đánh giá cá nhân.
Cycle Time: Thời gian từ khi task bắt đầu đến khi hoàn thành. Cycle time ngắn nghĩa là team đang làm việc hiệu quả.
Lead Time: Thời gian từ khi yêu cầu được tạo đến khi được deliver cho user. Bao gồm cả thời gian chờ trong backlog.
Sprint Goal Achievement Rate: Tỷ lệ sprint hoàn thành đúng sprint goal. Nếu liên tục không đạt, cần phân tích nguyên nhân.
Team Satisfaction: Khảo sát định kỳ (mỗi 2-4 sprint) để đo lường tinh thần team. Team hạnh phúc sẽ làm việc hiệu quả hơn.
Escaped Defects: Số lỗi được phát hiện sau khi release. Đây là chỉ báo chất lượng quan trọng.
4. Câu Hỏi Về Risk Management
9. Bạn xác định và quản lý rủi ro trong dự án IT như thế nào?
Risk management là kỹ năng bắt buộc cho mọi PM. Câu trả lời cần có framework rõ ràng.
Risk Identification:
- Brainstorm với team trong sprint planning
- Review lesson learned từ dự án trước
- Phân tích dependency giữa các task
- Đánh giá kỹ năng team có đủ không
Risk Assessment:
- Sử dụng Probability x Impact matrix
- Phân loại risk thành High/Medium/Low
- Ưu tiên xử lý risk có impact lớn trước
Risk Mitigation:
- Avoid: Thay đổi plan để loại bỏ risk hoàn toàn
- Transfer: Chuyển risk cho bên khác (ví dụ: outsource phần phức tạp)
- Mitigate: Giảm probability hoặc impact
- Accept: Chấp nhận risk nếu impact thấp
Risk Monitoring:
- Cập nhật risk register hàng tuần
- Discuss risk trong daily standup khi cần
- Escalate cho stakeholder khi risk become issue
10. Khi dự án bị delay nghiêm trọng, bạn sẽ communicate với stakeholder như thế nào?
Đây là câu hỏi tình huống phức tạp, kiểm tra khả năng leadership và communication.
Nguyên tắc vàng: Thông báo sớm, thông báo trung thực, và đi kèm giải pháp.
Bước 1: Đánh giá tình hình chính xác. Xác định delay bao lâu, nguyên nhân là gì, và có thể recover không. Không thông báo khi chưa hiểu rõ vấn đề.
Bước 2: Chuẩn bị communication plan. Ai cần biết? Mức độ chi tiết cho từng đối tượng? Format thông báo (email, meeting, call)?
Bước 3: Thông báo với giải pháp. Không chỉ nói "chúng tôi bị delay" mà cần trình bày: Nguyên nhân cụ thể, thời gian delay dự kiến, các option để recover, và recommendation của bạn.
Bước 4: Cập nhật thường xuyên. Sau khi thông báo, cập nhật tiến độ hàng ngày hoặc hàng tuần cho đến khi dự án ổn định lại.
Bước 5: Post-mortem. Sau khi dự án hoàn thành, phân tích nguyên nhân delay để cải tiến cho dự án tiếp theo.
👉 Luyện phỏng vấn tình huống PM & Scrum Master trên X Interview
5. Chiến Lược Trả Lời Phỏng Vấn Hiệu Quả
Ngoài việc nắm vững kiến thức chuyên môn, cách bạn trình bày câu trả lời cũng quan trọng không kém.
Sử dụng STAR Method: Situation (tình huống), Task (nhiệm vụ), Action (hành động), Result (kết quả). Đây là framework trả lời phỏng vấn tình huống hiệu quả nhất.
Kể câu chuyện thực tế: Interviewer muốn nghe trải nghiệm thực của bạn, không phải lý thuyết sách vở. Hãy chuẩn bị 3-5 câu chuyện từ kinh nghiệm làm việc trước đây.
Thể hiện tư duy cải tiến liên tục: Khi trả lời bất kỳ câu hỏi nào, luôn kết thúc bằng cách bạn đã rút kinh nghiệm và cải tiến như thế nào.
Đặt câu hỏi ngược: Sau khi trả lời, hãy đặt câu hỏi cho interviewer về cách công ty họ xử lý tình huống tương tự. Điều này thể hiện sự quan tâm và tư duy cầu tiến.
👉 Tập luyện phỏng vấn IT PM & Scrum Master với AI trên X Interview
6. Kết Luận
Phỏng vấn IT Project Manager và Scrum Master không chỉ kiểm tra kiến thức mà còn đánh giá khả năng xử lý tình huống, leadership và communication skills. 10 câu hỏi trên đã bao gồm những chủ đề quan trọng nhất mà bạn sẽ gặp trong buổi phỏng vấn thực tế.
Điều quan trọng nhất là hãy luyện tập trả lời thường xuyên. Mỗi câu hỏi không có đáp án đúng duy nhất, nhưng có cách trả lời tốt và cách trả lời chưa tốt. Kinh nghiệm thực tế kết hợp với sự chuẩn bị kỹ lưỡng sẽ giúp bạn tự tin vượt qua mọi câu hỏi khó.
Chúc bạn phỏng vấn thành công và nhận được offer mơ ước!
7. Tài Liệu Tham khảo
- Scrum Guide 2020 - Ken Schwaber & Jeff Sutherland: https://scrumguides.org/
- PMI Project Management Body of Knowledge (PMBOK Guide) 7th Edition: https://www.pmi.org/pmbok-guide-standards
- Agile Practice Guide - PMI & Agile Alliance: https://www.pmi.org/agile
- "User Story Mapping" by Jeff Patton: https://www.oreilly.com/library/view/user-story-mapping/9781491904893/
- Scaled Agile Framework (SAFe): https://www.scaledagileframework.com/
- Kanban University: https://kanban.university/
- Mountain Goat Software - Mike Cohn's Agile Resources: https://www.mountaingoatsoftware.com/
Tags: phong-van-it-project-manager, scrum-master, agile, sprint-planning, quan-ly-tien-do