Tengo dificultades para crear una buena visualización/seguimiento para mi proyecto de scrum y, por lo tanto, estoy considerando varias alternativas. Un concepto interesante es Story Mapping. ¿Tiene alguna información sobre el uso de un mapa de historia en lugar de una acumulación de trabajo plana?¿Mapa de historia o backlog plano?
Como siempre con Scrum, haga lo mínimo que crea que necesita. Demasiada documentación puede ser imposible de mantener y solo te atará.
Dicho esto: en un rol anterior donde teníamos alrededor de 15 equipos de Scrum, teníamos una "sala de guerra" donde las historias estaban mapeadas en una pizarra de pared.
La mayoría de estas historias eran "épicas", ya que se suponía que los equipos individuales de Scrum las dividirían en historias más pequeñas y manejables más adelante.
Inicialmente, no se asignaron estimaciones de tiempo a estas epopeyas, ya que el objetivo del mapa era identificar las dependencias entre las épicas y tener una idea aproximada de qué equipo estaría mejor situado para hacer qué épica.
En las siguientes iteraciones calculamos las estimaciones de tiempo y comenzamos a detallar dónde se ubicarían en la acumulación de trabajo de cada equipo. Esto condujo a un cierto revuelo de las historias, pero en general la conjetura inicial era correcta.
Por dos o tres sprints después de que comenzamos la "sala de guerra" se volvió más difícil de mantener, así que volvimos en ese punto a una hoja de cálculo de Excel con las epopeyas enumeradas secuencialmente. Sin embargo, en ese momento los propietarios y clientes del producto habían internalizado el plan del proyecto por lo que no había necesidad de mantenerlo.
Como se describe en el artículo que vinculó el concepto de Story Mapping fue el resultado de cambiar algo que no funcionó bien para ellos. Todos los equipos son diferentes y lo mejor que puedes hacer (en mi opinión) es elegir una cosa que tu (el equipo) cree que parece prometedora y probarla para un sprint y hablar de ello nuevamente en la próxima retrospectiva. Haga los ajustes necesarios, intente algunos más y vuelva a visitarlos en la retrospectiva, y así sucesivamente.
cierto. Tenía la esperanza de obtener algunos comentarios de los demás antes de seguir adelante con el concepto. –
El mapeo de historias es una gran técnica de planificación, pero yo no usaría el mapa de historias para el seguimiento. Utilizaría las características/escenarios identificados en el mapa como cubos de funcionalidad, y usaría cuadros de estacionamiento para mostrar el progreso de cada característica. Una buena idea es identificar la funcionalidad mínima necesaria para enviar cada característica (por supuesto, esas deberían ser las historias de mayor prioridad para esa función), y poner una línea en el gráfico de estacionamiento para cada característica que muestra cuando esa cantidad mínima de funcionalidad ha sido implementado. Esta es una forma clara de mostrar exactamente dónde está el producto a las partes interesadas externas.
Tobias aquí hay otras dos perspectivas sobre el mapeo de historias: John Walpole of Twitter shares their experience with story maps y también escribí un primer on story mapping.
Estoy votando para cerrar esta pregunta como fuera de tema porque no se trata de programación. –