Prioriza el Backlog: Chunking y User Story Mapping

Introducción

Hace unos días participé en el Agile Trends como ponente del Workshop «Prioriza el Backlog de forma rápida y efectiva». En este explicaba por qué es importante priorizar, cuáles son los principales problemas que nos encontramos al priorizar y explicaba el enfoque correcto que se debe adoptar a la hora de priorizar.

Además, detallaba una serie de técnicas que se pueden realizar de forma rápida y efectiva distinguiendo si la priorización del Backlog la realizamos a nivel estratégico, de coordinación u operacional.

Dada la demanda de los asistentes por conocer más sobre estas técnicas, doy inicio a una serie de post donde las explico más en profundidad y arrancamos con la primera de ellas, el chunking.

Chunking

El chunking o fragmentación se basa en un estudio de George Miller «El mágico número siete, más o menos dos», en el cual se estudia la memoria a corto y medio plazo del ser humano. Llegando a la conclusión de que somos buenos memorizando agrupaciones de 7 números (2 arriba, 2 abajo) pero no más allá.

En el estudio además, se indicaba que somos mejores memorizando cuando la información fragmentada es agrupada, dándole un cierto sentido para nosotros. Por tanto, podemos definir el chunking como el proceso por el cual las piezas individuales de un conjunto de información se descomponen y luego se agrupan en un todo significativo.

Esto se ve mejor con un ejemplo:

Y es que no es lo mismo que te den un número de teléfono de continuo que en agrupaciones como se ve en la imagen. (34) es el código de país, 91 es el código de provincia, etc.

El chunking está más presente en nuestro día a día más de lo que te imaginas y lo puedes encontrar en matrículas de coche, teléfonos, documentos de identidad, etc.

Y es que el chunking te ayuda a presentar la información de una forma que hace fácil a tu audiencia entender y recordar.

Ahora que conocemos el chunking, veamos cómo aplicarlo a nuestro Backlog. Pongamos una situación que suele ser habitual en las empresas que suelen tener dificultades para priorizar: El jefe de proyecto dispone de un excel en el que refleja mediante un Gantt toda la planificación del trabajo a futuro para el próximo año, con cálculos milimétricos y en el que todo es importante y todo debe estar listo para la próxima release.

Aquí ya os adelanto que cuando todo es prioritario, nada lo es.

Pero vamos a ayudar a nuestro Jefe de Proyecto a priorizar el Backlog. En primer lugar debemos de comprender el Principio de Pareto que nos dice: el 80% del valor proviene del 20% de los elementos del Backlog.

Con lo que aplicando este principio junto con el chunking, vamos a identificar qué elementos del Backlog son los que aportan más valor. Esto es, están enfocados a las necesidades reales del mercado; hay una demanda para ello. Y para esto vamos a utilizar el User Story Mapping.

User Story Mapping: Conceptos.

El User Story Mapping es una herramienta muy poderosa para visualizar el Backlog de forma bidimensional introducida por Jeff Patton. Te permite ver las historias de usuario siguiendo un flujo narrativo hilado por el User Journey y permite tener una visión general del producto junto con las prioridades.

El objetivo es alcanzar un entendimiento compartido a través del pensamiento y la comunicación externa y para ello, nos basamos en el Visual Thinking: sketching, combinación de palabras e imágenes, organización de ideas, etc.

Uno de los beneficios más importantes que proporciona el User Story Mapping es que sirve de iniciador de conversaciones así como de procesos colaborativos en el que tanto los expertos en la materia, como los Stakeholders, se reúnen para indicar sus pensamientos y visualizarlos. Esta parte del proceso se conoce como «Los 3 amigos» ya que es imprescindible que acudan a esta reunión el Product Owner, un desarrollador y un diseñador.

Otro de los beneficios que nos aporta es el de servir de puente entre desarrolladores y diseñadores:

