← Todos los artículos

¿Tu historia de usuario lleva intención? Una mirada lado a lado

By XNM Technologies · August 22, 2021 · 4 min read
¿Tu historia de usuario lleva intención? Una mirada lado a lado

Cuando los equipos pasaron al trabajo remoto en 2020 y siguieron en modo híbrido hasta 2021, un problema silencioso afloró en muchos backlogs. Con menos conversaciones de pasillo para tapar los huecos, las palabras de la tarjeta tenían que hacer más. Una historia de usuario que antes sobrevivía porque alguien podía preguntar al de al lado, ahora se atascaba porque nadie sabía qué significaba realmente. La solución no es más ceremonia. Es escribir historias que lleven intención.

Scrum en sí dice muy poco sobre cómo escribir un elemento del Backlog del Producto. La Guía Scrum deja el formato a elección del equipo. Las historias de usuario son simplemente la convención más popular, y la plantilla habitual — como [rol], quiero [capacidad], para [resultado] — solo es útil cuando la tercera cláusula es honesta. Quita el «para» y te queda una petición de funcionalidad disfrazada de agilidad.

Cómo se ve una historia débil

Las historias débiles describen la interfaz, no la necesidad. Cuelan la solución dentro del requisito, así que el equipo construye exactamente lo escrito y descubre demasiado tarde que no resolvió nada. Suelen compartir algunos rasgos.

  • «Como usuario, quiero un menú desplegable de provincias.» — Un control, no una meta. ¿Por qué el usuario necesita elegir una provincia?

  • «Como administrador, quiero un informe.» — Sin resultado, sin alcance. ¿Qué decisión respalda este informe?

  • «Como cliente, quiero que el sistema sea rápido.» — Necesidad real, pero no comprobable. ¿Rápido comparado con qué, medido cómo?

  • Una historia tan grande que nunca termina dentro de un Sprint, que se arrastra por tres y bloquea todo lo que viene detrás.

Cómo se ve una historia sólida

Una historia sólida nombra a una persona, una capacidad y el resultado que hace que esa capacidad valga la pena — y luego deja espacio para que el equipo decida cómo. Es lo bastante pequeña para terminarse y trae criterios de aceptación que indican cuándo está hecha.

  1. Declara un resultado real. «Como supervisor de obra, quiero marcar una entrega como incompleta para que compras reclame al proveedor antes del próximo vaciado.» El «para que» es comprobable y está ligado a una decisión.

  2. Es independiente y negociable. La tarjeta abre una conversación en lugar de cerrarla. El supervisor y el desarrollador aún pueden discutir si una marca, una foto o un campo de cantidad sirve mejor a la meta.

  3. Es pequeña y verificable. Cabe en un Sprint y lleva criterios de aceptación — «la marca aparece en el panel de compras en una actualización» — de modo que «hecho» no es cuestión de opinión.

  4. Sobrevive sin su autor en la sala. Un compañero remoto a tres husos horarios puede leerla en frío y construir lo correcto. Esa es la verdadera prueba de la intención.

Observa que el ejemplo sólido salió del mundo de la cadena de suministro de 2021 : entregas incompletas, vaciados perdidos, proveedores a los que reclamar. La historia llevaba intención porque describía lo que alguien intentaba lograr, no qué control mostrar. Mantén el porqué a la vista y el resto de la conversación sobre el backlog se vuelve más fácil : estimación, división y priorización se apoyan en una meta que el equipo puede ver de verdad.

Una prueba rápida antes del refinamiento

Antes de meter una historia en un Sprint, pásala por dos preguntas. Primera, ¿puedes enunciar el resultado sin nombrar una pantalla, un botón o una tabla de base de datos? Si no puedes, tienes una solución, no una necesidad, y has cerrado la puerta a las mejores ideas que el equipo podría haber aportado. Segunda, ¿un desarrollador que nunca conoció a quien lo pidió construiría lo correcto solo con la tarjeta? Si la respuesta honesta es no, la intención vive en la cabeza de alguien, no en la tarjeta — y en un equipo distribuido, esa cabeza puede estar desconectada cuando empieza el trabajo.

Nada de esto exige un proceso más pesado. Una buena historia suele ser más corta que una mala, porque deja de describir la interfaz y empieza a nombrar la meta. Los criterios de aceptación hacen el trabajo de precisión; la historia en sí solo tiene que dejar el propósito fuera de toda duda. Cuando la intención está en la tarjeta, el refinamiento se vuelve una conversación sobre la mejor solución en lugar de una excavación arqueológica de lo que quien lo pidió quería decir realmente.

Si tu backlog está lleno de pantallas en lugar de resultados, la asesoría en ejecución de programas y proyectos de XNM puede ayudar a tus equipos a escribir requisitos que lleven intención y sobrevivan al traspaso.