Glosario de Scrum

El siguiente glosario de términos de Scrum es una traducción de Glossary of Scrum terms, publicado en inglés por Victor Szalvay de la Scrum Alliance.

Gráfico de Burndown

Los gráficos de Burndown muestran el trabajo restante en el tiempo. El trabajo restante es el eje Y y el tiempo es el eje X. El trabajo restante debería subir y bajar y eventualmente tener una tendencia descendente.

Los libros de Scrum definen un Gráfico de Burndown de Sprint como el lugar en donde ver el progreso diario, y un Gráfico de Burndown del Producto en donde ver el progreso mensual (por sprint).

Reunión diaria de Scrum

Una reunión diaria de 15 minutos en donde cada miembro del equipo responde 3 preguntas:

1. ¿Qué hice desde la última reunión de Scrum? (por ejemplo, ayer)
2. ¿Qué voy a hacer para la próxima reunión de Scrum? (por ejemplo, mañana)
3. ¿Qué me impide realizar mi trabajo lo más eficientemente posible?

El ScrumMaster se asegura que los participantes organicen reuniones aparte para cualquier discusión que exceda a estas tres preguntas.

Los libros de Scrum recomiendan que esta reunión sea lo primero que ocurra a la mañana, ni bien lleguen todos los miembros del equipo.

Impedimentos

Un impedimento es cualquier cosa que le impida al equipo desempeñarse lo más eficientemente posible. Cada miembro del equip puede anunciar un impedimento durante la Reunión diaria de Scrum. El ScrumMaster está a cargo de resolver los impedimentos. Los ScrumMaster a menudo organizan reuniones paralelas cuando no se puede resolver un impedimento en la reunión diaria de Scrum.

Backlog del producto

El Backlog del Producto (o "backlog") contiene los requerimientos del sistema, expresados como una lista priorizada de elementos del backlog del producto. Esto incluye requerimientos del cliente funcionales y no-funcionales, y también requerimientos técnicos generados por el equipo. Aunque existen muchas entradas al backlog del producto, el Dueño del Producto es el único responsable por priorizar los elementos del backlog.

Durante la reunión de planificación del sprint, los elementos del backlog se mueven del backlog del producto hacia un sprint, basándose en las prioridades establecidas por el Dueño del Producto.

Elemento del backlog del producto

En Scrum, un elemento del backlog del producto ("PBI", "elemento del backlog", o "elemento") es una unidad de trabajo lo suficientemente pequeña para que el equipo pueda completarla en un sprint (iteración). Los elementos del backlog se descomponen en una o más tareas.

Ver también unidad de estimación de esfuerzo del backlog.

Esfuerzo para un elemento del backlog del producto

Algunas personas estiman es esfuerzo de los elementos del backlog del producto en días ideales, aunque otras personas prefieren unidades de estimación menos concretas. Las unidades alternativas pueden ser puentos de historia, puntos de función, o "tamaños de remera" (1 para pequeño, 2 para medio, etc.). La ventaja de estas unidades más vagas es que son explícitas en distinguir que el esfuerzo de los elementos del backlog del producto no son estimaciones de duración. También, las estimaciones a este nivel son aproximaciones burdas que nunca deben confundirse con horas de trabajo reales.

Nótese que las tareas del sprint son distintas de los elementos del backlog del sprint, y el esfuerzo restante de las tareas siempre se estima en horas.

Gráfico de burndown del producto

En Scrum, el gráfico de burndown del producto es una vista "general" del progreso del proyecto. Muestra cuánto trabajo restante hay al comienzo de cada sprint. El alcance de este gráfico abarca todas las entregas; sin embargo, un gráfico de burndown de entrega se limita a una única entrega.

Rol de Dueño del Producto

En Scrum, hay una única persona que tiene la autoridad final representando los intereses del cliente, priorizando el backlog y respondiendo preguntas sobre los requerimientos.

Esta persona debe estar disponible para el equipo en cualquier momento, especialmente durante la reunión de planificación del sprint y durante la reunión de demo del sprint.

Los desafíos de ser un Dueño del producto:

1. Resistir la tentanción de "gestionar" al equipo. El equipo puede no organizarse de la forma esperada. Esto resulta especialmente dificil si algunos miembros del equipo piden la intervención sobre temas que el equipo debería resolver por si mismos.
2. Resistir la tentación de agregar más trabajo importante después de iniciado un Sprint.
3. Estar dispuesto a tomar decisiones difíciles durante la reunión de planificación del sprint.
4. Balancear los intereses opuestos de interesados externos.

Entrega

Una entrega es la transición de un incremento potencialmente productivo del producto en algo que los clientes usen rutinariamente. Las entregas suelen ocurrir cuando uno o más sprints resultan en que el producto tiene suficiente valor como para superar el costo de desplegarlo.

