¿Cómo hacer un primer sprint en el marco Scrum?

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 primer Sprint?

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 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 primer Sprint, 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 presenta cada integrante del equipo y sus roles. Recuerda que en el equipo 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.
• El Scrum Master define el marco de trabajo: roles, horario, importancia de la fase, objetivo, interacciones necesarias dentro del equipo.
• Se mencionan las 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.
• Se definen las 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.
• Se identifican los 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, 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 es establecer diálogo entre el equipo y lograr un entendimiento común.

"Recuerda que las Historias de Usuario 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 Historia de Usuario 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 Historias de Usuario 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 Product Owner 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 Historias de Usuario 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 Product Owner 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 producción cada 2 sprints. Recuerda 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 Product Owner debe detallar las Historias de Usuario en un documento para que los desarrolladores tengan un punto de partida claro. Nosotros definimos un template 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 Product Owner 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 Product Owner 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.

Fabian Schwartz

CEO Scrum Network