El propósito es evitar el trabajo innecesario al obligar al usuario / cliente a proporcionar un beneficio comercial sólido y tangible como una razón para la existencia de esta característica.
No es extraño que se agreguen características solo porque alguien pensó que sonaba genial, o porque otro software lo tiene, por lo que el nuestro también debe tenerlo. Más a menudo que no, esos son al menos completamente innecesarios, si no activamente dañinos.
Sin embargo, generalmente es fácil detectar esas características, porque las personas que las proponen generalmente tendrán problemas para proporcionarles una razón comercial convincente.
Hay una técnica llamada Popping The Why Stack , en la que tomas la parte "de modo que" y preguntas "¿Por qué?", Luego tomas esa respuesta y preguntas "¿Por qué?" de nuevo, recursivamente. Si, después (digamos) de tres a cinco "Por qué", no ha llegado a "porque nos hará ganar dinero" o "porque nos ahorrará dinero" (preferiblemente con una descripción precisa de cómo exactamente eso va a suceder), entonces no vale la pena implementar la característica.
Algunas personas creen que esto es tan importante que realmente lo ponen primero en la plantilla de la historia:
A fin de que [...]
Como un [...]
Quiero [...]
Hay un gran ejemplo de una charla de algunas personas de Thoughtworks: uno de sus clientes quería que los informes impresos formateados de una manera muy peculiar. Cuando el consultor preguntó "Por qué", dijeron que de esa forma eran más fáciles de volver a escribir. Entonces, en lugar de implementar la función de formateo de informes, simplemente transfirieron los informes a través de la red. Sin la cláusula "para que", todavía estarían imprimiendo esos papeles en un departamento, enviándolos por correo al otro departamento y volviéndolos a escribir.