En un proyecto Agile, ¿cómo organizas una gran acumulación (cientos de historias de usuarios / epopeyas)?

He sido gerente de producto durante aproximadamente 20 años (probablemente 5 años antes de que se convirtiera en una disciplina real como la conocemos hoy), y ahora soy vicepresidente de producto en un inicio de SAAS. He trabajado en productos MUY diferentes durante toda mi carrera. Decodificadores de TV, sitios web, plataformas de video, juegos en la nube, eficiencia ambiental … Agile puede funcionar para cualquier cosa de la que esté convencido, pero debe ajustarse ligeramente según el tamaño del producto o la línea de productos que está entregando, y en qué etapa se encuentra. PERO aquí hay algunas reglas prácticas para ajustar esa última milla.

Decida sus tamaños estándar de puntos de historia épica / historia o los plazos de entrega. Tendemos a tener:

• Temas: estrategias o cosas que tardan aproximadamente medio año en desarrollarse.
• Las epopeyas tienden a estar en cuartos como máximo
• Las historias tienen que limitarse a una semana. Esa es la regla más estricta que tenemos (así como Def de Done en cada boleto)

Los temas representan los elementos grandes que salen de las reuniones externas o de la junta directiva de Exec … Los temas son las contribuciones de los equipos de Producto (Prod Mgrs, Eng, Design) a esas estrategias / tácticas. Realmente recomiendo no tener más de 2 o 3 temas por táctica, de lo contrario recibirá la queja “Demasiados detalles” de los ejecutivos en los informes de progreso.

Nos centramos estrictamente en el valor del cliente al nombrar cualquier cosa desde este punto. Al igual que con cualquier cosa ágil, a veces es más fácil mostrar un ejemplo …

• Estrategia de los ejecutivos: “Ejecutar un negocio más eficiente” (generalmente tengo que presionarlos para que lo conviertan en algo tan sucinto)
• Táctica corporativa 1: “Reducir el margen bruto corporativo”
• Tema 1: “Haga que la“ experiencia de configuración ”sea más intuitiva para que podamos controlar los costos de implementación”
• Tema 2: “Ventas de autoservicio para renovaciones”

Del tema 1:

• Epic 1: “Mejore la experiencia de” Comenzar “para que el cliente esté totalmente orientado”
• Epic 2: “Haga que la solución de problemas sea más intuitiva para que recibamos menos llamadas de servicio al cliente”
• Epic 3: “Crear un sistema de implementación continua para que podamos distribuir las tareas de lanzamiento en todo el equipo v1”

Aquí hay historias para Epic 1:

• Historia 1: Como representante de marketing, necesito una manera fácil de crear, editar o probar el contenido de nuestro correo electrónico de bienvenida (Mini-CMS para el mecanismo de presentación de diapositivas tutorial desarrollado)
• Historia 2: Como uso final, me gustaría obtener una visión general muy rápida del sistema lo antes posible, así que me siento orientado y entiendo los próximos pasos generales. (Crear prueba de presentación de diapositivas del tutorial)
• Historia 3: Spike: Definir “Definición de hecho” para la implementación continua

Escale la cantidad de historias en un Sprint en función de las personas que tiene.

TAN LEJOS COMO MANTENER LAS COSAS DE OBTENER SABIDURAS LOCO (utilizamos Jira, pero esta jerarquía probablemente debería funcionar en otras herramientas).

Tenemos 2 proyectos principales: DESCUBRIMIENTO y [Nuestro nombre de producto SAAS grande que llamaré “POD”]

El proyecto POD es nuestra línea de productos esencialmente. Sigue la regla general arriba

DISCOVERY es nuestra versión de “Top of Funnel” de Sales. Cualquiera puede entrar y agregar algo. Programas de la Voz del Cliente … Éxito del Cliente … Ejecutivos borrachos a las 3 de la madrugada. Yo ‘jardineo’ esa lista al agrupar las cosas en épicas cuando necesito desconectarme durante unos minutos en el trabajo. Las epopeyas parecen ser del tamaño de un tema en este proyecto, las historias son más épicas. My Definition of Done for DISCOVERY tickets básicamente define lo que sea necesario para ingresar al POD y contiene muchas cosas de tipo de proyecto. Cosas como:

