Escribir historias de usuario que transmitan intención, no solo tareas
Si has pasado tiempo cerca de Scrum, conoces el formato: «Como usuario, quiero un botón, para poder pulsarlo». Marca las casillas y no enseña nada. Una historia de usuario debe transmitir intención —la razón humana detrás de una solicitud— hasta el trabajo, para que un desarrollador que toma cien pequeñas decisiones las tome en la dirección correcta. Cuando falta la intención, el equipo construye exactamente lo escrito y aun así se equivoca de objetivo.
La Guía de Scrum en realidad no exige historias de usuario. Habla de elementos de la Pila de Producto y de la Pila de Producto en sí. Las historias de usuario son una técnica popular para expresar esos elementos, no una regla. Esa distinción importa: la meta es una pila que los Desarrolladores entiendan y que el Product Owner pueda ordenar por valor; el formato de historia solo es una forma fiable de llegar allí.
Las tres partes que importan
Una historia útil responde a tres preguntas. ¿Para quién es? ¿Qué quiere poder hacer? ¿Y por qué le importa? La clásica plantilla «Como / quiero / para» existe para forzar la tercera pregunta, la que los equipos suelen dejar caer. En el «para» reside el valor. Una historia sin él es una tarea disfrazada.
Mira la diferencia. «Como jefe de obra, quiero exportar el registro diario en PDF» es una tarea. «Como jefe de obra, quiero exportar el registro diario en PDF, para poder entregar a los inspectores un expediente sin darles acceso al sistema» le dice al equipo cómo es el éxito y abre mejores soluciones. Quizá la verdadera necesidad sea un enlace de solo lectura, y no un PDF en absoluto.
Cómo escribir historias que aguanten
Anclala a una persona real. Nombra el rol concreto, no un vago «usuario». Un responsable de compras y un trabajador de primera línea quieren cosas distintas; la historia debe decir cuál.
Empieza por el resultado, no por la pantalla. Describe qué necesita lograr la persona, dejando margen para que el equipo encuentre la mejor manera de entregarlo. Prescribir la interfaz demasiado pronto desperdicia su experiencia.
Añade criterios de aceptación, no un diseño. Enumera las condiciones que dan por terminada la historia: las comprobaciones que un revisor puede confirmar. Convierten el «para» en algo verificable sin dictar la implementación.
Mantenla lo bastante pequeña para terminarla. Si una historia no puede completarse de forma plausible dentro de un Sprint, divídela según el valor que entrega, no según las capas técnicas. Dos rebanadas finas que funcionan valen más que una gruesa que funciona a medias.
Refínala en equipo. El refinamiento de la pila es cuando el equipo pregunta y el Product Owner aclara. Una historia es el inicio de una conversación, no un contrato impuesto desde arriba.
Señales de que una historia perdió su intención
Cada historia nombra al mismo «usuario» genérico, de modo que nadie puede imaginar a quién afecta realmente.
La cláusula «para» repite el «quiero» —«para poder exportar»—, lo que añade palabras pero ninguna razón.
La historia especifica botones, campos y diseños, dejando al equipo teclear en lugar de pensar.
Es demasiado grande para terminarla en un Sprint y sigue rodando hacia adelante sin tocarse.
En 2022, con equipos repartidos entre casa y oficina y presupuestos apretados por el alza de costos, el costo de construir lo equivocado es más alto que nunca. Una historia de usuario que transmite intención es un seguro barato: permite que un desarrollador solo a las nueve de la noche tome la misma decisión que habría tomado el Product Owner. Ese es todo el sentido de ponerla por escrito.
Si tu equipo quiere pilas de producto que impulsen valor en vez de solo listar tareas, la asesoría de XNM en entrega de programas y proyectos puede ayudarte a afinar cómo se plantea el trabajo.