¿Se pueden incluir historias de usuario provenientes de varios epics en un sprint?

Ejercicio de pila de producto

Esta pregunta vino de una alumna que, en un ejercicio de creación de una pila de producto, me preguntaba qué hacer en caso de tener dos epics donde ambos se descomponían en historias de usuario tanto prioritarias como no prioritarias. Lo que realmente estaba preguntando era si se pueden mezclar historias de usuario de diferentes epics, y la respuesta es un rotundo ¡SI!

Si miramos la pila de producto, y si tomamos perspectiva, veremos que los epics están al final, en la parte que de momento aún no aporta gran valor al producto/cliente. Los elementos cercanos al sprint son todo historias de usuario, por tanto dentro de las mismas podemos priorizarlas como más nos convenga para maximizar el valor que aportan, por supuesto respetando las dependencias que pudiera haber. El hecho de provenir de la descomposición de epics diferentes no tiene ninguna importancia en el momento de incluirlas en un sprint.

La perspectiva ágil es construir aquello que más problemas de negocio solucione o más beneficios aporte a negocio, independientemente de donde venga.

Como ejemplo me imagino una compañía de seguros que decide probar con dos nuevos productos, un seguro de mascotas y otro de bicicletas... y como no tiene idea de la repercusión que tendrán estos nuevos seguros en el mercado decide empezar por desarrollar únicamente el formulario de solicitud de ambos. En cuanto reciban solicitudes de un u otro seguro y en función del volumen, el mercado marcará por qué frente seguir desarrollando.

Lo importante son los objetivos u metas de los sprints, objetivos que pueden ser comunes a los diferentes epics, o no serlo. En el ejemplo podría ser algo como "formulario de solicitud de ambos seguros activo", y si son cosas muy distintas podrían ser algo como: "poder tarificar seguros de bicicletas y poder emitir recibos de seguros de mascotas".

¿Cómo conseguir que el equipo tenga empatía hacia los usuarios?

El pensamiento de las personas se estructura siguiendo una narrativa, una historia, así es como entendemos el mundo. Estamos capacitados para comprender personajes, deseos y motivaciones, por tanto la forma en que más facilidad tenemos para adquirir y retener conocimiento es a través de las historias. A través de estas nos metemos dentro de los protagonistas de forma que vivimos como tales la historia que nos cuentan.

Una técnica que viene de la Experiencia de Usuario (UX) y nos acerca a los usuarios, es la User-Persona (Personalidad-Usuario), una técnica que permite ponernos en lugar de los usuarios y vivir su historia. La técnica se basa en la idea de conocer a los usuarios del producto que vamos a construir mediante arquetipos descritos como personajes de ficción, como por ejemplo una representación realista de la audiencia clave de nuestra web o aplicación. Estas User-Personas serán los roles de usuario del patrón de Mike Cohn para las historias de usuario:

Como [rol del usuario], quiero [objetivo], para poder [beneficio]

• Como [rol del usuario]: ¿para quién estamos construyendo esto? No se trata de un cargo o un rol profesional, se trata del tipo de persona que hay detrás de la necesidad descrita, personaje que describimos con la User-Persona y que permite al equipo tener un entendimiento compartido de quién es, entender como trabaja, como piensa y siente, en definitiva tener empatía por él.
• Quiero [objetivo]: Aquí estamos describiendo su intención, no la funcionalidad que usará. ¿Qué es lo que realmente está tratando de lograr?
• Para poder [beneficio]: ¿cómo encaja su necesidad inmediata en lo que le rodea? ¿cuál es el beneficio general que está tratando de lograr? ¿cuál es el gran problema que necesita resolver? Se trata de un beneficio que va relacionado con la visión del producto.

Con esta técnica nos centramos en los usuarios y mantenemos nuestras conversaciones centradas en estos. Dándoles un nombre y asignándoles una personalidad empatizamos con ellos y con el grupo de usuarios al que representan. Si los usuarios objetivos de nuestra web son un determinado tipo de persona, como los perroflautas, hacer su User-Persona y referirnos a ella con su mote, nos permite ponernos en su lugar e imaginar cómo interactuarán con el sistema, ayudando al equipo a entenderlos, a tomar decisiones más acertadas y ofrecer soluciones más adecuadas a sus necesidades.

