Estimar es timar: Example Mapping
El fin de semana estuvimos asistiendo en la Pamplona Software Craftsmanship. Un eventazo con formato mixto de charlas agendadas combinado con sesiones de open space.
Desde los Coding Stones nos animamos a proponer un par de sesiones en el open space. En mi caso iba con una en mente con un nombre con cierto gancho: Estimar es timar. Y quiero aclarar desde ya que cuando me refiero a estimar NO hablo de asumirlo como compromiso, por ahorrarnos ese debate.
Me quedé con un sabor agridulce, porque aunque creo que salió una conversación muy interesante, pasamos un poco de puntillas sobre lo que yo pretendía haber centrado el tiro. Al final se nos terminaron mezclando temas de presupuestos, reporting de velocidad, estimaciones de features y de historias de usuario.
Mi intención en realidad era tener una conversación inicial de saber quiénes estimaban o no historias de usuario, los formatos en los que se hace en caso de que sí: tiempo, puntos de historia, tallas de camiseta… pero principalmente conocer las razones de por qué sí o no se estima.
En nuestro caso empezamos a estimar en nuestras sesiones de refinamiento del backlog por 2 razones: tener conversaciones alrededor de las historias y su tamaño, y empezar a medir velocidad.
En el pasado había trabajado en estimaciones por puntos y haciendo planning póker, y me generaba muchas dudas su utilidad para ambas cosas, así que para ir más ligeros empezamos a estimar en tallas de camiseta, pero pronto vimos alternativas que nos parecían más efectivas.
Para empezar a medir la velocidad empezamos a controlar el tiempo de ciclo de las historias de usuario y tareas (vía el API de trello). Pronto vimos que al limitar el WIP empezábamos a ir más rápido, entregábamos más tarjetas por iteración; eso que es lo que interesa, no perdamos de vista que el objetivo final de medir esa velocidad es que queremos entregar valor lo antes posible.
Por otro lado, en cuanto a las conversaciones sobre las tarjetas y su tamaño, en las sesiones de grooming ya nos dedicábamos a partir las historias en tareas. Enseguida vimos que al empezar a hablar de tallas de camisetas no nos aportaba mucho para entrar más a detalle, siendo que se le supone el principal objetivo de hacer estimaciones, así que dejamos de hacerlo.
Al tiempo descubrimos una técnica llamada Example Mapping (la mencioné sin entrar en detalle en un post previo) con la que empezamos a experimentar, pronto vimos que nos podía aportar una conversación estructurada que una estimación no hacía y le podíamos sacar mucho más valor.
Y llegamos al fin al Example Mapping
Como introducía, el Example Mapping es una actividad de equipo muy sencilla para explorar el dominio y conocer los detalles de una historia de usuario, así llegar a un entendimiento compartido entre los miembros del equipo de una forma estructurada.
Recordemos que una historia de usuario no deja de ser de un recordatorio de una conversación, rara vez será una especificación concreta de lo que tenemos que desarrollar. Puede que todavía no fuéramos capaces de ser específicos al hablar de una historia de usuario, que tengamos una sensación de entendimiento compartido que en realidad no es tal o incluso que lo tengan que desarrollar algunas personas que no han estado en esas conversaciones.
Esta es una actividad en la que, como mínimo, debería haber una persona por rol de los llamados three amigos (Dev, Business Analyst y QA), aunque como siempre dependerá del contexto de cada equipo. A mi por ejemplo lo que más me convence a ser posible es la combinación de roles de Dev, QA, UX y PO del equipo.
Una de las cosas más interesantes de esta actividad es llegar a obtener ejemplos concretos que nos lleven a la especificación (estoy hablando otra vez de Specification by Example, sí), lo cual guía a conocer cuáles son los tests de aceptación, pero no es el único beneficio que aporta esta actividad.
Además de los ejemplos, a través de las conversaciones de esta actividad también extraeremos y mapearemos reglas de negocio, preguntas o dudas que nos surjan de la historia de usuario en cuestión, o incluso nuevas historias de usuario de las que no nos habíamos percatado inicialmente.
Y como suele ser habitual en estos temas de mapear información, necesitaremos algún tipo de tarjetas de distintos colores para visualizar la información.
Aunque sea lo de menos, por defecto se recomiendan este código de colores:
- Amarillo para las historias de usuarios
- Azul para las reglas de negocio
- Verde para los ejemplos
- Rojo para las preguntas.
¿Cómo lo estamos ejecutando?
La idea es que estas sesiones se hagan de forma recurrente y que no sean de mucha duración, y siempre sobre historias de usuario en las que el equipo vaya a trabajar de forma inmediata. Queremos que sean sesiones ligeras para que los involucrados estemos concentrados y resulten efectivas, así que tener un time-box nos es útil.
Empezamos presentando la historia de usuario, y discutimos dudas y preguntas que hayan alrededor de ella.
Tras ello nos dejamos 5 minutos de brainstorming en silencio para que cada uno anote reglas, ejemplos que las ilustren y nuevas dudas y preguntas que puedan continuar surgiendo. Para diferenciar los ejemplos positivos de los negativos que ilustran las reglas utilizamos un check o un aspa.
Y terminamos haciendo una puesta en común volcando las tarjetas, donde pueden seguir surgiendo nuevas a través de las conversaciones. Como comentaba, incluso nuevas historias de usuario.
Si vemos que no sale nada nuevo y estamos de acuerdo de que podemos empezar a trabajar con eso, no esperamos a que se termine el time-box.
¿Al acabar qué visualizamos?
Deberíamos tener todos un entendimiento compartido sobre qué significa una historia de usuario. Habremos definido a través de los distintos ejemplos la aceptación de la historia, que potencialmente podemos transformar en tests.
Si vemos que tenemos muchas tarjetas rojas que no hemos sabido resolver, no deberíamos empezar con esa historia de usuario al tener todavía mucha indefinición.
Si hay muchas tarjetas azules es que seguramente sea una historia demasiado grande, tal vez deberíamos plantearnos partirla en varias historias de usuario.
Si hay reglas con muchas tarjetas verdes quizás sea una regla excesivamente compleja, así que en ese caso podríamos ver que potencialmente estamos tratando de cubrir más de una regla con esos ejemplos.
Seguramente tal y como vayamos adquiriendo más experiencia con Example Mapping evolucionaremos la forma en como lo ejecutamos, pero ahora ya al menos sabéis por qué dejamos de estimar y con qué alternativas hemos empezado a experimentar.
Incluso si no os he convencido a dejar de estimar, os animo a que probéis a realizar esta actividad previamente. Y por supuesto que compartáis la experiencia :)
En los Coding Stones ayudamos a compañías desarrollando software, además de impartir formación y mentoring a equipos.
Si crees que podemos ayudarte en la implantación del uso o mejora de este tipo de técnicas y herramientas, péganos un toque y vemos si podemos tocar juntos.