• Cree una lista épica básica para POD (las que no tienen cerebro)
• Obtenga un diagrama de flujo de datos del sistema (si es necesario)
• Cree versiones de tema (para cuando se dé cuenta de que esto se extenderá durante los últimos 6 meses)
• Las secciones relevantes de Lean Canvas completan “Problemas – Mapa de características” “Diferenciación” “Ventaja única”
• Maquetas de diseño de nivel superior (para impulsar mejores discusiones con todos) (si es necesario)

Me reúno con el CEO como una vez al mes para revisar la clasificación de los artículos en los que pasamos tiempo. Gradúo algo en POD y lo marco como Hecho en Discovery.

Espero que al menos una persona encuentre esto útil (¡o incluso lo lea!)

Como otros han dicho, la jerarquía es la clave. Independientemente de las etiquetas que coloque en los niveles (usamos historia / función / épico / tema), use una herramienta de administración que permita el gusto de padres / hijos.

Entiendo que sientes que tus más de cien historias son el alcance de tu producto. También sé que te equivocas. Habrá cambios en ese alcance antes de completar las 100 historias.

Que haría yo:

• Organice las historias en “características”: agrupaciones funcionalmente relacionadas. Probablemente también tengas algunas historias atípicas. Esta bien. Si hay valor, haz otro nivel más alto.
• Usted y sus expertos (miembros experimentados del equipo) estiman las características. Así es: mira los grupos de historias en su conjunto y elabora una estimación. Puede usar puntos de historia, días ideales para desarrolladores, tamaños de camisetas o cualquier otra cosa, siempre y cuando no use horas. No hay forma de estimar en horas con precisión en este nivel. Use la secuencia de Fibonacci de modo que cuanto mayor sea la característica, mayor será la estimación forzada a ser. Esto se debe a que cuanto más grande es, más incógnitas hay. Es un acolchado incorporado si lo desea. Y no, hacer que su equipo calcule todas esas historias en puntos de historia y sumar no es una buena idea.
• Priorizar las características. ¿Qué necesita que sus partes interesadas vean primero? ¿Segundo? Si es una combinación de varias características, considere la posibilidad de reorganizar. O planifique pasar por dos o más funciones antes de invitar a las partes interesadas a una demostración completa.
• Ahora priorice las historias dentro de sus principales características.
• Ahora haga que todo su equipo calcule las primeras historias, lo suficiente como para completar un sprint o dos, no más. ¿Por qué? Porque las estimaciones tienen una vida media corta. Después de un sprint, el equipo sabrá más sobre el producto y entre sí. Sus estimaciones cambiarán. Ningún equipo debe aceptar en un sprint un elemento que se estimó más de dos sprints atrás.

La gestión de la reserva es un proceso continuo, por lo que volverá a pensar la jerarquía de la historia / característica, agregará historias y las eliminará y, muy probablemente, empaquetará los errores que se encuentran a medida que avanza.

Además, he asumido que sus historias ya están bien descompuestas y que tiene criterios de aceptación sólidos. Pero probablemente ese no sea el caso, y analizará, revisará y desarrollará los requisitos posteriores a medida que avanza.

¡Buena suerte!

Me gusta la sugerencia de que no deberías meterte en una situación de gestión de una cartera de pedidos tan grande en primer lugar como otros han sugerido. También para construir una cartera de pedidos, practique la estructura jerárquica según lo sugerido por los demás en este hilo.

Sin embargo, lo único que me gustaría agregar a sus respuestas es la práctica de “Acumulación de pedidos pendientes”. En mi proyecto, todas las semanas, me sentaba con el desarrollador principal y revisaba las historias en la cartera de pedidos priorizando los elementos de manera adecuada y también eliminaba los elementos de la cartera de pedidos que eran demasiado viejos para importar.

Esto aseguró que si bien nuestro registro de respaldo puede haber sido largo, siempre nos enfocamos en los elementos más importantes y “relevantes” en cada ciclo de sprint.

En resumen, elimine regularmente la piel muerta del trabajo atrasado. No lo lleves contigo.

Cubra esas historias y epopeyas de los usuarios con las tareas clave del trabajo del usuario (como se describe en la descripción de su trabajo). Una vez que tenga esas 100 historias de usuarios divididas en 6–8 categorías, podrá establecer prioridades más fácilmente. Determine qué tareas laborales tienen el mayor impacto en el éxito de la función laboral del usuario y las historias se priorizarán.

Antonio de la Torre, (Antonio de la Torre – Google+) es un entrenador ágil en http://taiga.io & nbsp ; Él publica aquí (Historias EPIC) sobre qué es exactamente una historia EPIC, y qué no es … Quizás esto ayude …