Index
Básico
- Propósito de la Guía Scrum
- Definición de Scrum
- Teoría de Scrum
Pilares de Scrum
- Valores Scrum
- Scrum Team
- Eventos Scrum
- Artefactos Scrum
- Assess your basic Scrum knowledge
Scrum
Propósito de la Guía Scrum
Scrum se desarrolló a principios de los 90's.
La primera versión de la Guía Scrum fué escrita en 2010, para ayudar a las personas a enteder Scrum.
La Guía Scrum contiene una definición de Scrum.
Cada elemento del marco (framework) sirve a un propósito, que es esencial para el valor general y los resultados obtenidos con Scrum.
Cambiar el diseño del núcleo o ideas de Scrum, omitir elementos o no seguir las reglas de Scrum, encubre problemas y limita los beneficios de Scrum, potencialmente incluso volviéndolo inútil.
A medida que se difunde el uso de Scrum, los desarrolladores, investigadores, analistas, los científicos y otros especialistas hacen el trabajo.
Se usa la palabra "desarrolladores" en Scrum no para excluir, sino para simplificar.
Si obtiene valor de Scrum, considérese incluido.
Definición de Scrum
Scrum es un framework (no es una metodología).
Ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos.
Scrum requiere un Scrum Master para fomentar un entorno donde:
- Un Product Owner ordena el trabajo de un problema complejo en un Product Backlog.
- El Equipo Scrum convierte una selección del trabajo en un Incremento de valor durante un Sprint.
- El equipo Scrum y sus partes interesadas inspeccionan los resultados y se ajustan para el próximo Sprint.
- Repetir (itera)
Scrum es simple.
Pruébelo como está y determine si su
filosofía,
teoría y
estructura ayudan a lograr sus objetivos y crear valor.
Propósito vs objetivos
Propósito vs objetivos
El framework de Scrum está intencionalmente incompleto,
solo define las partes requeridas para implementar la teoría de Scrum.
Scrum se basa en la inteligencia colectiva de las personas que lo utilizan.
En lugar de proporcionar a las personas instrucciones detalladas, las reglas de Scrum guían sus relaciones e interacciones (por esto y otras cosas más no es una metodología).
En lugar de proporcionar a las personas instrucciones detalladas, las reglas de Scrum guían sus relaciones e interacciones (por esto y otras cosas más no es una metodología).
Se pueden emplear varios procesos, técnicas y métodos dentro del framework. Scrum envuelve las prácticas existentes o las hace innecesarias. Scrum hace visible la eficacia relativa de técnicas actuales de gestión, medio ambiente y trabajo, para que se puedan realizar mejoras.
Teoría de Scrum
Scrum se basa en el empirismo y el pensamiento lean.
El empirismo afirma que el conocimiento proviene de la experiencia y de la toma de decisiones con base en lo observado.
El pensamiento Lean reduce el desperdicio y se enfoca en lo esencial.
Scrum emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar el riesgo.
Scrum involucra a grupos de personas que colectivamente tienen todas las habilidades y experiencia para hacer el trabajo y compartir o adquirir las habilidades según sea necesario.
Scrum combina cuatro eventos formales para inspección y adaptación dentro de un evento contenedor, el Sprint.
Estos eventos funcionan porque implementan los pilares empíricos de Scrum de:
- Transparencia,
- Inspección y
- Adaptación.
Transparencia
El proceso y el trabajo emergentes deben ser visibles tanto para quienes realizan el trabajo (scrum team) como para quienes lo reciben (product owner, stakeholders).
Con Scrum, las decisiones importantes se basan en el estado percibido de sus tres artefactos formales.
Los artefactos que tienen poca transparencia pueden llevar a decisiones que disminuyan el valor y aumenten el riesgo.
La transparencia permite la inspección. La inspección sin transparencia es engañosa y derrochadora.
Inspección
Los artefactos de Scrum y el progreso hacia los objetivos acordados deben inspeccionarse con frecuencia y con diligencia para detectar variaciones o problemas potencialmente indeseables.
Para ayudar con la inspección, Scrum proporciona cadencia en forma de sus cinco eventos.
La inspección permite la adaptación. La inspección sin adaptación se considera inútil.
Los eventos Scrum están diseñados para provocar cambios.
Adaptación
Si algún aspecto de un proceso se desvía fuera de los límites aceptables o si el producto resultante es inaceptable, el proceso que se está aplicando o los materiales que se están produciendo deben ajustarse.
El ajuste debe realizarse lo antes posible para minimizar una mayor desviación.
La adaptación se vuelve más difícil cuando las personas involucradas no están empoderadas ni se autogestionan.
Se espera que un Scrum Team se adapte en el momento en que aprenda algo nuevo a través de la inspección.
Valores Scrum
El uso exitoso de Scrum depende de que las personas se vuelvan más competentes en vivir cinco valores:
- Compromiso
- Enfoque
- Apertura
- Respeto
- Coraje
Su enfoque principal es el trabajo del Sprint para lograr el mejor progreso posible hacia estos objetivos.
El equipo Scrum y sus partes interesadas están abiertos sobre el trabajo y los desafíos.
Los miembros del Scrum Team se respetan entre sí para ser personas capaces e independientes, y son respetados como tales por las personas con las que trabajan.
Los miembros del Scrum Team tienen el coraje de hacer lo correcto, de trabajar en problemas difíciles.
Estos valores dan dirección al equipo Scrum con respecto a su trabajo, acciones y comportamiento.
Las decisiones que se toman, los pasos que se toman y la forma en que se usa Scrum deben reforzar estos valores, no disminuirlos ni socavarlos.
Los miembros del Equipo Scrum aprenden y exploran los valores mientras trabajan con los eventos y artefactos de Scrum.
Cuando estos valores son incorporados por el equipo Scrum y las personas con las que trabajan, los pilares empíricos de Scrum de transparencia, inspección y adaptación cobran vida y generan confianza.
Scrum Team
La unidad fundamental de Scrum es un pequeño equipo de personas, un Scrum Team.
El equipo Scrum consta de:
- Un Scrum Master
- Un Product owner
- y Desarrolladores
Es una unidad cohesionada de profesionales enfocados en un objetivo a la vez, la Meta del Producto.
Los Equipos Scrum son multifuncionales, lo que significa que los miembros tienen todas las habilidades necesarias para crear valor en cada Sprint.
También se autogestionan, lo que significa que deciden internamente quién hace qué, cuándo y cómo.
El Equipo Scrum es lo suficientemente pequeño como para seguir siendo ágil y
lo suficientemente grande como para completar un trabajo significativo dentro de un Sprint,
por lo general 10 personas o menos.
En general, hemos descubierto que los equipos más pequeños se comunican mejor y son más productivos.
Si los Equipos Scrum se vuelven demasiado grandes, deberían considerar reorganizarse en múltiples Equipos Scrum cohesivos, cada uno enfocado en el mismo producto. Por lo tanto, deben compartir el mismo objetivo del producto, la lista de trabajos pendientes (Product Backlog) y el propietario del producto (Product Owner).
El Equipo Scrum es responsable de todas las actividades relacionadas con el producto, desde la colaboración de las partes interesadas, la verificación, el mantenimiento, la operación, la experimentación, la investigación y el desarrollo, y cualquier otra cosa que pueda ser necesaria.
Están estructurados y facultados por la organización para gestionar su propio trabajo.
Trabajar en Sprints a un ritmo sostenible mejora el enfoque y la consistencia del Equipo Scrum.
Todo el Equipo Scrum es responsable de crear un Incremento valioso y útil en cada Sprint.
Scrum define tres responsabilidades específicas dentro del Scrum Team:
- Developers (Desarrolladores)
- Product Owner (Propietario del producto)
- Scrum Master (Scrum Master)
Developers
Los desarrolladores son las personas del equipo Scrum que se comprometen a crear cualquier aspecto de un Incremento utilizable en cada Sprint.
Las habilidades específicas que necesitan los desarrolladores son a menudo amplias y variarán según el ámbito del trabajo. Sin embargo, los Desarrolladores siempre son responsables de:
- Crear un plan para el Sprint, el Sprint Backlog;
- Inculcar calidad al adherirse a una Definición de Terminado;
- Adaptar su plan cada día hacia el Sprint Goal; y,
- Haciéndose responsables unos a otros como profesionales.
Product Owner
El Product Owner es responsable de maximizar el valor del producto resultante del trabajo del Scrum Team.
La forma en que se hace esto puede variar ampliamente entre organizaciones, equipos Scrum e individuos.
El propietario del producto también es responsable de la gestión eficaz de la Product Backlog (lista de productos), que incluye:
- Desarrollar y comunicar explícitamente el objetivo del producto;
- Crear y comunicar claramente los elementos de la Lista de Producto (Product Backlog);
- Ordenar los elementos de la lista de productos (Product Backlog); y,
- Asegurarse de que la lista de productos sea transparente, visible y entendida.
Para que los Product Owners tengan éxito, toda la organización debe respetar sus decisiones. Estas decisiones son visibles en el contenido y el orden del Product Backlog, y a través del Incremento inspeccionable en Sprint Review.
El Product Owner es una persona, no un comité. El Product Owner puede representar las necesidades de muchas partes interesadas en el Product Backlog.
Aquellos que quieran cambiar el Product Backlog pueden hacerlo intentando convencer al Product Owner.
Scrum Master
El Scrum Master es responsable de establecer Scrum como se define en la Guía de Scrum.
Hacen esto ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del Equipo Scrum como de la organización.
El Scrum Master es responsable de la efectividad del Scrum Team. Lo hacen al permitir que el equipo Scrum mejore sus prácticas, dentro del marco de Scrum.
Los Scrum Masters son verdaderos líderes que sirven al Scrum Team y a la organización en general.
El Scrum Master sirve al Scrum Team de varias maneras, que incluyen:
- Entrenar a los miembros del equipo en autogestión y funcionalidad cruzada;
- Ayudar al Equipo Scrum a enfocarse en crear Incrementos de alto valor que cumplan con la Definición de Terminado;
- Causar la eliminación de impedimentos para el progreso del Equipo Scrum; y,
- Asegurarse de que todos los eventos de Scrum tengan lugar y sean positivos, productivos y se mantengan dentro del timebox (plazo).
- Ayudar a encontrar técnicas para una definición de objetivos de producto y una gestión del Product Backlog eficaces
- Ayudar al Equipo Scrum a comprender la necesidad de elementos claros y concisos del Product Backlog;
- Ayudar a establecer una planificación empírica de productos para un entorno complejo; y,
- Facilitar la colaboración de las partes interesadas según se solicite o necesite.
- Liderar, capacitar y asesorar a la organización en su adopción de Scrum;
- Planificar y asesorar implementaciones de Scrum dentro de la organización;
- Ayudar a los empleados y las partes interesadas a comprender y aplicar un enfoque empírico para el trabajo complejo; y,
- Eliminando barreras entre las partes interesadas y los equipos Scrum.
Eventos Scrum
El Sprint es un contenedor para todos los demás eventos.
Cada evento en Scrum es una oportunidad formal para inspeccionar y adaptar los artefactos Scrum.
Estos eventos están diseñados específicamente para permitir la transparencia requerida.
No operar cualquier evento según lo prescrito da como resultado la pérdida de oportunidades para inspeccionar y adaptar.
Los eventos se utilizan en Scrum para crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum.
De manera óptima, todos los eventos se llevan a cabo al mismo tiempo y en el mismo lugar para reducir la complejidad.
- Planificación de Sprint (Sprint Planning)
- Sprint
- Scrums diarios (Daily Scrums)
- Revisión de Sprint (Sprint Review)
- Retrospectiva de Sprint (Sprint Retrospective)
El Sprint - Sprint
Los sprints son el latido del corazón de Scrum, donde las ideas se convierten en valor.
Son eventos de duración fija de un mes o menos para crear coherencia.
Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior.
Todo el trabajo necesario para lograr el objetivo del producto, incluida la planificación de Sprint, Scrums diarios, Revisión de Sprint y Retrospectiva de Sprint, ocurre dentro de Sprints.
Durante el Sprint:
- No se realizan cambios que pongan en peligro el Sprint Goal;
- La calidad no disminuye;
- La Lista de Producto se refina según sea necesario; y,
- El alcance se puede aclarar y renegociar con el propietario del producto a medida que se aprende más.
Cuando el horizonte de un Sprint es demasiado largo, el Objetivo del Sprint puede volverse inválido, la complejidad puede aumentar y el riesgo puede aumentar.
Se pueden emplear Sprints más cortos para generar más ciclos de aprendizaje y limitar el riesgo de costo y esfuerzo a un período de tiempo menor.
Cada Sprint puede considerarse un proyecto corto.
Existen varias prácticas para pronosticar el progreso, como burn-downs, burn-ups o flujos acumulativos. Si bien han demostrado su utilidad, no reemplazan la importancia del empirismo.
En entornos complejos, se desconoce lo que sucederá. Solo lo que ya ha sucedido se puede utilizar para la toma de decisiones con miras al futuro.
Un Sprint podría cancelarse si el Sprint Goal se vuelve obsoleto. Solo el propietario del producto tiene la autoridad para cancelar el Sprint.
Planificación de Sprint - Sprint Planning
Sprint Planning inicia el Sprint al establecer el trabajo que se realizará para el Sprint.
Este plan resultante es creado por el trabajo colaborativo de todo el Equipo Scrum.
El Product Owner se asegura de que los asistentes estén preparados para discutir los elementos más importantes del Product Backlog y cómo se asignan al Product Goal.
El equipo Scrum también puede invitar a otras personas a asistir a Sprint Planning para brindar asesoramiento.
Sprint Planning aborda los siguientes temas:
El Product Owner propone cómo el producto podría incrementar su valor y utilidad en el Sprint actual.
Todo el equipo Scrum colabora para definir un Sprint Goal que comunica por qué el Sprint es valioso para las partes interesadas.
El Sprint Goal se debe finalizar antes de que finalice la planificación del Sprint (es decir, durante la Planificación del Sprint se debe definir el objetivo del Sprint).
A través de una conversación con el Product Owner, los desarrolladores seleccionan elementos del Product Backlog (lista de trabajos pendientes del producto) para incluirlos en el Sprint actual.
El Equipo Scrum puede refinar estos elementos durante este proceso, lo que aumenta la comprensión y la confianza.
Seleccionar cuánto se puede completar dentro de un Sprint puede ser un desafío.
Sin embargo, cuanto más sepan los Desarrolladores sobre su desempeño pasado, su próxima capacidad y su Definición de Terminado, más confiados estarán en sus pronósticos de Sprint.
Para cada elemento del Product Backlog item seleccionado, los Desarrolladores planifican el trabajo necesario para crear un Incremento que cumpla con la Definición de Terminado (Definition of Done).
Esto a menudo se hace descomponiendo los elementos del Product Backlog en elementos de trabajo más pequeños de un día o menos. La forma en que se hace esto queda a criterio exclusivo de los Desarrolladores.
Nadie más les dice cómo convertir los elementos del Product Backlog en incrementos de valor.
El Sprint Goal (objetivo del Sprint), los elementos del Backlog de productos seleccionados para el Sprint, más el plan para entregarlos, se denominan juntos Sprint Backlog (Backlog del Sprint).
La planificación del Sprint tiene un límite de tiempo de un máximo de ocho horas para un Sprint de un mes.
Para Sprints más cortos, el evento suele ser más corto (es decir, hay una relación de tiempo propocional al tamaño del sprint).
Scrum diario - Daily Scrum
El propósito del Daily Scrum es inspeccionar el progreso hacia el Sprint Goal y adaptar el Sprint Backlog según sea necesario, ajustando el próximo trabajo planificado.
El Daily Scrum es un evento de 15 minutos para los desarrolladores del equipo Scrum.
Para reducir la complejidad, se lleva a cabo a la misma hora y en el mismo lugar todos los días hábiles del Sprint.
Si el Product Owner o Scrum Master están trabajando activamente en elementos del Sprint Backlog, participan como Desarrolladores.
Los Desarrolladores pueden seleccionar la estructura y las técnicas que deseen, siempre que su Scrum diario se centre en el progreso hacia el Sprint Goal y produzca un plan viable para el siguiente día de trabajo.
Esto crea enfoque y mejora la autogestión.
Los Scrums diarios:
- Mejoran las comunicaciones,
- Identifican impedimentos,
- Promueven la toma de decisiones rápida y, en consecuencia,
- Eliminan la necesidad de otras reuniones.
A menudo se reúnen a lo largo del día para discusiones más detalladas sobre cómo adaptar o volver a planificar el resto del trabajo del Sprint.
Revisión de Sprint - Sprint Review
El propósito de Sprint Review es inspeccionar el resultado del Sprint y determinar adaptaciones futuras.
El equipo Scrum presenta los resultados de su trabajo a las partes interesadas clave y se discute el progreso hacia el objetivo del producto.
Durante el evento, el equipo Scrum y las partes interesadas revisan lo que se logró en el Sprint y lo que ha cambiado en su entorno.
Con base en esta información, los asistentes colaboran sobre qué hacer a continuación.
El Product Backlog también se puede ajustar para encontrar nuevas oportunidades.
El Sprint Review es una sesión de trabajo y el equipo Scrum debe evitar limitarlo a una presentación.
La Revisión de Sprint tiene un límite de tiempo de un máximo de cuatro horas para un Sprint de un mes.
Para Sprints más cortos, el evento suele ser más corto.
Retrospectiva del Sprint - Sprint Retrospective
El propósito de la Retrospectiva de Sprint es planificar formas de aumentar la calidad y la eficacia.
El Equipo Scrum inspecciona cómo fue el último Sprint con respecto a las personas, las interacciones, los procesos, las herramientas y su Definición de Terminado.
Los elementos inspeccionados a menudo varían según el ámbito del trabajo.
Se identifican los supuestos que los llevaron por mal camino y se exploran sus orígenes.
El Equipo Scrum analiza qué salió bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no) esos problemas.
El equipo Scrum identifica los cambios más útiles para mejorar su efectividad.
Las mejoras más impactantes se abordan lo antes posible. Incluso pueden agregarse al Sprint Backlog para el próximo Sprint.
La Retrospectiva del Sprint concluye el Sprint. Tiene un límite de tiempo de un máximo de tres horas para un Sprint de un mes.
Para Sprints más cortos, el evento suele ser más corto.
Artefactos Scrum
Los artefactos de Scrum representan trabajo o valor.
Están diseñados para maximizar la transparencia de la información clave. Por lo tanto, todos los que los inspeccionan tienen la misma base de adaptación.
Cada artefacto contiene un compromiso para garantizar que proporcione información que mejore la transparencia y el enfoque frente al cual se pueda medir el progreso:
- Para el Product Backlog es el Product Goal.
- Para el Sprint Backlog es el Sprint Goal.
- Para el Incremento es la Definición de Terminado.
Product Backlog
El Product Backlog es una lista emergente y ordenada de lo que se necesita para mejorar el producto.
Es la única fuente de trabajo realizada por Scrum Team.
Los elementos del Backlog de productos que puede realizar el Scrum Team dentro de un Sprint se consideran listos para ser seleccionados en un evento de Sprint Planning.
Suelen adquirir este grado de transparencia después de las actividades de refinamiento.
El refinamiento de la Lista de Producto es el acto de dividir y definir aún más los elementos de la Lista de Producto en elementos más pequeños y precisos.
Esta es una actividad continua para agregar detalles, como una descripción, orden y tamaño.
Los atributos a menudo varían según el ámbito del trabajo.
Los Desarrolladores que realizarán el trabajo son responsables del dimensionamiento.
El Propietario del producto puede influir en los desarrolladores ayudándolos a comprender y seleccionar las alternativas.
Compromiso: objetivo del producto
El objetivo del producto describe un estado futuro del producto que puede servir como un objetivo para que el equipo Scrum planifique.
El objetivo del producto está en la lista de trabajos pendientes del producto.
El resto del Product Backlog surge para definir "qué" cumplirá con el Product Goal.
Un producto es un vehículo para ofrecer valor.
Tiene un límite claro, partes interesadas conocidas, usuarios o clientes bien definidos.
Un producto puede ser un servicio, un producto físico o algo más abstracto.
Un producto puede ser un servicio, un producto físico o algo más abstracto.
El Product Goal es el objetivo a largo plazo del Scrum Team. Deben cumplir (o abandonar) un objetivo antes de asumir el siguiente.
Lista emergente y ordenada de lo que se necesita en el Sprint - Spring Backlog
El Sprint Backlog se compone del Sprint Goal (por qué).
El conjunto de elementos del Product Backlog seleccionados para el Sprint (qué).
Así como un plan procesable para entregar el Incremento (cómo).
El Sprint Backlog es un plan realizado por y para los Desarrolladores.
Es una imagen muy visible y en tiempo real del trabajo que los Desarrolladores planean realizar durante el Sprint para lograr el Objetivo del Sprint.
En consecuencia, el Sprint Backlog se actualiza a lo largo del Sprint a medida que se aprende más.
Debe tener suficientes detalles para que puedan inspeccionar su progreso en el Daily Scrum.
Compromiso: Sprint Goal
El Sprint Goal es el único objetivo del Sprint.
Aunque el Sprint Goal es un compromiso de los desarrolladores, proporciona flexibilidad en términos del trabajo exacto necesario para lograrlo.
El Sprint Goal también crea coherencia y enfoque, alentando al Equipo Scrum a trabajar juntos en lugar de en iniciativas separadas.
El Sprint Goal se crea durante el evento Sprint Planning y luego se agrega al Sprint Backlog.
Mientras los Desarrolladores trabajan durante el Sprint, tienen en mente el Objetivo del Sprint.
Si el trabajo resulta ser diferente de lo que esperaban, colaboran con el Product Owner para negociar el alcance del Sprint Backlog dentro del Sprint sin afectar el Sprint Goal.
Incremento
Un incremento es un trampolín concreto hacia el objetivo del producto.
Cada Incremento se suma a todos los Incrementos anteriores y se verifica minuciosamente, lo que garantiza que todos los Incrementos funcionen juntos.
Para proporcionar valor, el Incremento debe ser utilizable.
Se pueden crear múltiples incrementos dentro de un Sprint.
La suma de los Incrementos se presenta en la Sprint Review apoyando así el empirismo.
Sin embargo, se puede entregar un Incremento a las partes interesadas antes del final del Sprint.
La Revisión de Sprint nunca debe considerarse una puerta para liberar valor.
El trabajo no puede considerarse parte de un Incremento a menos que cumpla con la Definición de Terminado.
Compromiso: Definición de Terminado
La Definición de Terminado es una descripción formal del estado del Incremento cuando cumple con las medidas de calidad requeridas para el producto.
En el momento en que un elemento de la Pila de Producto cumple con la Definición de Terminado, nace un Incremento.
La Definición de Terminado crea transparencia al proporcionar a todos un entendimiento compartido de qué trabajo se completó como parte del Incremento.
Si un artículo de la Lista de Producto no cumple con la Definición de Terminado, no se puede publicar ni presentar en la Revisión de Sprint. En su lugar, vuelve al Product Backlog para su consideración futura.
Si la Definición de Terminado para un incremento es parte de los estándares de la organización, todos los Equipos Scrum deben seguirla como mínimo.
Si no es un estándar organizacional, el Equipo Scrum debe crear una Definición de Hecho apropiada para el producto.
Los Desarrolladores deben ajustarse a la Definición de Terminado. Si hay varios Equipos Scrum trabajando juntos en un producto, deben definir y cumplir mutuamente la misma Definición de Hecho.
Assess your basic Scrum knowledge
Si has llegado hasta aquí es momento de hacer una evaluación gratuita de www.scrum.org:
Tip: Si haces al mes esta prueba durante 3 meses y de manera repetida obtienes una puntuación del 100%, ya podrías investigar sobre todos los recursos documentales con respecto a Scrum en el propio sitio de www.scrum.org y solicitar tu examen de certificación.
Nota final
Scrum es gratuito y se ofrece en esta guía. El marco de Scrum, como se describe en este documento, es inmutable. Si bien es posible implementar solo partes de Scrum, el resultado no es Scrum. Scrum existe solo en su totalidad y funciona bien como un contenedor para otras técnicas, metodologías y prácticas.