Una de las cosas para la que nos hemos retirado a Miravet es tener tiempo para revisar técnicas, descubrir su funcionamiento interno y adaptarlo a nuestros valores y habilidades. Nos preocupa mucho el uso de las técnicas basado sólo en la actividad o en su dinámica sin entender demasiado bien el porqué de cada cosa. Seguir el dogma, la receta.
En la primera de estas sesiones ha tocado Story Mapping. Así que, pertrechados de los artículos y diapositivas de Jeff Patton, repasamos y cuestionamos cada uno de los pasos.
La primera conclusión fue hacer la colección de personas antes de comenzar la actividad. En la ficha de persona decidimos evitar etiquetas como rol o tipo de usuario porque nos parecen restricciones que estereotipan más de lo necesario. Pasamos un buen rato reflexionando sobre el nivel de ambigüedad ideal para cada tramo de un proyecto. También estuvimos de acuerdo en iconizar con distintivos o colores a cada persona para marcar las historias de usuario en las que están involucradas.
Lo siguiente fue la creación de lo que llamamos el contexto. Su objetivo es almacenar restricciones que aplican a todo el producto como podría ser el framework, el lenguaje o una norma que cubrir. Evitando generar historias de usuario raras y roles tóxicos. Así, cuando aparece alguna de estas restricciones, la metemos en el contexto, liberándonos de esa preocupación y pudiendo enfocar mejor en el diseño del producto.
Para hacer el Backbone nos fijamos en los usos del sistema por parte de las personas que hemos definido previamente. Pero al desplegarlos en el eje horizontal, no vimos claro porqué la dimensión tenía que ser siempre el tiempo. Creemos que esa dimensión debe ser acorde al proyecto. Por ejemplo, mapeando un producto de software lo distribuimos en horizontal en relación a su proximidad en el dominio, pero para un proyecto de formación lo haríamos en función de las secciones temáticas.
Seguimos la técnica propuesta para dividir las épicas en historias de usuario más pequeñas y aceptamos el eje vertical como prioridad, pero entendiéndola como un cómputo de los factores que afectan al producto. En el curso de formación que usamos como ejemplo, la dimensión vertical sería la relación entre nivel de contenido, duración del delivery, aplicabilidad del tema, etc. En estas fases, los criterios falsamente objetivos como coste, duración de una tarea, story points… lastran la exploración. Ya habrá tiempo de tenerlos en cuenta cuando el producto haya madurado un poco más.
Una vez mapeado detectamos el Walking Skeleton, que es el conjunto mínimo de historias de usuario que satisfacen los usos básicos del sistema. A partir de él vamos añadiendo funcionalidades o contenido para diseñar sus evoluciones. En nuestro curso de ejemplo, el Walking Skeleton era una charla y sus hermanos mayores dos cursos de 8 y 20 horas.
Vemos Story Mapping como una de las actividades más útiles para definición de producto y captura de un primer backlog. No lo vemos como una técnica de planificación para obtener un release plan muy formalizado, aunque sí nos da algunas pistas. Es más útil para localizar el Walking Skeleton, tener un backlog inicial y detectar el MVP del proyecto. Por lo que es un ejercicio ideal para hacer después de una incepción. Y no olvidemos que tanto el backlog como el release plan resultante estaría en un estado inicial sobre el que se debe seguir trabajando continuamente.
Story Mapping es una interesante herramienta de análisis con la que podemos remapear el resultado inicial cambiando las dimensiones de los ejes. Si además hemos etiquetado debidamente, podremos volver a componer siempre todos y cada uno de los mapas que generemos.
Durante nuestro viaje vamos ofreceremos sesiones de cuatro horas de Story Mapping que creemos pueden aportar mucho si necesitas un primer backlog, has hecho una incepción y quieres comenzar con el desarrollo o si ya tienes un producto y quieres reevaluar su enfoque.
¿Y tú? ¿Nos cuentas cómo lo haces? ;)