How would you coach a developer skipping backlog refinement?

WHAT THIS TESTS: This question tests whether you understand that backlog refinement is not optional Scrum overhead but an essential activity for transparency and empiricism. The interviewer wants to see if you can coach through Scrum theory rather than authority, and whether you recognize that skipping refinement creates hidden waste that shows up later as unclear scope, slow Sprint Planning, and rework. They are also checking if you treat the Scrum Team as a collective that owns the Product Backlog together, rather than pushing refinement onto the Product Owner alone.

A GOOD ANSWER COVERS: First, meet the developer one-on-one to understand the real constraint, whether it is workload, meeting fatigue, or a belief that coding is the only value-adding activity. Second, explain how refinement creates transparency by making the Product Backlog visible and understood, which enables the team to inspect and adapt during Sprint Planning and the Sprint itself. Third, connect the behavior to concrete downstream pain, such as a three-hour Sprint Planning session, misunderstood requirements, or a missed Sprint Goal, so the developer sees the causal link rather than hearing abstract process arguments. Fourth, facilitate a Retrospective where the team inspects the current refinement process and adapts it, perhaps by changing the day, splitting it into two shorter sessions, or focusing only on the next two Sprints, so the event serves the team instead of interrupting it. Fifth, emphasize that the Developers are accountable for creating the Increment, and that accountability requires understanding the work before the Sprint starts.

COMMON WRONG ANSWERS: A major red flag is treating refinement as a mandatory calendar invite to enforce through management authority rather than empirical process control. Another is suggesting the Product Owner should refine alone while developers code, which destroys transparency and collective ownership. Saying the developer should simply be more disciplined, or that coding always trumps meetings, reveals a misunderstanding of lean thinking and the purpose of Scrum events. Similarly, proposing to cancel refinement to save time shows a lack of understanding that Scrum is designed to make waste visible so it can be reduced.

LIKELY FOLLOW-UPS: The interviewer may ask what you would do if the entire team resisted refinement, or how you would measure whether refinement is actually effective. They might probe whether you would escalate to the engineering manager or change the Sprint length to create more room. Another common follow-up is asking how you handle a Product Owner who brings unclear or overly large items to refinement, since the quality of the event depends on both sides.

ONE CONCRETE EXAMPLE: You might describe a two-week Sprint where a senior developer skipped three refinement sessions because of a critical release. During Sprint Planning the team discovered that a supposedly simple third-party integration required OAuth2 scopes that nobody had researched, causing a three-day delay and forcing them to drop a key story from the Sprint. In the Retrospective you facilitated a root-cause discussion where the team connected the delay to an opaque backlog item. The developer then proposed splitting refinement into two thirty-minute sessions mid-Sprint rather than one long Friday meeting. Attendance improved, and the next Sprint Planning finished in forty-five minutes instead of two hours.