Introducción
En Scrum el Product Backlog evoluciona en cada iteración. La gran pregunta es cómo y cuándo se genera el Product Backlog inicial, el utilizado en el Sprint Planning del sprint 1.
La respuesta es durante la fase de Inception. En este artículo ahondaremos sobre este concepto tan importante para todo proyecto Ágil (no sólo Scrum) y a la vez tan poco mencionado y elaborado.
Además de generar el Product Backlog, la fase de Inception o Sprint 0 incluye actividades tales como: seteo y configuración de ambientes, armado del equipo de Scrum, identificación de riesgos y stakeholders, aseguramiento de presupuesto, diseño y desarrollo de arquitectura inicial, elaboración de historias, story map y release plan.
Como dijimos este es el sprint 0 así que debo generar meta historias con sus tareas para irlas moviendo a lo largo de las 2 semanas en el tablero Kanban.
A continuación desarrollaremos alguno de estos conceptos:
Equipo, reglas, marco de trabajo, restricciones y stakeholders
La primera actividad del Inception es una breve introducción del equipo y del objetivo del proyecto.
El Scrum Master (SM) presenta cada integrante del equipo y sus roles. Recordar que en el equipo de scrum, todos los integrantes son definidos como developers ya que más allá de que hay skills determinados, todos deben contribuir con el objetivo común planteado para el sprint.
SM define marco de trabajo: roles, horario, importancia de la fase, objetivo, interacciones necesarias dentro del equipo.
Mención de restricciones del proyecto, en el caso que las hubiese. Por ejemplo: no se puede gastar más de X presupuesto, o el proyecto no puede ir más allá de X fecha.
Definir reglas de juego para el proyecto: hora entrada, salida, almuerzo, breaks, etc. Se pega un post it en la pared por cada regla. Esto hay que irlo reafirmando a lo largo del proyecto.
Identificar stakeholders clave: usuario final, operaciones, marketing, seguridad, etc.
Estos stakeholders serán consultados sobre las historias, y mantenidos al tanto sobre el incremento del producto a lo largo de los Sprint Reviews. Es importante identificar el tipo de interacción que se tendrá con los stakeholders a lo largo del proyecto. Si sólo se los mantiene informados o si además se requiere su input o feedback (para diferenciarlos, agrego 1 marca para los primeros y 2 para los segundos). Se pega un post it en la pared por cada stakeholder. Este tablero hay que irlo actualizando a lo largo del proyecto.
Identificación historias de usuario
Una vez hecha la introducción anterior, se va al análisis propiamente de los requerimientos. Estos pueden venir en un documento formal por parte del usuario o en una expresión de deseo. Recomiendo analizar los requerimientos desde todas las aristas: funcionales, valor para el negocio, pantallas, conceptos abstractos y concreto, entradas al sistema y flujos, diseños, funcionalidades esperadas, etc
Si es una modificación a un sistema actual hay que analizar el impacto sobre el mismo:: backend, performance, necesidad de test de integración, etc.
También hay que analizar los requerimientos no funcionales: performance, seguridad y estándares.
El objetivo de una Historia de Usuario (HU) es el de establecer diálogo entre el equipo y lograr un entendimiento común.
Recordar que las HU son requerimientos funcionales que agregan valor al usuario final y también los no funcionales que impactan al producto entregado.
El formato estándar para una HU es el siguiente:
Yo como un [Rol], necesito [Descripción de la funcionalidad], con la finalidad de [Descripción de la consecuencia].
Creación del Mapa de historias
Las HUs se agrupan verticalmente por funcionalidad o proceso.
Para sistemas pequeños las agrupo por funcionalidad: login, alta, consulta, transacción, salida.
Para sistemas grandes lo divido en procesos: entradas, salidas, transacciones, reportes, consultas, operaciones.
En segunda instancia priorizo las historias por importancia. Es una agrupación horizontal por relevancia en la que el PO es responsables de priorizar el orden en que se desarrollan las historias.
Una vez realizado el mapa con todo el equipo, el mismo se valida con los stakeholders; prestando atención sobre todo a la prioridad marcada para cada historia.
Estimación o pesaje de HU
El próximo paso es el de estimar las HU por tamaño. El pesaje es relativo y se puede usar planning poker con Fibonaci (1, 2, 3, 5, 8 ….) o talla de camiseta (XS, S, M, X, XL).
Es importante definir una historia de tamaño 1 y comparar relativamente todas las demás con ella (pivote). También es importante que el equipo defina cuánto tiempo aproximado le llevaría cerrar una historia de tamaño 1 para tenerla como referencia y poder hacer proyecciones de tiempo.
Release planning
Es el PO el que determina, en base a las prioridades, las funcionalidades para cada release. Todo sprint debe estar orientado a un objetivo particular y a dar valor al usuario. Sin embargo, no todo sprint va a producción; sobre todo en empresas que tienen procesos de calidad y certificación independientes y pases a producción largos y tediosos.
En mi equipo, vamos a PROD cada 2 sprints. Recordar que hay equipos que van a producción varias veces durante un Sprint (Integración continua o Devops) y otros cada varios sprints.
Definition of Done (DoD)
Otra actividad fundamental dentro del Inception es establecer la «definición de hecho» (DONE). Por ej: cumplir los criterios de aceptación de la historia, pruebas unitarias, documentación, testing, etc. Esta checklist debe ir en un tablero en la pared y debe ser analizada y de ser necesario actualizada durante la Retrospectives.
Historias detalladas
Finalmente el PO debe detallar las HU en un documento para que los desarrolladores tengan un punto de partida claro. Nosotros definimos un template de HU en excel que nos ha dado bastantes resultados. En una hoja se incluye la descripción, criterios de aceptación, consideraciones y estimación (puntos de historia). En las otras se incluye documentación técnica, imágenes de la pantalla a desarrollar, casos de prueba, etc.
Es importante que durante el inception el PO desarrolle las historias para los sprints 1 y 2. De esta forma, en el primer Sprint Planning el equipo puede decidir qué historias incluir en base a la prioridad, complejidad y capacidad del equipo. Por eso el PO debe estar siempre adelantado 2 sprints para darle margen al equipo para adaptarse y tomar decisiones.
Conclusión
Aunque la guía de Scrum no menciona la fase de Inception, la misma es fundamental para hacer el setup del proyecto y sobre todo armar el mapa de historias de usuario y el release plan. Estos serán los pilares para guiar el proyecto a lo largo de los sprints subsiguientes.