Ejemplo ficticio de User-Persona - cortesía de Pixabay

La técnica representa a los usuarios en una ficha tipo tríptico, J.M.Beas en su artículo sobre User-Personas nos propone el siguiente esquema básico de una User-Persona:

• Nombre y apodo: una manera rápida de identificar y reconocer al personaje
• Datos demográficos: ayudan a clasificar al personaje dentro de un segmento de mercado
• Descripción: se trata de un párrafo breve que nos ayude a conocer al personaje
• Objetivos: buscamos aquellas necesidades del usuario que distinguen su comportamiento del resto

Ejemplo de User-Persona de un ScrumPerry ;-P

El formato de tríptico es muy práctico ya que permite doblar el papel para reducir su tamaño y así colocarlo con un trozo de cinta de carrocero o celo en nuestros tableros de Scrum, User Story Mapping, Kanban, etc.

Animaos a incluir User-Personas en vuestro día a día. Cuando converséis en las diferentes reuniones saldrán a mención algunas de estos personajes, y la conversación alrededor de estos acercará al equipo a aquellos que al final van a utilizar nuestra aplicación como una herramienta de trabajo día a día.

Hay un poco de gamificación en esta práctica, eso es divertido, recordad que para hacer cosas serias es necesario pasarlo bien.

¿Cómo prevenir y evitar roces en el equipo?

Tablero de acuerdos de trabajo del taller de J.M.Beas

Recientemente participé en un taller en el que nada más empezar llenamos con post-its un tablero de acuerdos de trabajo. 

En una primera columna "participante" añadimos cada uno aquellas cosas que no nos gustaría que hicieran otros participantes, y en la columna "facilitador" todo aquello que no nos gustaría que hiciera el trainer. Algunas de las cosas fueron comunes, otras más particulares, lo interesante es que emergió todo aquello que era importante acordar a nivel de todo el grupo.

Una vez que todos pusimos post-its en el tablero, discutimos aquellos en qué había dudas o desacuerdo. Así, en cuestión de 10 minutos se estableció un marco de acuerdos, y lo más importante fue que todos sabíamos lo que como grupo nos importaba que no ocurriera, y conseguimos crear empatía para con los demás.

Esta herramienta tan simple es muy eficaz para fomentar la comunicación y llegar a acuerdos, nos permite llegar a un marco de trabajo en el que el equipo se sienta cómodo y evitar roces que pudieran producirse. Este ejercicio se puede hacer al principio, cuando se forma el equipo, cuando se incorpora un nuevo miembro y también periódicamente para tratar temas que puedan ir surgiendo. Y si lo hacemos con una coca-cola o cerveza en la mano es una ocasión ideal para aprovechar y hacer team-building. :-)

Si queremos refinar aún más nuestro tablero de acuerdos podemos incluir la columna de "expectativas". De esta manera no solo sabremos como interactuar y respetar los límites del equipo, sino que también sabremos las expectativas que tienen los demás miembros. Esto permite al Scrum Master o Coach Ágil alienarse para mantener una motivación óptima en el equipo.

Tablero que incluye la columna de expectativas

¿Qué es un coach ágil y cuáles son sus tareas principales?

Para dar apoyo y entrenamiento a equipos que están adoptando Agilidad y que se enfrentan con los retos del desarrollo ágil, se recurre al coach ágil. Opera a nivel de múltiples equipos y es capaz de sacar el máximo talento de las personas y de los equipos. Es un system thinker, trata de ayudar y apoyar en todos los problemas, conflictos y necesidades del sistema desde la perspectiva holística.

Por lo general se trata de un profesional con gran experiencia en los métodos y las técnicas ágiles, que guía y acompaña a los equipos a través de los momentos difíciles, hasta que encuentren su propio camino hacia la madurez. Es una mezcla de trainer que enseña cómo funcionan los métodos ágiles, y un coach que escucha y hace preguntas que hagan pensar y por tanto crecer a las personas y a los equipos.

Tareas principales:

