¿Cómo dividir una historia de usuario que abarca múltiples sprints?

Tengo una historia de usuario que contiene un montón de tareas, similar a esta:

Historia de usuario: repare cualquier JavaScript roto en CMS

  • Tarea: encontrar y corregir JavaScript roto en el contenido
  • Tarea: encontrar y reparar JavaScript roto en la base del código
  • Tarea: encontrar y reparar JavaScript roto en archivos estáticos
  • Tarea: encontrar y reparar JavaScript roto en la biblioteca
  • Tarea: encontrar y corregir JavaScript roto en archivos de catálogo

Así que tengo un montón de tareas para revisar algunos códigos y archivos y arreglar algunos JavaScript. Digamos que no puedo completar todas las tareas anteriores en un sprint de 2 semanas.

¿Cómo divido esto en varias historias? Las tareas se pueden completar en cualquier orden y no dependen unas de otras en absoluto. Por lo tanto, no hay una forma lógica de subagruparlos. ¿Simplemente haría:

Historia de usuario: Corrija cualquier JavaScript roto en CMS (parte 1)

y

Historia de usuario: Corrija cualquier JavaScript roto en CMS (parte 2)

Eso parece una mala manera de manejar esto. ¿Cuál es un mejor enfoque para este tipo de problema en el que las tareas no se pueden agrupar mejor pero aún necesita dividir la historia?

Una sola historia de usuario nunca debe exceder un solo Sprint. Vea la respuesta más completa a continuación.
para ser bastante pedante, estas no parecen ser historias de usuarios; generalmente, una historia de usuario sigue el formato de: mountaingoatsoftware.com/agile/user-stories Como <tipo de usuario>, quiero <algún objetivo> para que < alguna razón>.
¿Por qué sus usuarios quieren arreglar cualquier JavaScript roto en CMS?
Para resumir: plataforma de comercio electrónico a gran escala donde partes de JS de una sola página se colocan a través de un CMS, ya que no requiere una liberación de código. Pero eso es solo un ejemplo.

Respuestas (3)

Use INVEST para la definición y el tamaño de la historia

Está luchando por descomponer su trabajo porque sus historias no siguen la regla nemotécnica INVEST . En particular, las tareas que ha enumerado no se pueden probar. ¿Cómo podría saber si completó con éxito "[f]encuentra y corrige JavaScript roto en archivos de catálogo" o estima la cantidad de trabajo involucrada?

Al igual que el desarrollo basado en pruebas en general, las mejores historias de usuario deben describir el comportamiento . Por ejemplo:

Como usuario,
espero que el JavaScript en la página del catálogo me respalde
para que me moleste y sea menos productivo.

Ahora está claro en qué necesita trabajar el desarrollador y (lo que es más importante) cómo validar ese trabajo. Ha descrito el comportamiento comprobable en lugar de agitar a mano el alcance, el comportamiento esperado y los criterios de éxito comprobables.

Aglomeración de artículos relacionados

Las historias deben ser granulares, pero no ridículamente. Si tiene muchas correcciones relacionadas, puede agruparlas . Por ejemplo:

Como desarrollador web,
quiero corregir la lógica de rickroll.js en las 27 vistas
para poder irritar a todos los clientes independientemente de la página de entrada.

Nuevamente, esto define un comportamiento comprobable, tiene un alcance claro y medible y proporciona suficiente contexto para permitir que el equipo calcule el trabajo involucrado. Si debe tener historias individuales o agruparlas, variará según la capacidad del equipo y el tamaño de la historia, ¡pero al menos ahora tiene opciones!

Como desarrollador, creo que las historias que comienzan con "Como desarrollador yo..." no tienen sentido. El objetivo de una historia de usuario es comprender el trabajo desde la perspectiva del usuario. De lo contrario, también podría registrar qué trabajo debe realizarse en términos simples.
@GlenThomas A pesar del nombre, el formato de historia de usuario espera que se defina un consumidor de valor , no necesariamente un usuario final. Si tiene alguna pregunta sobre esto, abra otra pregunta ya que los comentarios no son para una discusión extensa.
Uso de comentarios definido por StackExchange: "Utilice comentarios para solicitar más información o sugerir mejoras". Estoy sugiriendo mejoras a su respuesta. No tengo ninguna pregunta que hacer. Definición de historia de usuario: "Las historias de usuario son descripciones breves y sencillas de una característica contada desde la perspectiva de la persona que desea la nueva capacidad, generalmente un usuario o cliente del sistema".
@GlenThomas Su cita con respecto al punto de vista de una historia dice que el rol debe ser (énfasis mío): "la persona que desea la nueva capacidad , [que es] generalmente un usuario o cliente del sistema". No hay absolutamente ningún requisito de que el consumidor de valor sea un usuario final. Está malinterpretando el formato y el propósito de la definición de roles en una historia de usuario. En resumen, su comentario original es objetivamente incorrecto, aunque es un malentendido común debido a la frecuencia con la que las historias de usuarios mal escritas atribuyen erróneamente el valor del consumidor.

En lugar de 'cualquiera', usaría un número exacto, o lo mejor sería hacer una investigación en el sprint 1, crear problemas para cada problema que haya encontrado y resolver los problemas específicos en los próximos sprints.

Mi problema con la configuración actual es que no es específica en absoluto. Probablemente significarán cosas diferentes para dos personas diferentes en su organización.

¿Qué pasa si la investigación y el paso de crear más tareas para cada problema lleva más tiempo que hacer la tarea en sí? Eso parece ineficiente.
Por ejemplo, digamos que para una tarea anterior, investigo y encuentro 100 lugares donde se debe corregir el código. Pero el tiempo que lleva hacer esas 100 correcciones de código lleva menos tiempo que investigar y luego crear 100 tareas individuales.
Estoy siguiendo la regla de los 10 minutos: si pienso hacerlo en 10 minutos, lo haré, de lo contrario crearé un problema.

Personalmente, mi enfoque sería hacer frente a la deuda técnica en función de la funcionalidad de la aplicación.

Por ejemplo, corrija JavaScript roto (todas las categorías) en las páginas de registro. Luego pruébelo (incluidas las pruebas de regresión) y luego pase a la siguiente área funcional.

Probablemente encontrará que las primeras áreas funcionales involucran la mayor parte del trabajo y luego, a medida que avanza en gran parte del JavaScript subyacente, habrá sido corregido por historias anteriores.

¿Cómo dividir una historia de usuario que abarca múltiples sprints?
RespuestasAquíPolítica de privacidad1y, 3v