Los términos de la Guía Scrum, explicados.
34 términos de Scrum con el nombre en inglés que usa el examen y, cuando hace falta, cómo suele aparecer en él.
- Empiricismempirismo
La base de Scrum: el conocimiento viene de la experiencia y las decisiones se toman sobre lo que se observa, no sobre lo que se predijo. Se apoya en tres pilares: transparencia, inspección y adaptación.
En el examen. Si una opción propone planificar todo por adelantado para no tener que cambiar, contradice el empirismo.
Empirismo y valores- Lean thinkingpensamiento lean
La otra base de Scrum junto al empirismo: reducir el desperdicio y concentrarse en lo esencial.
Empirismo y valores- Transparencytransparencia
Que el trabajo y el proceso sean visibles para quienes hacen el trabajo y para quienes lo reciben. Sin transparencia, la inspección engaña y las decisiones aumentan el riesgo.
En el examen. Los artefactos existen para dar transparencia: si un artefacto no es transparente, inspeccionarlo lleva a malas decisiones.
Empirismo y valores- Inspectioninspección
Revisar con frecuencia los artefactos y el avance hacia los objetivos para detectar a tiempo desviaciones o problemas. Cada evento de Scrum es una ocasión de inspección.
Empirismo y valores- Adaptationadaptación
Ajustar el proceso o el producto en cuanto la inspección muestra que algo se salió de lo aceptable. Cuanto antes se ajusta, menos se desvía.
En el examen. Adaptar es más difícil si las personas no tienen autonomía: por eso Scrum pide equipos autogestionados.
Empirismo y valores- Scrum Valuesvalores de Scrum
Compromiso, foco, apertura, respeto y coraje (Commitment, Focus, Openness, Respect, Courage). Cuando el equipo los vive, los pilares del empirismo cobran vida y se construye confianza.
En el examen. Son cinco. Pregunta frecuente: cuál no es un valor de Scrum (por ejemplo, «transparencia», que es un pilar).
Empirismo y valores- Scrum Teamequipo Scrum
Una unidad pequeña con un Scrum Master, un Product Owner y Developers, sin subequipos ni jerarquías, enfocada en un solo objetivo a la vez: el Product Goal. Suele tener diez personas o menos.
En el examen. No hay «líder técnico», «tester» ni subequipos dentro del Scrum Team: todos los que construyen son Developers.
El Scrum Team- Accountabilitiesresponsabilidades
La Guía 2020 habla de tres responsabilidades, no de roles ni de cargos: Product Owner, Scrum Master y Developers. Cada una responde por algo distinto dentro del mismo equipo.
El Scrum Team- Product Ownerdueño del producto
Responde por maximizar el valor del producto: desarrolla y comunica el Product Goal, crea y ordena los elementos del Product Backlog y se asegura de que sea transparente y se entienda. Es una persona, no un comité.
En el examen. Puede delegar trabajo en otros, pero sigue siendo quien responde. Para cambiar el Product Backlog, hay que convencerlo a él.
El Scrum Team- Scrum MasterScrum Master
Responde por la efectividad del Scrum Team y por que Scrum se aplique como lo define la Guía. Sirve al equipo, al Product Owner y a la organización: enseña, facilita y ayuda a retirar impedimentos.
En el examen. Es un líder que sirve («true leader who serves»). No asigna tareas ni es el jefe de los Developers.
El Scrum Team- Developersdesarrolladores
Las personas del Scrum Team que crean cualquier parte de un Increment utilizable en cada Sprint. Responden por el Sprint Backlog, por la calidad (cumplir la Definition of Done) y por adaptar su plan cada día.
En el examen. «Developer» no significa programador: incluye a quien analiza, diseña, prueba o documenta.
El Scrum Team- Self-managingautogestionado
El Scrum Team decide internamente quién hace qué, cuándo y cómo. La Guía 2020 usa «self-managing» en lugar del «self-organizing» de versiones anteriores.
En el examen. Si la opción es que alguien de fuera (o el Scrum Master) reparta el trabajo, casi siempre es la incorrecta.
El Scrum Team- Cross-functionalmultifuncional
El Scrum Team tiene todas las habilidades necesarias para crear valor en cada Sprint, sin depender de otros equipos.
El Scrum Team- Stakeholdersinteresados
Las personas con interés en el producto: clientes, usuarios, patrocinadores. No forman parte del Scrum Team; el Product Owner los representa y colaboran sobre todo en la Sprint Review.
El Scrum Team- SprintSprint
El evento que contiene a todos los demás: un periodo fijo de un mes o menos en el que se convierte una idea en valor. Un Sprint empieza en cuanto termina el anterior.
En el examen. Durante el Sprint no se hacen cambios que pongan en peligro el Sprint Goal ni se baja la calidad; el alcance se puede aclarar y renegociar con el Product Owner.
Eventos- Timeboxcaja de tiempo
Duración máxima de un evento. Para un Sprint de un mes: Sprint Planning de 8 horas como máximo, Daily Scrum de 15 minutos, Sprint Review de 4 horas y Sprint Retrospective de 3 horas; con Sprints más cortos, suelen ser más cortos.
En el examen. Es un máximo, no una duración obligatoria. La Daily Scrum dura 15 minutos sea cual sea el largo del Sprint.
Eventos- Sprint Planningplanificación del Sprint
Inicia el Sprint. Todo el Scrum Team responde tres preguntas: por qué este Sprint es valioso (el Sprint Goal), qué se puede terminar y cómo se hará el trabajo.
En el examen. Se pueden invitar personas de fuera para aportar consejo, pero el plan lo hace el Scrum Team.
Eventos- Daily ScrumScrum diario
Evento de 15 minutos para los Developers, cada día del Sprint a la misma hora y en el mismo lugar, para inspeccionar el avance hacia el Sprint Goal y adaptar el Sprint Backlog.
En el examen. Es de los Developers. Las tres preguntas clásicas no son obligatorias, y el Scrum Master no tiene que dirigirla: se asegura de que ocurra.
Eventos- Sprint Reviewrevisión del Sprint
Sesión de trabajo con los interesados para inspeccionar el resultado del Sprint y decidir las siguientes adaptaciones. El Product Backlog puede ajustarse a partir de lo que se aprende.
En el examen. No es solo una demostración ni una aprobación formal: es colaboración sobre qué hacer después.
Eventos- Sprint Retrospectiveretrospectiva del Sprint
Cierra el Sprint. El Scrum Team revisa cómo trabajó (personas, interacciones, procesos, herramientas y su Definition of Done) y elige las mejoras más útiles; pueden entrar en el siguiente Sprint Backlog.
En el examen. Es de todo el Scrum Team, Product Owner incluido, y es el último evento del Sprint: va después de la Sprint Review.
Eventos- Product Backlog refinementrefinamiento del Product Backlog
Actividad continua (no un evento) de dividir y detallar los elementos del Product Backlog: descripción, orden y tamaño. Los Developers que harán el trabajo son quienes los dimensionan.
En el examen. La Guía 2020 no le pone un tiempo máximo ni un porcentaje del Sprint.
Eventos- Sprint cancellationcancelar un Sprint
Un Sprint se puede cancelar si el Sprint Goal pierde sentido. Solo el Product Owner tiene autoridad para hacerlo.
En el examen. Ni el Scrum Master ni los Developers ni los interesados pueden cancelarlo; pueden influir en el Product Owner.
Eventos- Commitmentscompromisos
Cada artefacto tiene un compromiso que da transparencia y foco: el Product Backlog, el Product Goal; el Sprint Backlog, el Sprint Goal; el Increment, la Definition of Done.
En el examen. Pregunta típica: emparejar cada artefacto con su compromiso.
Artefactos y compromisos- Product Backloglista del producto
Lista ordenada y emergente de lo que se necesita para mejorar el producto. Es la única fuente de trabajo del Scrum Team y la mantiene el Product Owner.
En el examen. Es «ordenada», no solo «priorizada»: el orden puede depender de valor, riesgo o dependencias.
Artefactos y compromisos- Product Goalobjetivo del producto
El estado futuro del producto hacia el que trabaja el Scrum Team; es el compromiso del Product Backlog. El equipo debe cumplirlo (o abandonarlo) antes de tomar el siguiente.
En el examen. Novedad de la Guía 2020. Hay un solo Product Goal a la vez.
Artefactos y compromisos- Sprint Backloglista del Sprint
El Sprint Goal, los elementos del Product Backlog elegidos para el Sprint y el plan para entregarlos. Es de los Developers y se actualiza durante todo el Sprint.
En el examen. Solo los Developers lo cambian. El Product Owner no les agrega trabajo a mitad del Sprint.
Artefactos y compromisos- Sprint Goalobjetivo del Sprint
El único objetivo del Sprint, el compromiso del Sprint Backlog. Da coherencia y foco, y deja flexibilidad sobre el trabajo exacto para lograrlo.
En el examen. Si el trabajo resulta distinto de lo previsto, los Developers renegocian el alcance con el Product Owner sin cambiar el Sprint Goal.
Artefactos y compromisos- Incrementincremento
Un paso concreto hacia el Product Goal que se suma a todos los anteriores, verificado para que funcione con ellos. Para ser Increment tiene que cumplir la Definition of Done.
En el examen. Puede haber varios Increments en un Sprint y entregarse antes de que termine: la Sprint Review no es una puerta de liberación.
Artefactos y compromisos- Definition of Donedefinición de terminado
La descripción formal del estado que debe tener el Increment para cumplir la calidad exigida; es el compromiso del Increment. Si un elemento no la cumple, no se presenta en la Sprint Review y vuelve al Product Backlog.
En el examen. Si la organización tiene una, el Scrum Team la cumple como mínimo. Si varios equipos trabajan en el mismo producto, comparten una sola.
Artefactos y compromisos- Story points y velocitypuntos de historia y velocidad
Técnicas habituales para estimar y medir cuánto termina un equipo por Sprint. La Guía Scrum no las exige ni las menciona: el equipo usa las que le sirvan.
En el examen. Si una opción dice que Scrum «requiere» story points o velocity, es falsa.
Fuera de la Guía- Burndown chartgráfico de trabajo pendiente
Gráfico del trabajo que queda en el tiempo. Útil, pero opcional: la Guía dice que se pueden usar prácticas de pronóstico, sin imponer ninguna.
En el examen. No sustituye al empirismo: lo que pasó importa más que lo que se proyecta.
Fuera de la Guía- User storyhistoria de usuario
Formato muy usado para escribir elementos del Product Backlog. La Guía no exige ningún formato.
Fuera de la Guía- Sprint 0, hardening y release SprintsSprints especiales
Sprints «de preparación», «de estabilización» o «de liberación» que algunas organizaciones usan. No existen en Scrum: cada Sprint produce al menos un Increment terminado.
En el examen. Si la opción propone un Sprint sin Increment para preparar o estabilizar, es incorrecta.
Fuera de la Guía- Definition of Readydefinición de listo
Lista de criterios para que un elemento del Product Backlog pueda entrar en un Sprint. Práctica opcional que la Guía no menciona; la Guía habla de elementos «ready» tras el refinamiento.
En el examen. No confundirla con la Definition of Done, que sí es parte de Scrum.
Fuera de la Guía
Contenido original de PMNOVA. No afiliado ni respaldado por Scrum.org.