Me parecía un valor seguro hacerme con Fifty Quick Ideas to Improve your User Stories de Gojko Adzic y David Evans. Venía siguiendo los artículos del blog de Gojko Adzic (de hecho algunas de esas ideas ya están desarrolladas ahí) a raíz de leer Specification By Example y además tenía buenas referencias del libro. Desde luego que no me defraudó.
Tal y cómo está escrito existe una idea por capítulo que contiene la descripción, los beneficios clave y algunas recetas sobre cómo llevarla a cabo; teniendo en algunos casos referencias a otros libros y artículos donde profundizar más sobre esa idea. El formato está genial para revisitar de vez en cuando alguna de las ideas y llevarlas al día a día.
Creo que quienes más partido le pueden sacar a este libro son las personas con roles tipo product manager/owner o que tengan influencia sobre cómo se gestiona el producto y los stakeholders en una organización. Pero es muy interesante para cualquiera que se dedique a la creación de productos de software con cierto recorrido profesional e interés en profundizar sobre la gestión de producto.
Y hablo de cierto recorrido profesional porque no es un libro introductorio donde expliquen qué son las historias de usuario, si es mejor una u otra plantilla y cosas así.
Mientras lo leía estuve marcando lo que me parecieron los principales puntos de cada idea y al terminarlo, como ejercicio de repaso, decidí empezar a traducir esos extractos. Me pareció que sería interesante compartirlo, así que pedí permiso a Gojko para hacerlo.
Estas ideas están agrupadas en cinco bloques:
- Creando historias
- Planificando con historias
- Discutiendo historias
- Partiendo historias
- Gestionando la entrega iterativa
Creando historias
Cuenta historias, no las escribas
Usar historias de usuario implica un modelo completamente diferente, es definir requisitos de forma colaborativa.
No te preocupes demasiado por el formato de historia
Experimenta con el formato:
- Nombra las historias rápido, añadiendo los detalles después.
- Evita caer en escribir soluciones obvias.
- Piensa en más de un stakeholder interesado en el ítem, esto abre opciones de partir la historia.
- Utiliza imágenes en vez de palabras.
- Haz una pregunta.
Describe un cambio de comportamiento
Las iniciativas que aportan valor producen cambios observables en la forma de trabajar de alguien. Capturar ese cambio de comportamiento hace una historia medible desde un punto de vista de negocio y eso simpre abre una buena discusión.
Describe un cambio del sistema
La descripción de la historia debería aclarar exactamente cómo cambia el sistema o las reglas de negocio del momento actual y en el que la historia esté implementada. También necesitamos saber cuánto difiere del comportamiento actual. Empieza la discusión añadiendo otra cláusula a la plantilla de las historias (“Where as…”, “Instead of…”), debería aclarar lo más posible el contraste de lo que hay con lo que es necesario.
Enfoca las historias como experimentos que sobreviven
Las preguntas clave para el tamaño de la historia no deberían ser sobre la duración de la iteración, sino acerca de cuánto quieren invertir los stakeholders de negocio en saber si el cambio propuesto retornará lo que asumieron invertir. Enfocando las historias como experimentos podemos cambiar el enfoque desde la complejidad técnica hacia los outcomes (o resultados esperados) y el aprendizaje.
Diseña experimentos en torno a suposiciones y conviértelos en historias de usuario.
Cuidado con los roles genéricos
Evita “As an user…” como la peste. Una descripción clara y precisa de roles de usuario ayuda a identificar necesidades y eliminar complejidad innecesaria. Esto también ayuda a mejorar la gestión de los proyectos y la estrategia de planificación.
Evalúa la zona de control y la esfera de influencia
Hay tres áreas de sistemas diferentes:
- La zona de control incluye todas las cosas en un sistema que podemos cambiar nosotros mismos.
- La esfera de influencia incluye las actividades con las que podemos impactar, pero sobre las que no podemos ejercitar control total.
- Los elementos externos incluyen elementos sobre los que no podemos influir.
La necesidad del usuario de una historia idealmente debería estar en la esfera de influencia del equipo, mientras que el entregable en su zona de control.
Pon una fecha de “best before” en las historias
Para evitar presiones innecesarias y emergencias auto inflingidas, comprueba si hay una fecha límite cuando una nueva historia de usuario es propuesta. Escribe la fecha de “best before” en esas historias y haz visualmente obvio que esas son especiales y tienen que gestionarse por separado.
No intentes poner fecha de “best before” en todas las historias, de lo contrario todo se convertirá en una emergencia.
Próximamente iré completando las traducciones de las recopilaciones del resto de bloques:
Planificando con historias
Discutiendo historias
Partiendo historias
Gestionando la entrega iterativa
Obviamente estas anotaciones no pretenden servir como sustitución al libro, pero tal vez resulte de inspiración para investigar más en profundidad alguna de estas ideas.