Coach ágil vs.Consultor - Meetup Madriagil

• Apoyar la transición de proyectos nuevos y existentes a una manera ágil de trabajar
• Evaluar la de preparación del equipo en Agilidad e impulsar los niveles de fluidez con dirección
• Cada vez que sea necesario actuar como coach ágil formando parte del equipo:
• Ser mentor, facilitador y coach de los equipos ágiles, de los coaches de equipo y los Propietarios de Producto
• Proveer de formación in situ, ad hoc y formal en Agile/Lean con el apoyo del equipo central de adopción de Agilidad
• Hacer posible la adopción de prácticas Lean dentro del contexto de la entrega del proyecto
• Ayudar al equipo líder a entender y desarrollar sus conocimientos y prácticas Agile y Lean
• Identificar y entrenar a coaches de equipos emergentes
• Identificar impedimentos para formas ágiles de trabajar y cooperar con el equipo central para mitigarlos y resolverlos
• Participar y apoyar comunidades de práctica ágil: asegurar métodos y enfoques consistentes dentro de todo el grupo
• Trabajar en la fluidez del ciclo de vida de cambio ágil y apoyar su adopción en los proyectos
• Establecer las métricas del proyecto para medir los beneficios iterativos en valor para el cliente

Preguntas poderosas que hace un coach:

• ¿Qué nuevas conexiones estás haciendo?
• ¿Qué significado real tiene para ti lo que has escuchado?
• ¿Qué te sorprendió?
• ¿Qué te desafió?
• ¿Qué falta de esta imagen? ¿Qué es lo que no estamos viendo?
• ¿Sobre qué necesitamos más claridad?
• ¿Cuál ha sido tu aprendizaje, revelación o descubrimiento principal hasta ahora?
• ¿Cuál es el siguiente nivel de pensamiento que necesitamos hacer?
• ¿Qué no se ha dicho todavía que podría ayudar a alcanzar un nivel más profundo de comprensión y de claridad?
• ¿Qué harías si el éxito estuviera garantizado?

Be Agile - Using an agile project-management approach

¿Cómo representar la granularidad de la pila de producto?

Elementos que representan la granularidad de pila de producto

La granularidad es el nivel de detalle de cada elemento de la pila de producto, y este debe de ir en relación a la posición dentro de la misma. Recordemos que la posición va en relación a la prioridad. Al final de la lista, donde está lo menos prioritario, están los epics, historias de usuario de gran tamaño, y los temas que describen grandes cosas, de los que cada uno se descompondrá en elementos más pequeños a medida que avanza por la pila.

Las historias susceptibles de entrar en el próximo sprint son las que más detalle deben de tener para que en la reunión de planificación de sprint el equipo tenga toda la información necesaria para desglosarlas en tareas de la pila de sprint.

Una forma de imaginarnos la granularidad de la pila de producto es hacerlo comparándola con una ciudad:

Representación de la granularidad en forma de ciudad, aquí München, mi ciudad natal :-)

En primera línea tenemos edificios con mucho detalle, historias de usuario muy detalladas, y a medida que miramos más lejos se pierde el detalle. A medio camino vemos edificios con poco detalle, estos representan a los epics, hasta que al fondo intuimos contornos de grupos de edificios que representan a los temas. Con cada iteración o sprint damos un paso al frente, se perfilan al detalle los edificios que ahora tenemos delante y que representan las historias de usuario susceptibles de entrar en el siguiente sprint.

De la misma manera ganamos un poco de detalle a todos los demás niveles, se perfilan los edificios de segunda y tercera línea, y los lejanos, de los que solo vemos contornos, se van dibujando y perfilando sus características más amplias. Este perfilado de detalles representa el refinamiento y revisión constantes de la pila que hace el Propietario del Producto. Con esta imagen, al caminar por la ciudad, se visualiza el estado flujo continuo que prescribe la Agilidad, vemos como focaliza en lo prioritario sin perder de vista el todo.

