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 retrospectiva 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