El Sprint Cero

El Sprint 0

Siempre recomiendo la Guía Scrum como la referencia obligada a la hora de establecer las bases de nuestro conocimiento en este marco de trabajo.

Te dejo el enlace por aquí:

https://www.scrum.org/resources/scrum-guide

No obstante, cuando tratas de poner esos flamantes conocimientos en práctica, te das cuenta de hasta qué punto la guía se queda corta. Y uno de esos temas que ponen de manifiesto el laconismo de la guía es la creación del Product Backlog.

En este post hablaremos de una fase inicial de planificación previa al primer Sprint de cualquier proyecto, conocida, entre otros nombres, por el polémico nombre de Sprint Cero.

Comenzamos.

Todo el ciclo de vida de Scrum parte de la base de que tenemos un Product Backlog con todos los requisitos necesarios para poder trabajar. Pero, he aquí la pregunta del millón, ¿cómo y cuándo se crea ese Product Backlog?

Está claro que el Product Backlog debe estar antes de la primera Sprint Planning, con el contenido suficiente como para poder comenzar a trabajar en ese Sprint y en el siguiente. Entonces, ¿cuándo empezamos a trabajar, desde cero, sobre ese Product Backlog?

Pues en una fase llamada Agile Inception, también llamada por algunos Sprint 0, Sprint Zero o Sprint Cero.

El Sprint Cero

Lo puristas del Scrum aborrecen el término Sprint 0. Consideran que un Sprint es una iteración de entre 1-4 semanas en la que se planifica, se desarrolla, se prueba y se genera un entregable. Nada más.

Así que todo lo no sea eso no debería llamársele Sprint, prefieren otros nombres como kickoff, fase de planificación o lo que sea. Pero la realidad de la industria es que, habitualmente, a la fase de inception se le pone el dichoso nombre de Sprint Cero.

Nombres aparte, la sesiones de inception son esas en la que se organiza el trabajo del equipo y se establecen las bases sobre las que comenzará el primer Sprint, y de ahí hasta el último. Estas bases son de diversa índole:

  1. A nivel de Producto.
  2. A nivel de Organización.
  3. A nivel de Arquitectura y Tecnología.
  4. A nivel de Testing.
  5. A nivel metodológico.

Te digo aquí lo mismo que te decía en el apartado del Design Thinking: no alargues el Sprint Cero en demasía. Haz lo justo e imprescindible para poder comenzar con el Sprint 1 y poco más.

En principio 3 semanas debería bastarte, aunque cada organización es un mundo y estos tiempos pueden variar. Pero sea como fuere no caigas en el waterfolismo (sí, lo sé, me acabo de inventar esta palabra), no busques tener todos los cabos atados antes de empezar a desarrollar, ya que estarás tratando de prever lo imprevisible.

Ser agile es abrazar la incertidumbre, de modo que lánzate a la piscina. Quizá tragues un poco de agua al principio, pero verás como terminas nadando más pronto de lo que crees.

Veamos cada uno de los niveles de trabajo que se abordarán en estas sesiones.

Planificación a nivel de Producto

A nivel de producto deberás tener presente todas estas tareas:

Prototipo definido y testeado

Si esta tarea no terminó de rematarse en el Design Thinking, es vital que se realice en el Sprint 0. El prototipo debe quedar validado y revisado por los stakeholders, incluyendo al Equipo de Desarrollo y por supuesto por los usuarios.

Recuerda que el prototipo es la mejor referencia de tu futuro producto. Responsable: el Product Owner. Éste, como dueño del producto que es, debe velar porque exista un prototipo que identifique de forma clara y veraz el producto que comenzará a desarrollarse en breve.

Backlog definido y priorizado

A partir del prototipo comenzamos a crear el Product Backlog. Ojo, esto no es matemático, nadie dice que no pueda comenzarse a trabajar sobre el Product Backlog en el propio Design Thinking. No le pongas puertas al campo…

Por tanto, las épicas, features (si es que en tu proyecto usáis este tipo de ítem, no es un término agile estándar) e historias de usuario deberán estar definidas, priorizadas y cargadas en Jira (si es que utilizas esta plataforma) por lo menos para los dos primeros Sprints. El responsable de que esto se realice correctamente es de nuevo el Product Owner.