• Los diseñadores: entienden, analizan y traducen las narrativas de los usuarios. Lo que da como resultado que los diseñadores entienden qué es factible, cuáles son los riesgos, los costes y los compromisos.
• Los desarrolladores: deconstruyen sistemáticamente estas narrativas con la finalidad de implementarlas. Lo que da como resultado que los desarrolladores entienden mejor a los usuarios, su contexto y sus objetivos.

Por último, obtenemos una visión general ampliando la imagen. Ya que es común que en los procesos agile nos perdamos en los detalles centrándonos sólo en algunas de las historias de usuario, el User Story Mapping nos va a permitir desglosar el todo en piezas más pequeñas (chunking) pero aún teniendo la imagen global como punto de referencia.

Visualicemos el User Story Mapping y desglosemos su anatomía. Para ello voy a utilizar la infografía de Henny Portman:

• Backbone: comprende el flujo de las actividades y tareas a alto nivel de todo el producto que dan al User Story Mapping su estructura. Este se organiza en un flujo narrativo que puede ser obtenido mediante técnicas como el Pixar Pitch o el Customer Journey y que va de izquierda a derecha. Las subtareas más pequeñas, los detalles y las variaciones cuelgan para formar las costillas conectadas a la columna vertebral.
• User types: un mapa cuenta una historia sobre un tipo de persona que hace algo para alcanzar un objetivo. Asegúrate de incluirlos en el mapa junto con un poco de información sobre ellos. Puedes utilizar para ello la técnica User Persona para identificarlos. Estos pueden ser un único usuario, varios comprometidos con la misma actividad o también un sistema como puede ser un gestor de contenidos.
• Activities y Steps: las actividades organizan tareas realizadas por personas similares en momentos similares para alcanzar un objetivo. Para una aplicación de correo electrónico, las actividades podrían incluir:
  • Revisar mi bandeja de entrada
  • .Configurar mi cliente de correo electrónico.
  • Organizar los mensajes en carpetas.
• User Tasks: Son frases cortas con una acción que constituyen el bloque básico de un mapa. Si te pregunto qué has hecho hoy al usar el correo electrónico, probablemente responderás con tareas como:
  • Leer un mensaje de correo electrónico.
  • Responder a un mensaje.
  • Marcar un mensaje como spam.

Una vez poblado nuestro User Story Mapping con la estructura mencionada anteriormente, nos falta hacer una acción más y es dividir el contenido en Releases. Con lo cual aquí se va a iniciar una conversación interesante sobre qué es lo prioritario, es decir, aquellas tareas sin las cuales no lo vemos funcionar, sumando aquellas tareas que lo hacen mejor y por último las que lo hacen comercializable.

Quedándose fuera de esta primera release todas aquellas tareas que hacen mejor a nuestro producto pero para las que no tenemos tiempo y se afrontarán en futuras releases. Esta acción es la llamada Release Slicing. En la infografía anterior etiquetadas como 1, 2 y 3.

En un ejemplo real del desarrollo de una red social en la que la gente puede conocer gente con la que jugar al ajedrez online:

Si miramos el User Story Mapping por filas, tenemos un primer bloque formado por el Backbone con las actividades en azul y los pasos en amarillo. Siguiendo el flujo narrativo tendríamos «Crear Cuenta» y después «Crear Perfil» y después «Buscar gente con la que jugar» y después «Comunicarse con el oponente» y después «Jugar VS PC».

Si por el contrario lo miramos en vertical, lo que estamos haciendo es ver en detalle una actividad y un paso en concreto de esa actividad. Este estará comprendido por tareas, subtareas, opciones, casos límite, etc. En la imagen anterior por ejemplo para la actividad «Crear Perfil» y el paso «Introducir Datos» las tareas que lo conforman son «Datos Básicos» (un nick, por ejemplo), «Introducir Datos» (nombre y apellidos), «Introducir Dirección», etc.

User Story Mapping: Proceso.