"El producto se entrega al cliente o a las obligaciones del mercado. La entrega balancea funcionalidad, costo, y requerimientos de calidad contra la fecha comprometida". (Schwaber/Beedle, Agile Software Development with Scrum, p. 80).

Gráfico de burndown de la entrega

En Scrum, el gráfico de burndown de la entrega brinda una visión "general" sobre el progreso de la entrega. Muestra cuánto trabajo queda hacer al principio de cada sprint, para una única entrega. El alcance de este gráfico es una única entrega; sin embargo, un gráfico de burndown del producto abarca todas las entregas.

Roles de Scrum

Hay tres roles en cualquier proyecto de Scrum:

• Dueño del producto
• ScrumMaster
• Equipo

Rol de ScrumMaster

El ScrumMaster es una facilitador para el equipo y para el Dueño del Producto. En vez de gestionar al equipo, el ScrumMaster trabaja para asistir tanto al equipo como al Dueño del Producto de la siguiente forma:

• Quitar las barreras entre el desarrollo y el dueño del producto, de manera que el dueño del producto pueda dirigir directamente el desarrollo.
• Enseñarle al dueño del producto cómo maximizar el retorno de inversión (ROI), y cumplir sus objetivos usando Scrum.
• Mejorar la vida del equipo de desarrollo, facilitando la creatividad y la toma de decisiones.
• Mejorar la productividad del equipo de desarrollo de cualquier forma posible.
• Mejorar las prácticas de desarrollo y herramientas para que cada incremento de funcionalidad sea potencialmente productiva.
• Mananter información actualizada y visible para todos sobre el progreso del equipo.

Fuente: Agile Project Management with Scrum, Ken Schwaber

Sprint

Una iteración de trabajo durante la cual se implementa un incremento de la funcionalidad del producto. Según el libro, una iteración dura 30 días. Esto es más largo que en otros métodos ágiles para tener en cuenta el hecho de que un incremento funcional del producto tiene que producirse en cada sprint.

El sprint comienza con una reunión de planificación del sprint de un día. Durante el Scrum ocurren muchas reuniones diarias de Scrum (una por día). Al final del sprint ocurre una reunión de demo del sprint, seguida de una reunión de retrospectiva del sprint.

Durante el sprint, el equipo no debe ser interrumpido con pedidos adicionales. Al garantizar que no se interrumpa al equipo permite hacer compromisos reales que se pueden cumplir.

En la práctica, algunos equipos eligen flexibilizar esta regla declarando que algunos miembros están un "80% disposnibles", dejando así tiempo para atender bugs de "máxima prioridad" y emergencias. Sin embargo, esto genera consecuencias no deseables y debe evitarse siempre que sea posible.

Backlog del sprint

Define el trabajo de un sprint, representado por un conjunto de tareas que deben completarse para cumplir los objetivos del sprint, y por un conjunto de elementos seleccionados del backlog del producto.

Gráfico de burndown del sprint

Un gráfico de burndown del sprint muestra el total de horas de tareas restantes por día. Esto nos muestra dónde está el equipo respecto a completar las tareas correspondientes a los elementos del backlog del producto que cumplen el objetivo del sprint. El eje X representa los días del sprint, el eje Y es el esfuerzo restante (usualmente en horas ideales).

Para motivar al equipo, el gráfico de burndown del sprint debe mostrarse abiertamente. También actuá como un radiador de información muy efectivo. La alternativa manual a esto es un tablero física, como una pizarra.

Idealmente el gráfico va descendiendo hasta el cero al final del sprint. Si los miembros del equipo informan de forma realista las horas restantes, la línea debería subir y bajar caóticamente. Esto demuestra porqué el concepto de "porcentaje de terminado" de la gestión tradicional no funciona.

Objetivos del sprint

Los objetivos del sprint son el resultado de la negociación entre el Dueño del producto y el equipo de desarrollo.

Los objetivos útiles son aquellos específicos y mediables. En vez de "mejorar la escalabilidad", debemos decir "manejar cinco veces más de usuarios que en la versión 0.8".

Scrum se enfoca en objetivos que resultan en un producto demostrable. El Dueño del Producto tiene el derecho a esperar un producto demostrable (sin importar qué tan pequeño sea) a partir del primer sprint. En el desarrollo iterativo, los sprints siguientes incrementarán la robustez y cantidad de las características.

El equipo tiene que comprometerse a objetivos que todos puedan ver si se cumplieron (o no) al final del sprint. En la reunión de demo, se demuestra el sprint y el equipo le pregunta al dueño del producto si siente que se cumplieron los objetivos.

Aunque algunos elementos del backlog del producto específicos pueden no estar terminados al final del sprint, debería ser un hecho muy inusual que el equipo no cumpla con el objetivo del sprint. Scrum requiere que se notifique cuanto antes al dueño del producto cuando se hace descubre que no podrán cumplirse los objetivos.