Si además, al Equipo de Desarrollo le ha dado tiempo de revisar estas primeras historias de usuario, mejor que mejor. Así, no llegaremos a la primera Sprint Planning sin tener ni idea de lo qué nos vamos a encontrar. 

MVP y Plan de Releases

Debemos establecer unos objetivos de negocio y plan de entregas (pilotos, campañas, …). Está claro que hasta que no empecemos con los Sprints y podamos evaluar la velocidad del equipo no podremos hacer una Release Plan medianamente decente, pero eso no es excusa para no comenzar con un mínimo roadmap del proyecto. Responsable: el Product Owner.

Planificación a nivel de Organización

Tendremos en cuenta los siguientes puntos:

Equipo y Roles

Deberá quedar establecido qué personas compondrán finalmente el Equipo de Desarrollo, cuáles serán sus roles dentro del equipo, qué porcentaje de dedicación tendrán en el proyecto (idealmente debería ser el 100%)…

En resumen, antes de comenzar los desarrollos debemos tener perfectamente claro quién compondrá dicho Equipo de Desarrollo. Puede que te parezca una perogrullada, pero ni te imaginas la cantidad de proyectos que oficialmente comienzan antes de tener cerrado su equipo de desarrolladores.

Sala/Puesto

Habrá que establecer la ubicación del Equipo de Desarrollo, ¿dispondrán de una sala agile adecuada?

Permisos de acceso

¿Habrá que realizar algún tipo de gestión para asegurar el acceso a las instalaciones? Es decir, deberemos realizar alguna clase de gestión con el área que corresponda para asegurarnos que todos los miembros del equipo podrán acceder a las instalaciones?

Y es que esa es otra, proyectos que empiezan oficialmente antes de que sus desarrolladores tengan los permisos de acceso aprobados… 😯 

Call o alternativa

En esos casos en los que no se pueda participar de forma presencial, ¿disponemos de algún teléfono de call?

Herramientas colaborativas

¿Dispondremos de alguna herramienta de comunicación interna (slack, skype, Lynx, Yammer, Teams, Zoom, etc)?

Planificación a nivel de Arquitectura y Tecnología

Deberemos tener en cuenta:

Arquitectura y Diseño Técnico definido

La Arquitectura que vertebrará el producto y su Diseño Técnico deberían quedar convenientemente documentados en Confluence o en cualquier otra herramienta que permita la consulta por parte del equipo. Responsable: el technical lead del Equipo de Desarrollo.

Pruebas de Concepto (PoC) de Arquitectura

Funcionalidad de prueba para testear nueva arquitectura, conexiones, … Responsable: Equipo Desarrollo con la colaboración especial del technical lead.

Tareas DevOps

Entornos, GIT, Jenkins,… Todo esto debe quedar previamente establecido antes de comenzar a desarrollar.

Dependencias

MUY IMPORTANTE, debemos identificar las dependencias entre sistemas: identificación de sistemas con los que existen dependencias, identificación de interlocutores, requisitos Waterfall, etc. Responsable: Integradores / Arq. Func.

Planificación a nivel de Testing

Debemos establecer una estrategia de pruebas, tanto las propias del equipo agile como de posibles equipos externos que participen en la construcción del producto. Una posible estrategia de pruebas podría ser la siguiente:

Pruebas Unitarias

El Equipo de Desarrollo hace unas pruebas mínimas para verificar que lo construido funciona. Implicaría pruebas del backend y del frontend.

Pruebas Funcionales

El tester realiza una batería de pruebas funcionales verificando la cobertura de las Historias de Usuario. Serían pruebas tanto automatizadas como manuales. Estas pruebas deberán registrarse en una herramienta como por ejemplo ALM.

Pruebas de Integración

El Equipo de Integración (los integradores del DevTeam): front.

Pruebas de Regresión

El tester realiza una batería de pruebas de las funcionalidades ya entregadas para verificar su correcto funcionamiento. Suelen ser automáticas y se realizan sobre las funcionalidades más importantes.