Otra característica interesante para imaginar la pila de producto es ver como los edificios están en un plano bidimensional, y que vemos edificios a distancias iguales en todas direcciones. A diferencia de lo que significa la palabra pila, la mejor forma de representar una pila de producto es la de un embudo. Tal como puede imaginarse en esta foto de Munich, donde vemos muchos edificios a la misma distancia, estos representan elementos lejanos que actualmente tienen una prioridad similar y muy baja, de los que aún no sabemos en qué prioridad y valor cristalizarán a medida que avancen por la pila. Si pensamos en una pila lineal esta puede dar la impresión de una prioridad inexistente.

¿Cómo se realizan las hojas de ruta del producto?

Las hojas de ruta son una herramienta de la planificación ágil que se hace necesaria en el desarrollo de proyectos/productos medianos y grandes. Son una representación gráfica del "todo": las etapas/releases previstos de un producto junto con sus contenidos y componentes principales para llegar a la visión. Por su naturaleza de "grande" se da la circunstancia de un cierto grado de certeza que permite "predecir" a medio o a un año vista como puede evolucionar el futuro del producto. La release en curso es de naturaleza más comprometida, las releases posteriores representan oportunidades.

Ejemplo de hoja de ruta

Se trata de una herramienta de comunicación muy eficaz para todos los interesados. A parte de proporcionar una vista rápida de las releases y los objetivos asociados, permite reflexionar sobre el futuro del producto y alinear la estrategia de la empresa y la del producto.

La hoja de ruta es responsabilidad del Propietario del Producto, y este es quien determina las etapas y las releases. Para darle forma a la hoja de ruta se apoya en el equipo para que aporte conocimiento técnico y estimación a muy grandes rasgos de funcionalidades potenciales o tentativas que den solución a los objetivos proyectados.

Un ejemplo de entradas en la hoja de ruta podría ser:

• V.3.1, para el segundo trimestre de 2015, implementará la gestión de empleados.
• V.2.5, para el último trimestre de 2015, implementará la integración con Logic.

Hay varias maneras de representar las hojas de ruta. La forma que me parece más práctica, ya que puede ir en un tablero físico como los que se usan para Kanban, es la que muestra esta plantilla de Agile Roadmap para Powerpoint de libre uso y que he utilizado para el ejemplo.

¿A que niveles se planifica bajo Agilidad?

A primera vista, y bajo las reglas de Scrum formal, el equipo planifica las tareas del sprint en la reunión de planificación de sprint, y dado que los sprints son cortos toma importancia la microplanificación sin existir un plan cerrado al que seguir. Cuando se trata de proyectos con un gran número de sprints y/o con muchos equipos trabajando en paralelo se hace necesario un plan con un detalle mínimo para no perder la visión del "todo" del proyecto. Este plan mínimo se consigue en Agilidad planificando a niveles superiores.

Hay cinco niveles de requisitos ágiles que se van desgranando paulatinamente desde arriba a abajo a medida que se avanza en un proyecto ágil. Es como un embudo en el que entran los requisitos en una forma más general y altamente granulada y se van desgranando y concretando a medida que avanzan en base al valor que aportan. Acaban saliendo como tareas detalladas para la pila de sprint en la parte inferior. Con ello la ingeniería de requisitos ágil trata de establecer un estado de flujo continuo en que se van concretando los requisitos desde la entrada al embudo hasta su salida.

Niveles de requisitos ágiles, cortesía de Scrum Manager

• Visión del producto: un resumen muy corto de las funcionalidades deseadas y los objetivos del producto a construir compartido por todos
• Tema: representa una colección de epics relacionados para describir un sistema o subsistema en su totalidad
• Epic: una superhistoria de usuario que se distingue por su gran tamaño y su alta granularidad
• Historia de usuario: una descripción breve de una funcionalidad de software tal y como la percibe el usuario
• Tarea: resultado de la descomposición de las historias de usuario en unidades de trabajo o tareas con las que el equipo puede trabajar

Para no perder la visión de un gran proyecto en su totalidad y obtener un plan mínimo necesario, se planifica en correlación a cada uno de estos niveles.

Niveles de planificación ágil

Visión del producto: en la visión se describe un estado en que se proyecta el producto a alrededor de un año hacia el futuro, que suele ser estático a lo lo largo del periodo. Las demás planificaciones concretan y detallan la visión y dado que deben de responder y adaptarse al mercado, pueden desviarse razonablemente de la visión.

