Seamos ágiles con Scrum (VI) – Conceptos básicos: Desarrollador, ítems y tareas del Sprint Backlog, eventos de un Sprint
on Thu Jul 01 2021
Gentil introducción
Este serie de publicaciones describe paso por paso los conceptos más importantes de Scrum, así como la forma en que pueden ser aplicados en una organización real.
Puedes acceder a toda la serie a través de estos enlaces:
Primera parte – El agilismo y el manifiesto ágil.
Segunda parte – Conceptos básicos: La guía de Scrum, Product Backlog, Items y User Stories
Cuarta parte – Cómo medir el progreso de desarrollo
Quinta parte – Conceptos básicos: El Scrum Master, el equipo de desarrollo, y Scaled Scrum
Sobre la guía de Scrum 2020: Esta serie de publicaciones se encuentra en construcción, y su contenido se basa íntegramente en la guía de Scrum de 2017. Finalizada la publicación de la serie, se trabajará en actualizar el contenido a la última versión de la guía de Scrum.
Qué esperar de esta publicación
En la publicación anterior nos centramos principalmente en definir el rol de Scrum Master, y explicar de forma muy resumida cómo debía conformarse un equipo de más de nueve desarrolladores.
Esta publicación continuará introduciendo conceptos básicos, y expondrá quien debe ser considerado un desarrollador, qué elementos podemos encontrar en el Sprint Backlog, y qué eventos encontramos durante el transcurso de un Sprint.
Un desarrollador no es sólo quien programa
Constantemente hemos introducido el término “desarrollador” y “equipo de desarrollo” durante todas las publicaciones. Podríamos resumir que, dentro de todos los roles que intervienen en Scrum (Product Owner, Scrum Master, etcétera) encontramos el del desarrollador, y que la suma de todos los desarrolladores conforma el equipo de desarrollo.
¿Pero, a quien debemos considerar desarrollador? La palabra puede inducir a confusión, dado que la reacción natural puede ser pensar en un desarrollador de Software. No obstante Scrum considera bajo el paraguas del término “desarrollador” a cualquier persona que participe en la concepción y construcción del producto.
¿Significa esto que un diseñador es parte de equipo de desarrollo? En efecto, un desarrollador puede ser parte del equipo de desarrollo. De hecho, uno de los valores que Scrum establece como requisito, es que el equipo debe articularse como un equipo multi-disciplinar. Esto, no significa que cada persona del equipo deba conocer todas las disciplinas que le sean posibles, sino que el equipo en su conjunto, debe reunir a personas de diferentes disciplinas, de forma en que el producto logre desarrollarse de forma autónoma, sin requerir de equipos externos o de terceros.
Durante su trabajo, cada desarrollador debe focalizarse sólo en el desarrollo de un ítem del Sprint Backlog, asegurando el foco en una única tarea simultáneamente.
Qué encontramos en el Sprint Backlog
En la tercera publicación de esta serie ya adelantamos que los Sprints se planificaban durante un Sprint Planning, en el que definíamos el objetivo de Sprint o Sprint Goal, y el Sprint Backlog.
¿Pero, qué podemos encontrar dentro del Sprint Backlog? Principalmente dos elementos:
- En primer lugar, los ítems que hemos seleccionado del Product Backlog durante la planificación del Sprint.
- Las tareas que, dentro de cada ítem, descomponen el trabajo que debe realizarse para completar la tarea. (En la certificación de Scrum.org, a estas tareas se las denomina como “work”).
A modo de conclusión, podríamos decir que durante el Sprint Planning definimos el Sprint Backlog, que acabará componiéndose de esos dos elementos. La responsabilidad de definir el Sprint Backlog es enteramente del equipo de desarrollo, especialmente teniendo en cuenta que el equipo de desarrollo es quien mejor conoce su capacidad de desarrollo durante un Sprint.
Por otro lado, el objetivo de Sprint o Sprint Goal, se decidirá antes de empezar a definir el Sprint Backlog, y en esta decisión se implicará todo el equipo de Scrum al completo.
Eventos de un Sprint
En anteriores publicaciones hemos introducido diversos eventos (nótese que existen algunas personas que los denominan reuniones, mecánicas, rituales, ceremonias, u otros adjetivos, pero su denominación según la guía de Scrum es “eventos”). El Scrum daily (del cual hablaremos más adelante) o el Sprint Planning, son algunos de ellos.
En Scrum existen un número concreto de eventos durante el transcurso de un Sprint, que además tienen una duración concreta determinada, y suceden en un orden específico.
Los eventos que suceden durante un Sprint, son los siguientes:
- Sprint Planning: Nos permite planificar el contenido del Sprint Goal y Sprint Backlog. Es el primer evento que tiene lugar durante el Sprint.
- Scrum Daily: Permite al equipo de desarrollo sincronizarse entre sí. Tiene lugar al inicio de cada día.
- Sprint Review: Permite enseñar al cliente y otras personas interesadas el avance e incremento generado, y recibir feedback con el que ajustar los subsiguientes desarrollos. Tiene lugar una vez por Sprint, al final de éste.
- Sprint Retrospective: Gracias a las retrospectivas, el equipo puede mejorar la forma en la que trabaja, analizar el flujo de trabajo y decidir como mejorarlo, eliminando impedimentos y potenciando soluciones. Es el último evento del Sprint, después del Sprint Review, y tiene lugar una única vez en todo el Sprint.
En sucesivas publicaciones se explicará en mayor detalle las características de cada uno de los eventos, su duración, así como prácticas recomendadas, pero por el momento la lista anterior permite tener visibilidad de todos los eventos que tienen lugar durante un Scrum.
Conclusión
Ahora ya sabemos qué podemos encontrar dentro del Sprint Backlog, quien debe ser considerado un desarrollador, y qué es un evento de un Sprint, y qué eventos podemos encontrar.
En la próxima publicación, profundizaremos y aclararemos algunos conceptos más sobre la definición de acabado o Definition of Done, y seguiremos avanzando en conceptos básicos de Scrum.