Vocabulario Scrum

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 Scrum Master 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 equipo puede anunciar un impedimento durante la Reunión diaria
de Scrum. El Scrum Master está a cargo de resolver los impedimentos. Los Scrum Master 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 historias de usuarios, 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 tentación de "gestionar" al equipo. El equipo puede no organizarse de la forma

esperada. Esto resulta especialmente difícil 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

• Scrum Master
• Equipo
Rol de Scrum Master
El Scrum Master es un facilitador para el equipo y para el Dueño del Producto. En vez de
gestionar al equipo, el Scrum Master 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 productivo.
• 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% disponibles", 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ísico, 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.
Reunión de planificación del sprint
La reunión de planificación del sprint es una negociación entre el equipo y el dueño del producto
sobre lo que el equipo hará durante el siguiente sprint.
El dueño del producto y todos los miembros del equipo acuerdan un conjunto de objetivos para
el sprint, el cual se usa para determinar los elementos del backlog del producto comprometidos.
A menudo se definen nuevos elementos del backlog durante esta reunión. Esta parte de la
reunión de planificación del sprint está acotada a 4 horas.
Usualmente el equipo deja libre al dueño del producto de la reunión, y comienza a descomponer
los elementos del backlog en tareas. El dueño del producto sigue estando disponible en esta
fase para renegociar o para responder preguntas que afecten las estimaciones. Esta parte de
la reunión está acotada a 4 horas. Algunos equipos insertan tareas "recordatorias" (con
estimaciones groseras) para los elementos del backlog del producto que no esperan comenzar
hasta más tarde en el sprint.
Reunión de retrospectiva del sprint
La reunión de retrospectiva del sprint se realiza al final de cada sprint, después de la reunión de
demo del sprint. El equipo y el Scrum Master se juntan para discutir lo que salió bien y lo que
necesita mejorarse en el próximo sprint. El dueño del producto no asiste a esta reunión.
La retrospectiva del sprint está acotada a 3 horas.
Kelley Louie (Certified Scrum Practitioner) escribe: "La reunión de retrospectiva del sprint es una
paret integral del proceso de inspección-y-adaptación. si no, el equipo nunca podrá mejorar su
salida general y no podrá enfocarse en el rendimiento general del equipo. El Scrum Master tiene
que prestar atención a esta reunión y trabajar en resolver los impedimentos que puedan estar
retrasando al equipo".
Tarea del sprint
En Scrum, una tarea del sprint (o tarea) es una unidad de trabajo generalmente entre 4 y 16
horas. Los miembros del equipo se asignan voluntariamente las tareas. Actualizan la estimación
de horas restantes de forma diaria, influenciando así el gráfico de burndown del sprint. Las
tareas están contenidas dentro de elementos del backlog.
Scrum fomenta dividir una tarea en muchas si el estimado excede las 12 horas.
Equipo
El equipo (o "Equipo de Scrum") está compuesto idealmente de 7 más/menos dos personas.
Para los proyectos de desarrollo de software, los miembros del equipo suelen ser una mezcla
de ingenieros de software, arquitectos, programadores, analistas, expertos de QA, testers,
diseñadores de interfaz de usuario, etc. A menudo esto se llama "equipos de proyectos multi-
disciplinarios". Las prácticas ágiles también fomentan a miembros del equipo multi-
disciplinarios.
Durante un sprint, el equipo se autoorganiza para cumplir los objetivos del sprint. El equipo tiene
autonomía para elegir cómo cumplir las metas, y es responsable por eso. El Scrum Master actúa
como guardián para asegurarse que el equipo esté protegido del dueño del producto.
Scrum también promueve ubicar al equipo completo en una misma habitación.
Miembro del equipo
Un miembro del equipo es cualquier persona que está trabajando en las tareas del sprint para
cumplir el objetivo del sprint.
Velocidad
En Scrum, la velocidad es cuánto esfuerzo del backlog del producto el equipo puede manejar
en un sprint. Esto puede estimarse viendo los sprint pasados, asumiendo que la composición
del equipo y la duración del sprint se mantienen constante. También puede establecerse sprint-
a-sprint, usando una planificación basada en compromisos.
Una vez establecida, la velocidad puede usarse para planificar proyectos y predecir entregas y
fechas de terminación del producto.
¿Cómo puede ser que el cálculo de la velocidad tenga sentido cuando los elementos del backlog
son estimados de forma grosera? La regla de los números grandes tiende a promediar las
imperfecciones de las estimaciones.