Hoja de ruta del producto: se trata de la planificación de las etapas a recorrer para llegar a la visión, dado que en Agilidad se trata de entrega frecuente, en cada etapa se determinan los releases que serán incluidos. Usualmente se trata de una representación gráfica de releases previstos junto con sus contenidos en forma de temas que se comparte con todos los interesados.
 
Planificación de release: esta planificación es propia del Propietario del Producto. El equipo estima por encima la pila de producto compuesta por epics e historias de usuario, luego el Propietario del Producto proyecta los sprints futuros en base a la velocidad del equipo y planifica en rangos de fechas futuros releases. Aquí, dado que deben de participar todos los equipos del proyecto, es donde se coordinan estos entre si y surgen las dependencias entre historias de usuario que pueda haber entre equipos. Usualmente el Propietario del Producto planifica entregas que coincidan con uno o más temas, estas se representan con gráfico de producto o gráfico burnup que, focalizándose en el siguiente release, muestra visualmente la evolución previsible de los releases visibles del producto.

Planificación de sprint: se trata de la reunión en que el equipo toma historias de usuario de la pila de producto según la prioridad marcada por el Propietario del Producto, y las desgrana junto con este en las tareas correspondientes. Al desgranarlas y reestimarlas, es en esta reunión donde se va minimizando la incertidumbre. El equipo decide el incremento del sprint cuando decide hasta qué historia de usuario incluirá el sprint y se compromete a realizarlas al 100% dentro del mismo.

Planificación diaria: esta ocurre en el daily-srcum cuando los miembros del equipo informan del trabajo hecho y eligen la siguiente tarea en que van a trabajar. Esta planificación se materializa en el gráfico de avance o burndown que es actualizado día a día.

Cuadro de planificación por niveles

Nivel	Cuando	Actores principales	Salidas
Visión del producto	Una vez, antes del inicio	Propietario del Producto (opcional: Equipo de Desarrollo)	Visión del producto
Hoja de ruta del producto	Antes de algunas releases	Propietario del Producto (opcional: Equipo de Desarrollo)	Hoja de ruta
Planificación de release	Antes de cada release	Propietario del Producto + Equipo de Desarrollo (opcional: interesados)	Plan de release
Planificación de sprint	En cada inicio de sprint	Propietario del Producto + Equipo de Desarrollo	Pila de sprint y objetivo de sprint
Planificación diaria	Cada día de trabajo	Equipo de Desarrollo	Avance de sprint y gráfico de avance (burndown)

¿Scrum se carga el teletrabajo?

En realidad lo que ocurrió es que al hablar de las diferentes reuniones, entre ellas la diaria y haciendo referencia a la naturaleza de los equipos, uno de los alumnos exclamó "¡Scrum se carga el teletrabajo!"

Teletrabajador desde casa

En general las personas para sentirnos motivados preferimos el tiempo libre al dinero, y el teletrabajo nos ahorra desplazamientos y esperas en pro de nuestro tiempo libre. También nos permite organizar nuestro tiempo y por tanto mejora la conciliación de la vida personal con la laboral. Por la misma razón aumenta la capacidad de concentración y en definitiva la productividad. Para las empresas también tiene sus ventajas, costes más bajos y sobre todo aumenta las posibilidades de retener el talento.

Pero ¿cómo conciliar todo eso con reuniones diarias y un alto grado de comunicación entre los miembros del equipo? El teletrabajo funciona bien con grupos de trabajo que se basan  la cooperación, como los que forman traductores por ejemplo, en que reciben el texto a traducir por separado y lo devuelven traducido dentro del tiempo estipulado, pero ¿y con equipos donde se requiere colaboración y cuyos miembros han de estar fuertemente conectados?

En el caso de equipos ágiles no se puede implantar este tipo de teletrabajo puro. Según mi experiencia el teletrabajo de un equipo ágil ha de ser parcial, todos los miembros han de asistir presencialmente a las reuniones de planificación y revisión de sprint, así como a las retrospectivas. También es crucial que el equipo entero trabaje en la oficina uno o dos días a la semana para tratar temas en directo como reuniones puntuales, nuevas herramientas, etc. y también para hacer team-building, como tomarse unas copas juntos.

