A crusher is simply a rock used to help refine other rocks. This special rock makes visible the learning activities that are present in the backlog refinement process.
First and foremost, a crusher is a rock, and just like any other rock, a crusher has an intent—which, in this case, is learning the knowledge necessary for further rock refinement. That learning results in a testable, verifiable model, such as a customer journey that can be demonstrated. Accepted crushers are presented at the iteration review, just like all other work accepted by the backlog owner.
Unlike other rocks, when the backlog owner accepts a crusher’s verifiable model, it does not become a solution increment. Rather, the accepted verifiable model represents what was learned about the rock we are trying to refine. The crusher creates economic value by reducing the risk of building the wrong thing and aligning the team on the ultimate solution. The crusher also represents work performed by members of the team, and it may have a cost in terms of team capacity.
Crushers are similar to what many developers call a “spike”—a timeboxed story that answers a question. We chose the term crusher for two reasons: First, it fits our rock crushing metaphor. Second, and more importantly, the “spike” term is well entrenched in the agile community and usually refers to a technical exploration story. We want to broaden the scope of the learning to include the analysis and design processes.