A crusher is simply a rock used to help refine other rocks. This special rock makes visible the learning activities which are present in the backlog refinement process.
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 a crusher’s verifiable model is accepted by the backlog owner, 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 [1] 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.
replaced “individuals” with “the team”