Es primordial que los miembros del equipo tengan contacto diario y en cualquier caso la reunión diaria debe de realizarse. Hay múltiples herramientas como Skype, pizarras Kanban virtuales, Hang-out, y la hoja de cálculo de Google que permiten realizar el daily-scrum virtualmente.

Consejos para la reunión diaria virtual:

• Es importante que todo el mundo mantenga el foco en la conversación y no mantenga conversaciones paralelas
• La puntualidad es básica, todos deben de estar disponibles en la hora convenida
• Intentar hacer todo lo posible para que los miembros vean en todo momento en su pantalla a la persona que habla
• Definir un símbolo (banderita, tarjeta, levantar la mano, ...) para que cualquier miembro pueda parar una conversación cuando se esté alejando del cometido de la reunión

La premisa principal para que funcione el teletrabajo es que haya confianza plena entre todos los miembros del equipo, todos han de saber cómo trabajan los demás. Si esta no estuviera presente hay que construirla antes de ir a trabajar a casa. El hecho de trabajar unos días en la oficina también tiene la función de darle continuidad a esa confianza. Cuando se incorpore alguien nuevo al equipo hay que trabajar en la oficina durante un tiempo para crear la confianza necesaria con el nuevo miembro.

En definitiva, el teletrabajo es posible, pero sólo parcialmente y respetando los valores y artefactos de Scrum. Y respecto a si funciona quiero citar el texto de un post-it escrito por Sergio, un teletrabajador parcial, en una de las retrospectiva: "¡Es como si estuviera con vosotros!" :-D

El teletrabajo también tiene sus sombras, la Agilidad requiere innovación y creatividad, y el teletrabajo reduce fuertemente la serendipia, cuando grandes ideas y descubrimientos se producen por hallazgos afortunados e inesperados. Esta se produce cuando libreamos nuestra creatividad en presencial y en equipo, cuando nuestras ideas se suman y conciben grandes cosas cuando realmente estábamos buscando otra cosa distinta.

¿Qué hacer cuando el equipo nunca cumple con la pila de sprint?

Gráfico burn-down con un sprint subestimado

Partimos de la base de que tenemos un equipo formado y motivado, que lleva unos pocos sprints a su espalda y que ha alcanzado un cierto grado de autoorganización. Todo debería ir bien, pero con cada sprint se obtiene un gráfico burn-down con un patrón semejante al de la imagen de la derecha, en que se pone de relieve que las tareas de las planificación del sprint se han subestimado o han aparecido nuevas tareas que no se han visto antes durante el sprint.

Podríamos seguir nuestra intuición y razonar que dado que cada sprint se ha se alargado, que el equipo necesita más tiempo y la solución estaría en alargar el tiempo de los sprints. Pero eso sería erróneo, ya que si el equipo está fallando repetidamente a no llegar a final de sprint con todo terminado algo no está funcionando en la estimación. Contrariamente a ese primer impulso, lo que hay que hacer es reducir el tiempo de los sprints, hacerlos más pequeños. Con ello se obliga al equipo a tomar menos historias de usuario y crear tareas más pequeñas, y cuanto más pequeña sea una tarea menos incertidumbre hay en su estimación, y por tanto más certidumbre para terminar el sprint en el tiempo establecido.

Tareas y sprints más pequeños tienen una segunda ventaja que también ayuda a cumplir los sprints y es que focalizan al equipo. Una de las constantes en los métodos ágiles, como en Scrum, es que sus iteraciones cortas y frecuentes, sus reuniones diarias y en general sus ciclos cortos mantienen el foco del equipo en lo que le da valor al proyecto.

Como tercera ventaja mencionar que cuanto menor sea el sprint más se solapan las tareas y el equipo estará diseñando, programando y probando de manera no secuencial, casi a la vez, lo que implica máxima colaboración e interacción entre los miembros del equipo, propiciando equipos multidisciplinares y autoorganizados.