¡Nuevo episodio de Scrum Manager Podcast! También disponible en Spotify e iVoox.
En este segundo episodio explicamos cómo preparar un backlog y marcar objetivos claros para nuestro proyecto.
Recordad que las transcripciones de todos los episodios estarán disponibles en el blog, e iremos subiendo a ritmo de sprint: cada par de semanas. ¡No dudéis en sugerirnos temas sobre los que os gustaría profundizar en los comentarios!
Transcripción
Hola y bienvenidos. Seguro que hay quien ha decidido empezar el año siguiendo la tradición de marcarse objetivos. Nosotros no íbamos ser menos. Y queremos ayudar. En este episodio explicamos cómo preparar y usar un backlog, uno de los artefactos típicos de scrum.
¿Qué es un backlog?
En agilidad el backlog es la lista de trabajo pendiente de un proyecto. También se le conoce como «lista» o «pila». Este se utiliza para identificar, priorizar y estimar el trabajo que se debe realizar durante el desarrollo. Permite al equipo y al product owner (o propietario del producto) mantener una visión clara y actualizada del avance del proyecto.
Existen dos tipos de backlog con dos finalidades distintas: el product backlog o pila de producto y el sprint backlog o pila del sprint. Uno es a nivel de proyecto y otro es sólo para el sprint en curso.
Vamos a explicar un poco más en profundidad cada backlog:
- El product backlog es la lista que contiene los trabajos pendientes del proyecto. El responsable de crearla y actualizarla es el product owner. Al ser quien mejor conoce el negocio del cliente, debe asegurarse de que la pila refleje su visión y sus necesidades. No obstante, en algunos casos, en equipos muy implicados con el proyecto y de alto nivel, el equipo también puede colaborar en el proceso de creación del backlog. De hecho, en esas circunstancias se recomienda y así se aprovecha la inteligencia colectiva.
- Por otro lado estaría el sprint backlog: esta es la lista de tareas en las que hemos descompuesto el product backlog para completarlas durante el próximo sprint. Este documento es propiedad del equipo de desarrollo, lo cual quiere decir que ellos son los que se encargarán de mantenerlo: no el product owner. Se utiliza para planificar y monitorear el avance del sprint.
Hay que tener en cuanta algo muy importante y es que el product backlog es un documento vivo. Para que resulte útil y ayude a generar valor tiene que estar siempre actualizado y visible. Los requisitos y las prioridades del negocio pueden cambiar, y el product owner debe encargarse de que la pila de producto lo comunique claramente. En esto se diferencia del sprint backlog, que no se recomienda alterar. Una vez definido, se mantiene hasta que termina el sprint.
- Ambos, product y sprint backlog, son radiadores de la información clave para monitorizar el estado de desarrollo del proyecto y ver si se están cumpliendo nuestras previsiones. Deben estar en un lugar visible o al menos fácilmente accesible a todos. En una pared, o en una aplicación tipo Trello o JIRA.
- Las tareas tienen que estar bien definidas y alineadas con los objetivos del proyecto para poder priorizarlas y saber cuándo darlas por completadas, de esta forma podremos medir el progreso.
- Y por último, su tamaño debe ser manejable. Sobre todo, cuando pasemos al sprint backlog: debemos asegurarnos de que la cantidad de tareas es viable para el equipo de modo que no exista sobrecarga de trabajo.
En este episodio nos centramos sobre todo en el product backlog. No obstante, conforme definamos las tareas, llegaremos al final al sprint backlog.
Existen muchas prácticas en las que podemos apoyarnos para conseguir una buena pila de producto. A continuación, las mencionaremos mientras construimos un ejemplo.
De la teoría a la práctica: cómo crear un backlog
Vamos a hacer el backlog de un curso on-line. Supongamos que tenemos una empresa de formación y queremos lanzar contenido nuevo. Disponemos de material y profesores especializados en teoría musical y vamos a aprovechar esto para preparar un curso con un enfoque más práctico orientado a composición musical para películas.
Somos el product owner de este proyecto, ya tenemos clara la visión general y la hemos trabajado previamente para definir nuestros objetivos de negocio. En caso contrario, podríamos usar técnicas como el Product Canvas, de las que, si os interesan, podemos hablar en otro episodio.
Sabemos lo que queremos: un curso práctico que nos diferencie de otros y que ayude a los alumnos a desarrollar competencias que les den salidas laborales. Sabemos otros detalles como cuántos profesores necesitamos, qué temas generales va a cubrir el curso, conocimientos previos, duración…
Todo eso está hecho. Lo que nos toca ahora es concretar los requisitos. Los primeros que se identifican son los que se denominan epics o «épicas». Vamos de grande a pequeño. Los requisitos suelen recibir diferentes nombres según su tamaño y nivel de detalle, entre otras cosas. De la visión general se extraen «temas», de ahí epics, que es donde hemos empezado nosotros, y de las epics se extraen historias de usuario, y de las historias, tareas.
1. Identificar épicas
Para identificar epics (es decir, tareas o trabajos muy grandes) podemos usar técnicas de brainstorming o tormenta de ideas o talleres como los Agile Inception. También podríamos trasladar el concepto de jerarquía de necesidades de la pirámide de Maslow a las necesidades de los clientes para generar más ideas.
Como ya hemos dicho, según las circunstancias, podemos involucrar al equipo, pero el responsable directo de este paso somos nosotros: el product owner. Para nuestro ejemplo hemos hecho una tormenta de ideas teniendo en cuenta los objetivos del curso y del negocio, y éstas son algunas de las epics que podrían surgir:
- Definir los materiales necesarios para el curso.
- Diseñar la estructura del contenido.
- Crear recursos de apoyo como presentaciones, grabaciones y vídeos.
- Crear materiales didácticos.
- Subir los contenidos a nuestra plataforma web.
- Preparar la campaña de marketing.
- Probar y depurar el curso antes de su lanzamiento.
- Etcétera…
Podría haber más, pero con esto nos hacemos una idea.
Si estamos poco inspirados, la traslación de las necesidades de la pirámide de Maslow que mencionábamos antes nos puede ayudar a descubrir epics valiosas. Ésta clasifica las necesidades humanas en 5 niveles: fisiológicos, seguridad, socialización, estima y autorrealización. Así que por ejemplo, para aportar a la necesidad de «seguridad» se nos puede ocurrir incluir una epic que sea «dar soporte a los alumnos», si no tenemos este servicio ya en nuestra plataforma.
2. Definir y priorizar tareas
Una vez tenemos claras las epics, podemos descomponerlas en historias de usuario. No suele hacerse con todas las epics desde el principio, sólo con las más prioritarias. Para decidir prioridades hay otras técnicas. Vamos a usar la técnica MoSCoW para identificar las épicas más prioritarias y descompondremos una de ellas como ejemplo.
La técnica MoSCoW viene de las siglas Must, Should, Could y Won’t en inglés, que podríamos traducir como «obligación», «debería», «podría» y «no»: tenemos que encajar cada epic dentro de una de estas cuatro categorías. Y las más prioritarias, evidentemente, serán las “obligatorias”, las Must. Luego las Should «debería», las Could, «podría» y por último las Won’t, tareas que puede que nos gusten pero que no son esenciales y no las podemos incluir de momento.
Un Must u obligación muy clara en nuestro curso es «definir los materiales necesarios». Sin esto no hay curso. Y tampoco podemos saber cuál es una estructura que tenga sentido ni qué materiales preparar.
Pero como historia de usuario es demasiado grande. Para descomponerla podemos usar una técnica conocida como el «método pizza». Se trata de dividir en «porciones» lo bastante pequeñas para ser manejables, de manera que todas las porciones juntas conformen la epic completa.
También podríamos usar SMART goals, para obligarnos a redactar ciertas tareas de forma que encajen bien en el proyecto. SMART son unas siglas que suelen significar tareas específicas, medibles, viables, relevantes y limitadas en el tiempo. En nuestra guía las explicamos con más detalle. En este ejemplo no vamos a usar esta técnica, pero conviene conocerla.
Vamos a descomponer la epic «definir materiales necesarios para el curso». En este paso contaríamos con la participación de nuestro equipo, que incluye a los profesores. Están especializados en diferentes áreas: composición musical, efectos de sonido, posproducción… Identificamos, por ejemplo, las siguientes tareas:
- Preparar la programación didáctica de cada profesor, incluyendo criterios de evaluación. Esto pueden ser tres historias separadas.
- Identificar, organizar y catalogar los recursos necesarios tanto para los alumnos como para los profesores.
- Obtener licencias para contenidos con derechos de autor y software de pago.
3. Estimación de tareas
Para estimar cuánto tardaremos en hacer estas historias podemos usar, por ejemplo, el planning poker, que ya explicamos en el episodio anterior. Si alguna es demasiado grande habrá que descomponerla otra vez en otras más pequeñas.
¿Cómo sabemos cuántas tareas incluir en un sprint?
Depende de si el equipo conoce ya su velocidad; es decir, cuántos puntos de historia suelen completar por sprint. Esa media nos dirá cuántas de las historias prioritarias caben, una vez estimadas.
Los puntos de historia son unidades relativas: un punto equivale a una tarea sencilla con la que todo el equipo está familiarizado. En nuestra empresa de e-learning, por ejemplo, el punto equivale a «preparar una clase».
Y con esto ya estaríamos listos para trabajar en nuestro nuevo curso. Como ya hemos comentado antes, el backlog es un documento vivo. Los requisitos pueden cambiar. Por ejemplo, puede que se actualice el software de composición musical a mitad de nuestro desarrollo y tengamos que incluir una nueva historia para el próximo sprint que sea «actualizar los materiales del programa de edición».
También tendremos que asegurarnos, como hemos dicho al principio, de que tanto la pila de producto como la del sprint estén disponibles en un lugar visible para todo el equipo. Conforme avancemos, en próximos sprints, habrá que volver a la pila, identificar prioridades, descomponer, y estimar otra vez.
Esperamos que haya quedado claro qué son los backlog, quién se responsabiliza de cada uno, y cómo ayudan a gestionar el alcance de un proyecto ágil.
Volveremos con el próximo episodio en lo que se tarda en hacer un sprint: un par de semanas. Hasta entonces podéis encontrarnos en Twitter, LinkedIn, y en scrummanager.com.
¡Mucha suerte con vuestros proyectos y hasta la próxima!