Pruebas de Carga (o Performance)

Un Equipo de Rendimiento realiza una serie de pruebas para verificar que la aplicación soporta la carga de usuarios o transacciones que se espera que asuma la aplicación antes de subir a Producción. La petición y coordinación con este equipo la realiza normalmente el tester del Equipo de Desarrollo.

Sonar

Hay que tener en cuenta la parte correspondiente a cobertura de pruebas obligatoria por SoNar a cualquier proyecto Java que tiene que estar por encima de un determinado porcentaje (por ejemplo, el 65%) y conlleva un porcentaje a tener en cuenta sobre la construcción.

Planificación a nivel de Metodología

Definition of Ready (DoR)

El Equipo de Desarrollo y el Product Owner deberán establecer los criterios del DoR. Veremos este punto en posteriores artículos.

Definition of Done (DoD)

Mínimos de calidad

Tablero físico vs virtual.

¿Vamos a usar Jira o alguna herramienta semejante que contenga el Product Backlog y el panel Scrum? ¿o vamos a ir de minimalistas y nos va a bastar con una pared y unos posits? Te recomiendo que le eches un vistazo a este artículo: Product Backlog físico vs Product Backlog virtual.

Por otra parte, ¿cómo va a ser la estructura del panel Scrum? ¿las tres columnas típicas de TO DO, IN PROGRESS y DONE? ¿o necesitarás añadir alguna columna más, por ejemplo IN TEST, BLOCKED, etc?

Creación del proyecto en Jira/Confluence.

Configuración del proyecto en Jira: clave del proyecto en Jira, issue types que utilizaremos, fields, screens, workflows por cada issue type, política de roles y permisos, creación de los boards o paneles, etc.

De hecho, el proyecto en Jira debería haberse creado más pronto que tarde para que el Product Owner vaya creando directamente allí las historias de usuario. Sin embargo, muchas veces estas historias comienzan a crearse antes de realizar este trámite, normalmente en una excel, y después debe el Product Owner (o alguien en su nombre) hacer el trasvase de historias de la dichosa excel a Jira. Pérdida de tiempo absoluta…

Definición de la estructura en Confluence.

Si vamos a utilizar Confluence, o cualquier otro software colaborativo, deberemos al igual que pasa en Jira haber creado el proyecto en esta plataforma. Además, deberemos tener una idea cuanto menos de la estructura que tendrá nuestro repositorio de información.

Formación metodológica

Por parte del Scrum Master al Product Owner y al Equipo de Desarrollo, en el caso de que no tengan experiencia con el marco de trabajo.

Acordar la duración del Sprint

Mínimo 1 semana, máximo 4 semanas.

Estimación velocidad inicial

Si el Equipo de Desarrollo es nuevo difícilmente podremos saber qué velocidad estimada presentará, pero si es un equipo que ya ha trabajado anteriormente no es mala idea tener alguna cifra de referencia, por ejemplo 50 storypoints de velocidad. De todas formas, quizá esto sea precipitarse, ya se hablará en la primera Sprint Planning… 

Reflexión final

Como habrás podido observar, hay mucha faena a tener en cuenta antes de comenzar el primer Sprint. Así que tendrás que poner bastante foco al Sprint Cero si no quieres encontrarte con que en el Sprint 1 prácticamente no tienes margen para desarrollar algo de código.

Como te comenté, no alargues demasiado el Sprint Cero, ya que siempre hay cosas que pueden abordarse a la vez que el equipo desarrolla.

Céntrate por tanto en las tareas de Arquitectura, o sea, tener una infraestructura mínima para poder trabajar, y en tener un Product Backlog con las suficientes historias para tener sobre qué trabajar.

Además, ve acotando las dependencias externas desde el principio, ya que éstas son uno de los principales peligros a los que se enfrenta un equipo ágil a la hora de acabar adecuadamente sus Sprints.

Y como siempre, el Product Owner, con la ayuda del resto del equipo, deberá aunar a todas aquellas personas necesarias para que el Sprint Cero sea provechoso y no queden cabos sueltos.

Te puede interesar:

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario