Blocked tickets during development

‘My ticker is blocked’, says the developer at the daily standup before dragging it into the blocked column.

This happens from time to time in most teams; a wayward ticket either wasn’t refined or made it through refinement before something genuinely unexpected emerges.

“Nothing, I’m waiting on the other team,” he snaps back when asked what he will do to help unblock it. Probably feeling singled out and put on the spot.

It would be very easy to blame the individual team member for not being proactive and label them as having a bad attitude. But perhaps they are simply fed up with continually being unable to complete their work.

Suppose blocked tickets happen regularly, particularly for more than one team member. In that case, something is broken with how you manage the product backlog and refine your user stories. It should be fixed before it becomes accepted as normal.

Other signs that something is broken include unhappy users of newly released features, user stories missing alternative scenarios and acceptance criteria, user stories that are implementation-specific rather than goal-oriented, and user stories that contain too much technical detail.

Getting a handle on things becomes even more critical in remote, outsourced and offshore development teams, which often have additional challenges of language barriers, different cultures, being physically distanced from the client and working across time zones.

Preventing tickets from becoming blocked and improving developer experience is probably the same in all cases, namely well-defined user stories that have been fully refined ahead of sprint planning. Developers will become confident knowing they can implement their work, as specified and intended, within the upcoming sprint.

If you are unhappy with your development team, they may need more detailed guidance.

Better software requirements can help with this.