En este glosario definimos, de forma breve, algunos de los conceptos más utilizados por la comunidad Agile, en sentido amplio, no solo aquellos relacionados con Scrum. Esperamos que este Glosario Agile sea un recurso útil para Scrum Masters, Product Owners, Desarrolladores, Agile Coaches y líderes en toda clase de empresas. A menudo encontrarás enlaces con los que profundizar en la materia, cuya lectura te recomendamos.
Se predica de un equipo cuando este es el que decide sobre cómo realizar su propio trabajo, sin injerencias externas. En Scrum, el propio Equipo Scrum debe ser autoorganizado.
Es un gráfico que muestra el trabajo restante estimado dentro de un Backlog (Product Backlog o Sprint Backlog), medido, por ejemplo, en horas o en puntos de historias de usuario. El eje horizontal muestra el tiempo, y el eje vertical el trabajo restante estimado. Lo normal es que, conforme pasa el tiempo, el trabajo restante vaya disminuyendo.
Es una forma gráfica de expresar la idea de que la variabilidad de las estimaciones disminuye a medida que un proyecto avanza. Al principio, no obstante, la variabilidad o margen de error de las estimaciones en proyectos de software es muy notable. Puedes leer más sobre el cono de la incertidumbre en este artículo.
Con el paso de los años, han ido surgiendo multitud de certificaciones que acreditan el dominio de Scrum, ya sea como Scrum Master, Product Owner, Desarrollador, Agile Coach, etc. Las más populares y reconocidas son las de Scrum.org y Scrum Alliance. En este sentido, hemos elaborado una guía de preparación de PSM I.
Modelo de liderazgo que encuadra las diversas situaciones en cinco contextos, con objeto de modular el proceso de toma de decisiones según aquellos. Dichos contextos son: simple, complicado, complejo, caótico y desorden. En este artículo ahondamos sobre la importancia del Cynefin framework.
Reunión por y para los Desarrolladores del Equipo Scrum que tiene lugar cada día, con una duración máxima de 15 minutos, y cuyo fin es evaluar el progreso hacia el Objetivo del Sprint.
Es el entendimiento compartido sobre aquellos requisitos que un elemento del Product Backlog y la totalidad del Incremento tienen que cumplir para considerar que el trabajo de desarrollo asociado ha concluido. Es creada por el Equipo Scrum (si la organización carece de una) y los Desarrolladores han de adherirse a ella. Puedes ampliar y ver ejemplos de la Definición de hecho en este artículo.
Costes indirectos asociados al mantenimiento de un producto, resultado de malas prácticas o decisiones de diseño. La deuda técnica mengua nuestra capacidad para afrontar nuevos desarrollos e innovar.
Consiste en la toma de decisiones basada en la experiencia, en lo que ya ha sucedido. Sus tres pilares son la transparencia, la inspección y la adaptación.
Se integra por un Scrum Master, un Product Owner y los Desarrolladores.
Son una serie de dinámicas para celebrar reuniones en un formato alternativo al tradicional, como 1-2-4-All, Troika Consulting o 15% Solutions. Si quieres saber más, puedes consultar nuestra guía sobre las estructuras liberadoras.
Framework agile para el desarrollo de software que persigue producir software de alta calidad, así como mejorar la calidad de vida de los Desarrolladores. Introduce prácticas de desarrollo como las historias de usuario, el pair programming o refactoring, entre otras.
Es algo así como “la Biblia de Scrum”, creada y mantenida por los creadores de Scrum, Ken Schwaber y Jeff Sutherland. Puedes leer la versión en español de la Guía Scrum en este enlace.
Forma de expresar los requerimientos de un producto en términos de valor para el cliente o usuario. Por ejemplo: “Como usuario lector (tipo de usuario), puedo registrarme en la plataforma (acción), para así poder comprar libros (beneficio)”. Fueron popularizadas por el Extreme Programming y su uso no es obligatorio en Scrum.
Hace referencia a profesionales que, además de poseer una determinada especialidad (en vertical), cuentan con otras competencias (en horizontal) con las que contribuir al proyecto. Por ejemplo, puede que un desarrollador de front-end también pueda asumir tareas de testing o back-end. Favorecer equipos con habilidades en forma de T nos ayuda a “ir todos a una” y a terminar los elementos ya empezados, minimizando el trabajo en curso. En este post profundizamos sobre las habilidades en forma de T.
Funcionalidad o iteración de un producto, que se añade e integra con todos los incrementos anteriormente creados. Más información sobre el Incremento de producto aquí.
Estrategia de optimización del flujo de valor mediante un proceso visual y que limita el trabajo en curso (sistema “pull”).
Es aquel producto que, de la forma más barata en coste y tiempo, nos permite testear nuestras hipótesis básicas y aprender sobre lo que los clientes quieren. Valga el ejemplo de Groupon, cuyo fundador, Andrew Mason, empezó el servicio con un simple WordPress, generando los primeros cupones en PDF, a mano. Es un concepto popularizado por Eric Ries en Lean Startup.
Denominación acuñada por el Agile Manifesto (2001), en el que 17 líderes de diversas corrientes de desarrollo de software pusieron en común una serie de valores y principios. Comprenden un conjunto amplio de frameworks, técnicas, métodos y prácticas, a saber: Scrum, Extreme Programming, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, Kanban, Lean Manufacturing, Lean Startup, Design Sprint, etc. En este post hablamos sobre los orígenes de las metodologías ágiles.
Se predica de aquellos equipos que poseen todas las habilidades necesarias para crear un producto o funcionalidad de principio a fin, sin dependencias externas.
Es el framework de escalado de Scrum propuesto por Scrum.org, aplicable a 3-9 equipos Scrum que trabajan sobre el mismo producto. Entre otros aspectos, sobresale la creación de un nuevo rol, el Nexus Integration Team. Puedes descargar la Guía Nexus de Scrum.org en este enlace .
Meta que fija el Equipo Scrum durante la Sprint Planning y que guía a este a la hora de completar el trabajo del Sprint. Ha de ser coherente con la funcionalidad o alcance definidos, esto es, cuando dicha funcionalidad o parte sustancial de esta se completan, el Objetivo del Sprint debe conseguirse. Asimismo, la funcionalidad a entregar puede ajustarse si ello contribuye a la consecución del Objetivo establecido. Más información sobre el Objetivo del Sprint o Sprint Goal en este enlace.
Rol dentro de Scrum que asume la responsabilidad de la promoción y correcta implantación de Scrum, ejerciendo un liderazgo sirviente (servant leadership) en beneficio del Product Owner, del Equipo de Desarrollo y de la organización en su conjunto. Aquí hablamos sobre “el buen” Scrum Master|.
Liderazgo que se plasma mediante el servicio a los demás antes que a uno mismo, y que se predica del buen Scrum Master. Mejor que de servant leadership o liderazgo sirviente, nosotros preferimos hablar de liderazgo de nivel 5.
Elemento del Product Backlog orientado a la investigación o experimentación, cuya finalidad es obtener el aprendizaje necesario para implementar la funcionalidad solicitada por el Product Owner o cliente. Es importante que definamos un time-box para el spike. Puedes aprender más sobre cómo utilizar los spikes consultando este artículo.
Iteración o ciclo corto de desarrollo de producto. En Scrum, su duración máxima es de un mes y contiene al resto de eventos del framework. Cada Sprint comienza inmediatamente después del anterior, sin pausas ni fases entre uno y otro. Puedes leer más sobre el Sprint en Scrum aquí.
Artefacto dentro de Scrum que comprende los elementos del Product Backlog seleccionados para el Sprint, así como el plan para transformar esos elementos en un Incremento de producto terminado. Visualmente, suele representarse a través de un tablero Scrum. Amplia la información sobre el Sprint Backlog aquí.
Ceremonia en Scrum que da comienzo al Sprint. En la primera parte de la reunión se decide qué elementos del Product Backlog pasan al Sprint y cuál será el Objetivo de este. En la segunda parte, el Equipo de Desarrollo aborda el cómo realizará la implementación de esos elementos, trazando un plan para el Sprint. Su time-box es de ocho horas para Sprints de un mes.
Reunión dentro de Scrum cuyo propósito es la colaboración entre el Equipo Scrum y los stakeholders invitados por el Product Owner. Incluye una demo del Incremento de producto, que es así inspeccionado, y el feedback generado durante la sesión será utilizado para adaptar el Product Backlog, en su caso. Su time-box es de cuatro horas para Sprints de un mes.
Persona externa al Equipo Scrum, pero con un determinado interés en el producto en el que este se encuentra trabajando. Los stakeholders son gestionados y representados por el Product Owner, quien los invitará a la Sprint Review.
Lista ordenada de todos aquellos requerimientos o funcionalidades conocidos que el producto puede necesitar. Se dice que es “la única fuente de la verdad”, dado que los miembros del Equipo de Desarrollo no deben trabajar en tareas cuyo origen no proceda del Product Backlog. Es un artefacto gestionado por el Product Owner. Amplia la información sobre el Product Backlog aquí.
Es una meta u objetivo a largo plazo para el Equipo Scrum. Da sentido a una sucesión de Sprint Goals y enlaza con la visión para dicho Producto. Explicamos qué es el Product Goal aquí.
Rol dentro de Scrum responsable de la maximización del valor del producto. Se encarga de gestionar el Product Backlog. En este post hablamos sobre las características y funciones del buen Product Owner.
Conjunto de técnicas que Product Owner y Equipo de Desarrollo pueden utilizar para conocer aquello que los clientes quieren y valorar la idoneidad de una determinada funcionalidad. Por ejemplo, las entrevistas con usuarios son una técnica de discovery. Hemos creado una guía de product discovery para ilustrar las técnicas más utilizadas.
Es el acto de añadir detalle y estimaciones a los elementos del Product Backlog. Es realizado por el Equipo de Desarrollo y el Product Owner, y no debe exceder del 10% de la capacidad del Sprint.
Evento dentro de Scrum con el que concluye el Sprint. En esta reunión, el Equipo Scrum en su totalidad trata temas relacionados con el proceso, las herramientas y las relaciones entre personas. Su time-box es de tres horas para Sprints de un mes.
Duración máxima prevista para un evento. Por ejemplo, la Daily Scrum no debe durar más de 15 minutos. En este post hablamos sobre la relevancia del time-box y su cumplimiento.
Cinco valores que representan el espíritu de Scrum como framework, opuesto al uso automatizado de Scrum o “zombie Scrum”. Estos valores son: compromiso, foco, sinceridad, respeto y coraje. Este post puede ayudarte a poner en práctica los valores Scrum.
Medida que alude a la cantidad de unidades de elementos de Product Backlog que el Equipo Scrum transforma en Incremento de producto durante un Sprint. No es una métrica indicativa del valor del producto, sino una medida interna del Equipo Scrum que hace el propio Equipo de Desarrollo.