How to address a teammate working on low-priority tasks?

WHAT THIS TESTS: This question assesses your commitment to the Scrum values of respect, openness, and commitment, specifically to the Sprint Goal. The interviewer is looking for a response that demonstrates peer-to-peer accountability within the self-managing Scrum Team. They want to see if you understand your role as a Developer is not to manage others, but to collaborate and hold the team accountable to its shared goals. It also tests your knowledge of when and how to use Scrum events and roles (Daily Scrum, Scrum Master) to resolve impediments.

A GOOD ANSWER COVERS: An excellent answer follows a path of escalating transparency. First, approach the teammate privately and with curiosity, not accusation, after the Daily Scrum. Seek to understand their reasoning. Second, if a private conversation doesn't resolve it, re-center the conversation on the team's commitment to the Sprint Goal. Frame it as a shared problem. Third, if the behavior persists, use the next Daily Scrum to make the risk to the Sprint Goal transparent to the entire team. This is not about blaming an individual but about inspecting progress and adapting the plan. Finally, as a last resort, involve the Scrum Master, whose job is to help remove impediments and ensure the team is using Scrum effectively.

COMMON WRONG ANSWERS: Red flags include answers that undermine team self-management. The most common mistake is immediately escalating to the Scrum Master or an engineering manager. This signals a lack of trust in your peers and an unwillingness to handle conflict directly. Another red flag is publicly confronting the teammate during the Daily Scrum, which can create a hostile environment. The Daily Scrum is for planning and inspection, not for conflict resolution. Finally, simply ignoring the problem is also a bad answer, as it shows a lack of commitment to the team's success and the Sprint Goal.

LIKELY FOLLOW-UPS: Be prepared for follow-ups like, "What if the teammate gets defensive when you talk to them privately?" (Your answer should focus on 'I' statements and the shared team goal). Or, "What if the task they're working on is actually a hidden, urgent dependency?" (This highlights the importance of starting with curiosity and making that dependency transparent to the team and Product Owner). Another is, "What if the Scrum Master doesn't take action?" (A good answer would involve raising the issue as a systemic problem in the Sprint Retrospective).

ONE CONCRETE EXAMPLE: "After the Daily Scrum, I'd find a moment to talk to my teammate. I'd say something like, 'Hey, I noticed you're working on the old analytics dashboard. I was curious because our Sprint Goal is all about the new payment gateway. Is there a blocker on the gateway tasks I could help with?' This opens a dialogue. If the behavior continued, in the next Daily Scrum I would state, 'I'm concerned about our progress towards the Sprint Goal. We have only 3 days left and key tasks for the payment gateway haven't been started. We need to inspect our plan to ensure we can deliver.' This makes it a team problem to solve."