A PBI is vague. How do you get clarity?

What's really being asked

This question assesses your sense of ownership, communication skills, and understanding of core agile principles, specifically the "Definition of Ready." Interviewers want to see that you don't just consume tasks, but actively de-risk them. They're testing if you prevent wasted work by ensuring requirements are clear before writing code, rather than discovering misunderstandings during PR review or QA. It also shows how you collaborate with non-technical stakeholders like Product Managers.

The full answer

A strong answer describes a multi-step process. First, document your specific questions and assumptions directly in the PBI/ticket comments. This creates a written record and shows you've thought critically about the problem. Second, proactively engage the Product Manager (and potentially the designer or tech lead) for a brief clarification session. Don't just "throw it over the wall;" suggest a quick 15-minute huddle. Third, after the discussion, you or the PM should update the ticket with concrete, testable Acceptance Criteria (ACs). Fourth, confirm this updated understanding with the group before moving the ticket to "In Progress."

The mistakes people make

A major red flag is starting to code based on assumptions. This signals a "lone wolf" mentality and often leads to significant rework. Another weak answer is simply reassigning the ticket back to the PM with a comment like "needs more info." This is passive and doesn't drive a solution; a senior engineer is expected to facilitate the conversation. Finally, blocking the ticket and waiting for the next refinement or planning meeting is often too slow and shows a lack of urgency.

What usually comes next

"What if the PM is unavailable or unresponsive?" (A: Escalate to your engineering manager, find a proxy like a lead PM, or document your assumptions and proposed path forward for asynchronous approval). "What if you and the PM disagree on the scope or implementation?" (A: Focus on the user problem to be solved, present data and trade-offs for different approaches, and involve the tech lead or EM to help mediate a decision).

A concrete example

"A PBI said 'Improve user dashboard loading speed.' This is too vague. First, I added comments asking: What's the current loading time? What's the target? Are we focused on Time to First Byte or Largest Contentful Paint? For what user percentile (p50, p90)? I then scheduled a 15-min meeting with the PM and the front-end lead. We decided the goal was to get the dashboard's LCP from 4.1s to under 2.5s for p75 users. I updated the ticket with this specific AC, got a thumbs-up in Slack, and only then started my investigation."