Estoy trabajando duro en las historias de los usuarios y está dando sus frutos, pero algo me pica.
Usamos Jira, pero el problema es que desde arriba la acumulación parece torpe.
Necesitamos escribir un resumen de la historia del usuario para que Jira pueda mostrarlo, pero esos resúmenes a veces son un poco engañosos o no son útiles para encontrar una historia en particular.
No hacemos scrum, solo usamos el backlog y el tablero kanban modificado para visualizar nuestro progreso.
Me gustaría que la acumulación (y el tablero) muestre las historias en una estructura coherente (legible) para que pueda navegar más fácilmente.
En este momento para resolver ese problema veo que yo:
No se como seguir con el punto 2.
Algunas ideas para el punto 1 hasta ahora:
Más lo pienso, creo que esa historia de usuario no tiene un resumen (?). Se originaron a partir de fichas (?) y representan una pequeña parte de un requisito.
Parecen ser tan breves como puedes conseguir.
Algunas historias de ejemplo (sea amable si tienen fallas) en el contexto de una máquina expendedora o estación de pago que ofrece la opción de pago con tarjeta.
Como cliente,
quiero que se me recuerde que mi tarjeta está en la terminal de tarjetas después de haber cancelado el pago con tarjeta,
para que no la olvide en la estación de pago.Como cliente,
quiero que se me recuerde que mi tarjeta está en la terminal de tarjetas después de haber pagado con tarjeta,
para que no la olvide en la estación de pago.Como cliente,
quiero saber si he cancelado con éxito el pago con tarjeta desde el terminal de la tarjeta,
para que no me confunda si he pagado o no.
Utilice historias de trabajo en su lugar.
Todas sus historias de usuario comienzan con 'Como cliente', por lo que está desperdiciando esa línea. Sabemos que es un cliente. Eso es un hecho.
En cambio, las historias de trabajo dicen:
Cuando... quiero... Entonces puedo...
Así por ejemplo -
Cuando cancelo un pago con tarjeta, quiero que me recuerden que mi tarjeta está en el terminal de tarjetas, para no olvidarla.
(Y luego puede agregar una línea final: 'Esta necesidad se satisface cuando...', para que sepa exactamente lo que tiene que hacer. Si lo desea).
Sería muy difícil encontrar una respuesta canónica para esta pregunta y considerando que el problema que tiene podría ser compartido por otros miembros de la comunidad, compartiré algunas ideas.
Su problema subyacente es cómo el equipo visualiza el trabajo pendiente. Independientemente de cuán detallado sea el resumen, es solo un... resumen. No debe esperar entender todo del resumen.
Trate de ver los resúmenes como "indicadores". Su equipo debe tener una sesión para revisar los principales elementos pendientes (para conocer el "contenido" real). La próxima vez que las personas miren el backlog, al leer el resumen, deberían tener una idea de qué trata cada elemento. Leer sobre el refinamiento de la cartera de pedidos podría ayudarlo.
Ahora, teniendo en cuenta sus ejemplos específicos de Historia y su uso de Jira. Si usa un tablero Scrum en lugar de un tablero Kanban, podría agrupar las historias anteriores debajo de un Epic llamado "pago con tarjeta"... y luego, en la acumulación de Scrum, podría hacer clic en este Epic en el filtro Epic a la izquierda. lado del atraso. Puedes ver un ejemplo en ESTA respuesta.
Podría aplicar la misma lógica a otros Epics, como "pago en efectivo" o incluso dejar un Epic específico para "pagos". La conclusión es que la acumulación debe ser fácil de leer y navegar.
Además, es extremadamente importante recordar que "una 'historia de usuario' no es un código fuente". Una historia de usuario es simplemente una declaración de un requisito en términos humanos. Si lo "resume", corre dos riesgos pragmáticos:
Lo modifica, consciente o inconscientemente, lo reescribe en términos del diseño o implementación del sistema de software en evolución.
Usted impone un significado, el suyo, sobre algo que, desde "la perspectiva del usuario", podría haber tenido la intención de significar otra cosa.
Su objetivo es utilizar estas historias durante el proceso de formulación de diseños e implementaciones, de modo que luego pueda comparar ese diseño con ellos para ver cómo se cumplirá el requisito establecido en esa "historia", tanto por el sistema como por el usuario hipotético que "contó la historia" cuando intenta utilizar el sistema. Si los resume (reescribe) , pierde muy rápidamente su valor previsto.
Sí, así es, si realmente está utilizando el concepto de Historias de usuario, no hay resumen. Solo el formato "Como, quiero, Así que".
Si quiere, o puede, escribir más de un resumen que eso, entonces está haciendo, o ha realizado, un trabajo de análisis que el equipo debe realizar más adelante. Ese es el enfoque purista, supongo. Incluso es una práctica bien conocida agregar criterios de aceptación a la historia, tal vez en formato pepinillo, por lo que es difícil argumentar que siempre es malo agregar más que el título. Por supuesto, los criterios de aceptación a menudo se agregan más tarde, en el refinamiento.
Creo que una vez que agrega mucho texto, diagramas o capturas de pantalla, comienza a alejarse de la esencia de una historia de usuario. Puede que eso no siempre sea algo malo, no todos los requisitos ágiles tienen que ser historias de usuario. Sin embargo, la forma en que muchos lugares usan el término Historia de usuario, con archivos adjuntos completos de palabras de varias páginas, no es realmente lo que deberíamos considerar como Historia de usuario.
En términos prácticos, en Jira podrías almacenar los criterios de aceptación en el campo de resumen.
Barnaby dorado
Todd A. Jacobs