Anything that stops the delivery of a product, or acts as a hurdle for the product can be termed as a blocker. A blocker might be an issue or bug which you have come across during development or testing and which is not allowing you to develop or test further. Blockers are also known as impediments in Scrum, and issues in more traditional project management approaches. A blocker doesn’t necessarily have to be a complete show stopper. Drag factors are also another form of blocker, that it, things that are slowing the team (or individual) down but not stopping them entirely. Common examples of blockers that teams face on a regular basis are: technical environment issues, too much multi-tasking or task switching, changing priorities, bad story slicing, dependencies on 3rd parties, dependencies on other teams, technical debt, too many meetings or distractions, unfamiliar tools or technology, vagueness of stories, rework, too much work in progress, hidden complexity. Blockers can manifest themselves at any time and in most cases, pretty much everything gets blocked at some point in the software development life cycle. Techniques such as Kanban focus on removing the blockers rather than parking the blocked item and starting some other work. In Kanban, blockers are normally visualised on a physical card wall using magenta (or neon pink) post-it notes. When this technique is used it’s important to clearly state the reason for the blocker on the post-it note. This enables management to understand the common causes of delay for teams and assist with the removal of impediments. Blockers are normally systemic issues beyond the remit of the team. Another Kanban technique is to store the unblocked blocker post-it in an envelope at the end of the board. This provides a store of blockers so that every two weeks or so the team can layout all their past blockers and cluster them according to patterns they spot. The team can then focus on taking action to resolve the root cause of the blocker.