Hace seis meses, tus historias de usuario cabían en fichas. Hoy, son especificaciones de tres párrafos con criterios de aceptación con viñetas y maquetas adjuntas.
Para tu equipo esto es progreso: «Estamos mejorando la ingeniería de requisitos».
Pero quizas, lo que realmente está sucediendo es que la fricción en la comunicación se está acumulando y usted la está compensando agregando texto.
Cards, Conversation, Confirmation (3Cs)
Ron Jeffries introdujo las tres C de las historias de usuario: Cards/Tarjetas, Conversación, Confirmación. La tarjeta es deliberadamente minimalista porque la transferencia de información valiosa ocurre en la conversación, no en la documentación.
Cuando puedes acercarte al dueño del producto y preguntarle: “¿Qué quisiste decir con esto?”, necesitas escribir poco. La conversación sincrónica requiere un gran ancho de banda. Aclaras ambigüedades en segundos, exploras casos extremos de forma interactiva y alcanzas un entendimiento mutuo mediante el diálogo. En comparación, el texto escrito requiere poco ancho de banda y alta latencia.
Las tarjetas pequeñas funcionan cuando la fricción en la comunicación es baja.
¿Cómo se ve la compensación?
Recientemente trabajé con un equipo cuyas historias habían evolucionado de tarjetas a especificaciones de varios párrafos en un periodo de dieciocho meses. En algún momento, implementaron reuniones de preparación del backlog (de dos horas, dos veces por semana) para gestionar la complejidad de los requisitos.
Durante la preparación, los desarrolladores pidieron ejemplos y aclaraciones. Los propietarios de producto proporcionaron respuestas detalladas. Todo se incorporó a Jira. Las historias se extendieron a varios párrafos antes de que comenzara el desarrollo. Las partes interesadas dieron su aprobación y los desarrolladores comenzaron a trabajar.
Ambas partes eran ajenas a perder la conversación.
Los desarrolladores hicieron preguntas en reuniones formales en lugar de durante el desarrollo, cuando el contexto era nuevo. Las partes interesadas adelantaron los detalles porque no estarían disponibles más tarde. Nadie habló durante el desarrollo real, cuando las preguntas surgen naturalmente y las respuestas son más importantes.
Quizás estaban mejorando en ingeniería de requisitos. Pero lo más importante es que compensaban las dificultades de comunicación con la documentación. Y la documentación no puede responder a preguntas que desconoces hasta que empiezas a construir.
Cuando la documentación sirve a la conversación
Hay que aceptar cierta fricción. Trabajé con otro equipo que se enfrentaba a la distancia geográfica entre los centros de desarrollo. El responsable del producto no podía estar disponible constantemente, y mucho menos atender ambas zonas horarias.
Centramos la documentación en transmitir las intenciones: por qué la función era importante y qué problema solucionaba. Los desarrolladores podían tomar decisiones tácticas cuando el propietario del producto no estaba disponible, ya que comprendían la intención.
Esto es apropiado: capturar el contexto cuando el ancho de banda de la conversación es realmente limitado. El texto facilita la conversación al permitir la toma de decisiones en ausencia.
Qué es inapropiado: usar la documentación como contrato porque han perdido la confianza mutua. O añadir texto porque su infraestructura de comunicación presenta fricciones que no están solucionando.
Lo que te dicen tus historias de crecimiento
Compara tus historias de usuario de hace un año con las de hoy para funciones de complejidad similar. ¿Crecieron?
Eso es fricción comunicativa que se acumula. No porque su producto sea más complejo, sino porque:
- La disponibilidad del propietario de su producto disminuyó
- Su equipo se distribuyó
- Su rotación de partes interesadas aumentó
- Tu confianza se erosionó
La fricción aumentó. Lo compensaste añadiendo texto. Y ahora te mueves más despacio, pero con mayor rigor.
No ves cómo se acumula tu propia fricción. Sientes que necesitas más detalles porque las preguntas siguen surgiendo. Dar un paso atrás puede revelar este patrón: tus historias crecen porque tu infraestructura de comunicación se está deteriorando.
Cuando la única respuesta a la fricción es “añadir más texto”, no se está resolviendo el problema de comunicación. Se está creando una ilusión de claridad mientras se ralentiza todo.
La semana que viene: cómo reducir la fricción en lugar de documentarla.
Si bien los principios que se describen aquí son sencillos, su implementación efectiva a menudo requiere una comprensión detallada de las fuentes de fricción y los patrones de comunicación específicos de su equipo. Ahí es donde el coaching basado en evidencia marca la diferencia, ayudándole a identificar dónde se acumula la fricción y si la está gestionando adecuadamente o simplemente añadiendo documentación que crea la ilusión de claridad. Contáctenos hoy mismo y hablemos sobre lo que realmente le dicen tus historias de usuario.
Discover more from The Software Coach
Subscribe to get the latest posts sent to your email.