1. 1. Identifica los objetivos de usuario (User Goal) para ello hazte las preguntas: ¿Qué problema quieres resolver? ¿Qué característica añadir al producto? Pero también ten en cuenta los objetivos de negocio: ¿por qué construir este producto?, ¿qué beneficios aporta a la compañía construir este producto o  feature? Siempre enfocado a la misión y visión de la compañía.

      

   2. Añade la audiencia objetivo del producto, los User Personas. Nombra los diferentes tipos de usuarios que harán uso del producto o feature. Identifica al usuario que comprará tu producto y por cada usuario, indica el beneficio que obtendrán por usar el producto.

      

   3. Mapea la imagen global. Añade pasos al flujo narrativo de modo que empieces a mapear toda la historia indicando las actividades y tareas. Si se hace muy grande agrega un nuevo nivel. Siempre empezando por las más críticas para el éxito de tu producto.

      

   4. Explora, llena el cuerpo del User Story Mapping desglosando las tareas más grandes en subtareas más pequeñas y agrega detalles de la interfaz de usuario. Aquí es justo el momento de agregar todas las ideas que se os ocurran aunque queden fuera del alcance, ya que luego se priorizarán. Para ello plantéate ideas del tipo:
      1. Estaría guay si…
      2. Busca variantes.
      3. Busca excepciones.
      4. Considera otros usuarios.
      5. Añade detalles del producto: descripción de la propuesta de UI, reglas de negocio, etc.
      6. Involucra a otros, cuéntale tu historia de producto a otros que conozcan a los usuarios.
   5. Divide en Releases centrándote en las métricas y los outcomes, de modo que tu primera release sea un MVP (Producto Mínimo Viable). Este además servirá para probar la confianza en la idea de producto y así como las asunciones más arriesgadas.

      

   6. Divide en estrategias de desarrollo. Divide la primera versión del mapa en tres o más fases de entrega que te permitan a ti y a tu equipo aprender rápidamente y evitar riesgos.
      1. Planifica el trabajo necesario para refinar las historias.
      2. Crea talleres de historias de usuario con los desarrolladores y testar para trabajar en los detalles y acordar los criterios de aceptación.
      3. Planifica el desarrollo y las pruebas.
      4. Construye y verifica partes del software en funcionamiento.

Conclusiones

El User Story Mapping es una método de priorización en el que se utiliza un pensamiento basado en los outcomes. Esto es, la gente quiere mejores formas de alcanzar sus objetivos y se plantean preguntas del tipo: ¿qué problemas resolverán esta feature o producto?, ¿por qué es mejor que otras alternativas existentes?. Y está alineado con los objetivos de negocio.

Además, proporciona gran ayuda en la toma de decisiones sobre qué hay que construir y en qué orden, siendo el objetivo minimizar el output y maximizar el outcome ya que se toman las decisiones apoyados en un backlog bidimensional según la línea temporal y la importancia.

Los pasos a dar para construir un User Story Mapping son:

1. Conocer la estrategia de negocio.
2. Conocer la audiencia objetivo.
3. Identificar objetivos y actividades.
4. Identificar características.
5. Profundizar hasta donde se desee.

Existen numerosas herramientas digitales para construir el User Story Mapping entre las que destaco MIRO y MURAL ya que permiten hacerlo fácilmente y de forma gratuita. Sin embargo, desde mi punto de vista la mejor opción es realizarlo con post it y empleando una pared a modo de pizarra.

El uso recomendado de este método de priorización está a todos los niveles de la compañía ya sea a nivel estratégico, de coordinación u operacional ya que involucra a cada uno de ellos y permite alinearnos para mapear las releases y los futuros sprints.

Una última consideración a tener muy en cuenta es que el User Story Mapping mapea el mundo de hoy y no el de mañana, con lo que este tiene un trabajo de evolución detrás que conlleva el uso del diseño y el descubrimiento para describir el comportamiento que se espera que tengan los usuarios en el futuro.