Scrum es un marco de trabajo para el desarrollo y el mantenimiento de productos complejos. Compuesto por los roles, eventos y artefactos de Scrum, y las reglas que los relacionan.
Ken Schwaber y Jeff Sutherland desarrollaron Scrum; este marco de trabajo, por el cual las personas pueden abordar problemas complejos adaptativos, a la vez que entrega productos del máximo valor posible productiva y creativamente.
Scrum no es un proceso o una técnica para construir productos; es un marco de trabajo dentro del cual se pueden emplear varias técnicas y procesos. Scrum muestra la eficacia relativa de las prácticas de gestión de producto y las prácticas de desarrollo, de modo que podamos mejorar.
El marco de trabajo Scrum consiste en los Equipos Scrum, roles, eventos, artefactos y reglas asociadas; cada componente dentro del marco de trabajo sirve a un propósito específico y es esencial para el éxito de Scrum y su uso.
Las reglas de Scrum relacionan los eventos, roles y artefactos, gobernando las relaciones e interacciones entre ellos.
Scrum se basa en la teoría de control de procesos empírica. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo.
Existen tres pilares que soportan toda la implementación del control de procesos empírico, transparencia, inspección y adaptación.
La Transparencia indica que los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado; requiere que dichos aspectos sean definidos por un estándar común, de tal modo que los observadores compartan un entendimiento común de lo que se está viendo; por ejemplo, todos los participantes deben compartir un lenguaje común para referirse al proceso; y aquellos que desempeñan el trabajo y aquellos que aceptan el producto de dicho trabajo deben compartir una definición común de Terminado (DONE).
La Inspección nos indica que los integrantes de los equipos de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y el progreso hacia el objetivo, para detectar variaciones.
Su inspección no debe ser tan frecuente como para que interfiera en el trabajo y son más beneficiosas cuando se realizan de forma diligente por inspectores expertos, en el mismo lugar de trabajo.
La Adaptación indica que si se determina que uno o más aspectos de un proceso se desvían de límites aceptables, y que el producto resultante no será aceptable, el proceso o el material que está siendo procesado deben ser ajustados. Dicho ajuste debe realizarse cuanto antes para minimizar desviaciones mayores.
Los eventos formales de Scrum, contenidos dentro del Sprint, para la inspección y adaptación son:
Reunión de Planificación del Sprint
Scrum Diario
Revisión del Sprint
Retrospectiva del Sprint
El Equipo Scrum está compuesto por un Product Owner, Development Team y un Scrum Master. Los Equipos Scrum son auto organizados y multifuncionales. Los equipos auto organizados eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo.
Los equipos multifuncionales tienen todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no son parte del equipo.
El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad; entregan productos de forma iterativa e incremental, maximizando las oportunidades de obtener retroalimentación. Las entregas incrementales de productos terminados aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto.
El Product Owner (es una única persona, no un comité) es el responsable de maximizar el valor del producto y del trabajo del Development Team (Equipo de Desarrollo). El cómo se lleva a cabo esto podría variar ampliamente entre distintas organizaciones, Equipos Scrum e individuos; es la única persona responsable de gestionar la Product Backlog (Lista del Producto), incluso si delegara esta gestión, que incluye:
Expresar claramente cada uno de los elementos.
Ordenar los elementos, para alcanzar los objetivos y misiones de la mejor manera posible.
Optimizar el valor del trabajo desempeñado por el Equipo de Desarrollo.
Asegurar que la Lista del Producto es visible, transparente y clara para todos, y que muestra aquello en lo que el equipo trabajará a continuación.
Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al nivel que es necesario.
El Product Owner podría representar los deseos de un comité en el Product Backlog, pero aquellos que quieran cambiar la prioridad de un elemento, deben hacerlo a través del Product Owner.
Para que se pueda realizar de forma óptima este trabajo, toda la organización debe respetar sus decisiones; las decisiones del Product Owner se reflejan en el contenido y en la priorización del Product Backlog.
No está permitido que nadie pida al Development Team que trabaje con base en un conjunto diferente de requerimientos y el Development Team no debe actuar con base en lo que diga cualquier otra persona.
Development Team consiste en los profesionales que desempeñan el trabajo de entregar un Incremento de producto terminado, que potencialmente se pueda poner en producción al final de cada Sprint, solo estos participan en la creación del Incremento. Estos equipos son estructurados y empoderados por la organización para organizar y gestionar su propio trabajo, la sinergia resultante optimiza la eficiencia y efectividad.
El Development Team tiene las siguientes características:
Auto organizados, nadie indica al Development Team cómo convertir elementos del Product Backlog en Incrementos de funcionalidad potencialmente desplegables.
Multifuncionales, deben contar con todas las habilidades necesarias para crear un Incremento de producto.
Scrum no reconoce títulos para los miembros de un Development Team, todos son desarrolladores, independientemente del trabajo que realice cada profesional, no hay excepciones a esta regla.
Scrum no reconoce sub equipos en el Development Team, no importan los dominios particulares que requieran, como pruebas o análisis de negocio, no hay excepciones a esta regla.
Los miembros individuales del Development Team pueden tener habilidades especializadas y áreas en las que estén más enfocados, pero la responsabilidad recae en el Equipo como un todo.
El tamaño óptimo del Development Team es lo suficientemente pequeño como para permanecer ágil y lo suficientemente grande como para completar una cantidad de trabajo significativa. Tener menos de tres miembros en el Team reduce la interacción y resulta en ganancias de productividad más pequeñas.
Los Development Teams más pequeños podrían encontrar limitaciones en cuanto a las habilidades necesarias durante un Sprint, haciendo que estos no pudiesen entregar un incremento que potencialmente se pueda poner en un ambiente productivo.
Tener más de nueve miembros en el equipo requiere demasiada coordinación, los Development Team grandes generan demasiada complejidad como para que pueda gestionarse mediante un proceso empírico. Los roles de Product Owner y Scrum Master no cuentan en el cálculo del tamaño del equipo a menos que también estén contribuyendo a trabajar en la Lista de Pendientes de Sprint.
El Scrum Master es el responsable de asegurar que el marco de trabajo Scrum es entendido y adoptado, ellos se aseguran de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum, es un líder que está al servicio del Equipo Scrum, ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no, ayuda a todos a modificar estas interacciones para maximizar el valor creado por el Equipo Scrum.
El Scrum Master da servicio al Product Owner de varias formas, incluyendo:
Encontrar técnicas para gestionar la Product Backlog de manera efectiva.
Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Product Backlog claros y concisos.
Entender la planificación del producto en un entorno empírico.
Asegurar que el Product Owner conozca cómo ordenar el Product Backlog para maximizar el valor.
Entender y practicar la agilidad.
Facilitar los eventos de Scrum según se requiera o necesite.
El Scrum Master da servicio al Development Team de varias formas, incluyendo:
Guiarlos en ser auto organizado y multifuncional.
Ayudarlos a crear productos de alto valor.
Eliminar impedimentos para el progreso del Development Team.
Facilitar los eventos de Scrum según se requiera o necesite.
Guiarlos en el entorno de organizaciones en las que Scrum aún no ha sido adoptado y entendido por completo.
El Scrum Master da servicio a la organización de varias formas, incluyendo:
Liderar y guiar a la organización en la adopción de Scrum.
Planificar las implementaciones de Scrum en la organización.
Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico de producto.
Motivar cambios que incrementen la productividad del Equipo Scrum.
Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización.
En Marco de Trabajo Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son bloques de tiempo, de tal modo que todos tienen una duración máxima.
Una vez que comienza un Sprint, su duración es fija y no puede modificarse. Los demás eventos pueden terminar siempre que se alcance el objetivo del evento, asegurando que se emplee una cantidad apropiada de tiempo sin permitir desperdicio en el proceso.
Además, del propio Sprint, que es un contenedor del resto de eventos, cada uno de los eventos de Scrum constituye una oportunidad formal para la inspección y la adaptación de algún aspecto; estos eventos están diseñados específicamente para habilitar la transparencia e inspección; la falta de alguno de estos eventos da como resultado una reducción de la transparencia y constituye una oportunidad perdida para inspeccionar y adaptarse.
El corazón del Marco de Trabajo Scrum es el Sprint, es un bloque de tiempo de un mes o menos durante el cual se crea un incremento de producto terminado, utilizable y potencialmente desplegable.
Es conveniente que la duración de los Sprints sea consistente a lo largo del esfuerzo de desarrollo; cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint previo.
Los Sprints contienen y consisten de la Reunión de Planificación del Sprint, las Reuniones Diarias, el trabajo de desarrollo, Reunión Revisión del Sprint, y la Reunión Retrospectiva del Sprint.
Durante el Sprint:
No se realizan cambios que puedan afectar al Objetivo del Sprint.
Los objetivos de calidad no disminuyen.
El alcance puede ser clarificado y renegociado entre el Product Owner y el Development Team a medida que se va aprendiendo más.
Cada Sprint puede considerarse un proyecto con un horizonte no mayor de un mes. Al igual que los proyectos, los Sprints se usan para lograr algo. Cada Sprint tiene una definición de qué se va a construir, un diseño y un plan flexible que guiará la construcción y el trabajo y el producto resultante.
Están limitados a un mes calendario. Cuando el horizonte de un Sprint es demasiado grande la definición de lo que se está construyendo podría cambiar, la complejidad podría elevarse y el riesgo podría aumentar.
Los Sprints habilitan la predictibilidad, al asegurar la inspección y adaptación del progreso al menos en cada mes calendario. Los Sprints también limitan el riesgo al costo de un mes calendario.
Un Sprint puede ser cancelado antes de que el bloque de tiempo llegue a su fin. Solo el Product Owner tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de los interesados, del Equipo de Desarrollo o del Scrum Master. Un Sprint se cancelaría si el Objetivo del Sprint llega a quedar obsoleto.
Esto podría ocurrir si la compañía cambia la dirección o si las condiciones del mercado o de la tecnología cambian.
En general, un Sprint debería cancelarse si no tuviese sentido seguir con él dadas las circunstancias. Pero debido a la corta duración de los Sprints, rara vez la cancelación tiene sentido.
Cuando se cancela un Sprint, se revisan todos los Elementos del Product Backlog que se hayan completado y terminado.
Si una parte del trabajo es potencialmente entregable, el Product Owner normalmente lo acepta.
Todos los elementos del la Product Backlog no completados se vuelven a estimar y se vuelven a introducir en el Product Backlog. El trabajo finalizado en ellos pierde valor con rapidez y frecuentemente debe volverse a estimar.
Las cancelaciones de Sprint consumen recursos, ya que todos deben reagruparse en otra Reunión de Planificación de Sprint para empezar otro Sprint. Las cancelaciones de Sprint son a menudo traumáticas para el Equipo Scrum y son muy poco comunes.
En la reunión de planificación de Sprint, el trabajo a realizar durante el Sprint se planifica, este plan se crea mediante el trabajo colaborativo del Equipo Scrum completo. Esta reunión tiene un máximo de duración de ocho horas para un Sprint de un mes, para Sprints más cortos, el evento es usualmente más corto.
El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito.
El Scrum Master enseña al Equipo Scrum a mantenerse dentro del bloque de tiempo.
La Reunión de Planificación de Sprint responde a las siguientes preguntas:
¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?
¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?
El Development Team trabaja para proyectar la funcionalidad que se desarrollará durante el Sprint, el Product Owner discute el objetivo que el Sprint debería lograr y los elementos del Product Backlog que, si se completan en el Sprint, lograrían el objetivo del Sprint.
El Equipo Scrum completo colabora en el entendimiento del trabajo del Sprint. La entrada a esta reunión está constituida por el Product Backlog, el último Incremento de producto, la capacidad proyectada del Development Team para el Sprint, y el rendimiento pasado del Development Team.
El número de elementos del Product Backlog seleccionados para el Sprint depende únicamente del Development Team.
Solo el Development Team puede evaluar qué es capaz de lograr durante el Sprint que comienza; después de que estos proyectan qué elementos del Product Backlog entregarán en el Sprint, el Equipo Scrum elabora un Objetivo del Sprint.
El Objetivo del Sprint debería lograrse durante el Sprint a través de la implementación de la Sprint Backlog, y provee una guía al equipo de desarrollo de por qué se está construyendo el incremento.
Una vez que se ha establecido el objetivo y seleccionado los elementos del Prodcut Backlog para el Sprint, el Development Team decide cómo construirá esta funcionalidad para formar un Incremento de producto terminado, los elementos del Product Backlog seleccionados para este Sprint, más el plan para terminarlos, recibe el nombre de Sprint Backlog.
El Development Team, por lo general, comienza diseñando el sistema y el trabajo necesario para convertir el Product Backlog en un Incremento de producto funcional. El trabajo podría ser de tamaño o esfuerzo estimado variables.
Sin embargo, durante la Reunión de Planificación del Sprint, se planifica suficiente trabajo como para que el Development Team pueda hacer una proyección de lo que cree que puede completar en el Sprint que comienza.
Para el final de esta reunión, el trabajo planificado por el Development Team para los primeros días del Sprint es descompuesto en unidades de un día o menos.
El Development Team se auto organiza para asumir el trabajo de la Lista de Pendientes de Sprint, tanto durante la reunión de Planificación de Sprint como a lo largo del Sprint. El Product Owner puede ayudar a clarificar los elementos del Product Backlog seleccionados y hacer concesiones.
Si el Development Team determina que tiene demasiado trabajo o que no tiene suficiente trabajo, podría renegociar los elementos del Product Backlog seleccionados con el Product Owner. El Development Team podría también invitar a otras personas a que asistan con el fin de que proporcionen asesoría técnica o relacionada con el dominio.
Al finalizar la Reunión de Planificación de Sprint, el Development Team debería ser capaz de explicar al Product Owner y al Scrum Master cómo pretende trabajar como un equipo auto organizado para lograr el Objetivo del Sprint y crear el Incremento esperado.
El Objetivo del Sprint, es una meta establecida para el Sprint que puede ser alcanzada mediante la implementación del Product Backlog, la cual proporciona una guía al Development Team acerca de por qué está construyendo el incremento, es creado durante la reunión de Planificación del Sprint.
El objetivo del Sprint, ofrece al equipo de desarrollo cierta flexibilidad con respecto a la funcionalidad implementada en el Sprint.
Los elementos del Product Backlog seleccionados ofrecen una función coherente, que puede ser el objetivo del Sprint.
Este objetivo del Sprint, puede representar otro nexo de unión que haga que el Development Team trabaje en conjunto y no en iniciativas separadas; a medida que el Development Team trabaja, se mantiene el objetivo del Sprint en mente, con el fin de satisfacer el objetivo del Sprint se implementa la funcionalidad y la tecnología.
Si el trabajo resulta ser diferente de lo que el Development Team espera, ellos colaboran con el Product Owner para negociar el alcance de la Lista de pendientes del Sprint.
El Scrum diario es una reunión con un bloque de tiempo de 15 minutos para que el Equipo de Desarrollo sincronice sus actividades y cree un plan para las siguientes 24 horas.
Esto se lleva a cabo inspeccionando el trabajo avanzado desde la última Reunión Scrum diario y haciendo una proyección acerca del trabajo que podría completarse antes del siguiente.
El Scrum diario se realiza a la misma hora y en el mismo lugar todos los días para reducir la complejidad.
Durante la reunión, cada miembro del Equipo de Desarrollo explica:
¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del Sprint?
¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint?
El Development Team usa el Scrum Diario para evaluar el progreso hacia el Objetivo del Sprint y para evaluar qué tendencia sigue este progreso hacia la finalización del trabajo contenido en la Sprint Backlog.
El Scrum Diario optimiza las posibilidades de que el Development Team cumpla el Objetivo del Sprint. Cada día, el Development Team debería entender cómo intenta trabajar en conjunto como un equipo auto organizado para lograr el Objetivo del Sprint y crear el Incremento esperado hacia el final del Sprint.
El Development Team, a menudo, se vuelve a reunir inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para adaptar, o planificar el resto del trabajo del Sprint.
El Scrum Master se asegura de que el Development Team tenga la reunión, pero el Development Team es el responsable de dirigir el Scrum Diario.
El Scrum Master enseña al Development Team para que mantenga el Scrum Diario en los límites del bloque de tiempo de 15 minutos, se asegura de que se cumpla la regla de que solo los miembros del Development Team participan en el Scrum Diario.
Estas reuniones mejoran la comunicación, eliminan la necesidad de mantener otras reuniones, identifican y eliminan impedimentos relativos al desarrollo, resaltan y promueven la toma de decisiones rápida, y mejoran el nivel de conocimiento del Development Team.
El Scrum Diario constituye una reunión clave de inspección y adaptación.
Al final del Sprint se lleva a cabo una Revisión de Sprint para inspeccionar el Incremento y adaptar el Backlog, si fuese necesario.
Durante la Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se hizo durante el Sprint.
Basándose en esto, y en cualquier cambio al Backlog durante el Sprint, los asistentes colaboran para determinar las siguientes cosas que podrían hacerse para optimizar el valor.
Se trata de una reunión informal, no una reunión de seguimiento, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación de información y fomentar la colaboración.
Se trata de una reunión restringida a un bloque de tiempo de cuatro horas para Sprints de un mes.
Para Sprints más cortos, se reserva un tiempo proporcionalmente menor. El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito.
El Scrum Master enseña a todos a mantener el evento dentro del bloque de tiempo fijado.
La Revisión de Sprint incluye los siguientes elementos:
Los asistentes son el Equipo Scrum y los interesados clave invitados por el Product Owner.
El Product Owner explica qué elementos del Backlog se han Terminado y cuales no se han terminado.
El Development Team habla acerca de qué fue bien durante el Sprint, qué problemas aparecieron y cómo fueron resueltos esos problemas.
El Development Team demuestra el trabajo que ha terminado y responde preguntas acerca del Incremento.
El Product Owner habla acerca del Backlog en el estado actual. Proyecta fechas de finalización probables en el tiempo basándose en el progreso obtenido hasta la fecha (si es necesario).
El grupo completo colabora acerca de qué hacer a continuación, de modo que la Revisión del Sprint proporcione información de entrada valiosa para Reuniones de Planificación de Sprints subsiguientes.
Revisión de cómo el mercado o el uso potencial del producto podría haber cambiado lo que es de más valor para hacer a continuación.
Revisión de la línea de tiempo, presupuesto, capacidades potenciales y mercado para la próxima entrega prevista del producto.
El resultado de la Revisión de Sprint es un Backlog revisado, que define los elementos del Backlog posibles para el siguiente Sprint. Es posible además que el Backlog reciba un ajuste general para enfocarse en nuevas oportunidades.
La Retrospectiva del Sprint es una oportunidad para el Equipo Scrum pueda inspeccionarse a sí mismo y crear un plan de mejoras que sean abordadas durante el siguiente Sprint, tiene lugar después de la Revisión de Sprint y antes de la siguiente Reunión de Planificación de Sprint, se trata de una reunión restringida a un bloque de tiempo de tres horas para Sprints de un mes, para Sprints más cortos se reserva un tiempo proporcionalmente menor.
El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito. El Scrum Master enseña a todos a mantener el evento dentro del bloque de tiempo fijado. El Scrum Master participa en la reunión como un miembro del equipo ya que la responsabilidad del proceso Scrum recae sobre él.
El propósito de la Retrospectiva de Sprint es:
Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas.
Identificar y ordenar los elementos más importantes que salieron bien y las posibles mejoras.
Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo.
El Scrum Master alienta al equipo para que mejore, dentro del marco de proceso Scrum, su proceso de desarrollo y sus prácticas para hacerlos más efectivos y amenos para el siguiente Sprint.
Durante cada Retrospectiva de Sprint, el Equipo Scrum planifica formas de aumentar la calidad del producto mediante la adaptación de la Definición de Terminado o Done.
Para el final de la Retrospectiva de Sprint, el Equipo Scrum debería haber identificado mejoras que implementará en el próximo Sprint.
El hecho de implementar estas mejoras en el siguiente Sprint, constituye la adaptación subsecuente a la inspección del Development Team a sí mismo.
Aunque las mejoras pueden implementarse en cualquier momento, la Retrospectiva de Sprint ofrece un evento dedicado para este fin, enfocado en la inspección y la adaptación.
Los artefactos de Scrum representan trabajo o valor en diversas formas que son útiles para proporcionar transparencia y oportunidades para la inspección y adaptación. Los artefactos definidos por Scrum están diseñados específicamente para maximizar la transparencia de la información clave, que es necesaria para asegurar que todos tengan el mismo entendimiento del artefacto.
El Backlog es una lista ordenada de todo lo que podría ser necesario en el producto, y es la única fuente de requisitos para cualquier cambio a realizarse en el producto.
El Product Owner es el responsable del Backlog , incluyendo su contenido, disponibilidad y ordenación.
Un Backlog nunca está completo, el desarrollo más temprano del mismo solo refleja los requisitos conocidos y mejor entendidos al principio.
El Backlog evoluciona a medida de que el producto y el entorno en el que se usará también lo hacen, es dinámico; cambia constantemente para identificar lo que el producto necesita para ser adecuado, competitivo y útil, mientras el producto exista, su Backlog también existe.
El Backlog enumera todas las características, funcionalidades, requisitos, mejoras y correcciones que constituyen cambios a ser hechos sobre el producto para entregas futuras; los elementos del Backlog tienen como atributos la descripción, la ordenación, la estimación y el valor.
A medida que un producto es utilizado y se incrementa su valor, y el mercado proporciona retroalimentación, el Backlog se convierte en una lista más larga y exhaustiva. Los requisitos nunca dejan de cambiar, así que el Backlog es un artefacto vivo.
Los cambios en los requisitos de negocio, las condiciones del mercado o la tecnología podrían causar cambios en el Backlog .
A menudo, varios Equipos Scrum trabajan juntos en el mismo producto, para describir el trabajo a realizar sobre el producto, se utiliza un único Backlog ; en ese caso podría emplearse un atributo del Backlog para agrupar los elementos.
El refinamiento del Backlog es el acto de añadir detalle, estimaciones y orden a los elementos del Backlog . Se trata de un proceso continuo, en el cual el Product Owner y el Development Team colaboran acerca de los detalles de los elementos del Backlog . Durante el refinamiento del Backlog, se examinan y revisan sus elementos, el Equipo Scrum decide cómo y cuándo se hace el refinamiento, este usualmente consume no más del 10% de la capacidad del Development Team.
Sin embargo, los elementos del Backlog pueden actualizarse en cualquier momento por el Product Owner o a criterio suyo.
Los elementos del Backlog de orden más alto son generalmente más claros y detallados que los de menor orden.
Se realizan estimaciones más precisas basándose en la mayor claridad y detalle; cuanto más bajo es el orden, menor es el detalle. Los elementos del Backlog de los que se ocupará el Development Team en el siguiente Sprint tienen una granularidad mayor, habiendo sido descompuestos de forma que cualquier elemento puede ser terminado dentro de los límites del bloque de tiempo del Sprint.
Los elementos del Backlog que pueden ser terminados por el Development Team en un Sprint son considerados “preparados” o “accionables” para ser seleccionados en una reunión de Planificación de Sprint.
Los elementos del Backlog normalmente adquieren este grado de transparencia mediante las actividades de refinamiento descritas anteriormente.
El Development Team es el responsable de proporcionar todas las estimaciones. El Product Owner podría influenciar al Equipo ayudándoles a entender y seleccionar soluciones de compromiso, pero las personas que harán el trabajo son las que hacen la estimación final.
En cualquier momento, es posible sumar el trabajo total restante para alcanzar el objetivo.
El Product Owner hace seguimiento de este trabajo restante total al menos en cada Revisión de Sprint.
El Product Owner compará esta cantidad con el trabajo restante en Revisiones de Sprint previas, para evaluar el progreso hacia la finalización del trabajo proyectado en el tiempo deseado para el objetivo.
Esta información se muestra de forma transparente a todos los interesados. Varias prácticas de proyección sobre tendencias se han utilizado para predecir el progreso, como trabajo consumido (burndown), avanzado (burnup) y flujo acumulado (cumulative flow); estas se han revelado como útiles, sin embargo, no remplazan la importancia del empirismo.
En entornos complejos, se desconoce lo que ocurrirá, solo lo que ya ha ocurrido puede utilizarse para la toma de decisiones con miras al futuro.
La Lista de Pendientes del Sprint es el conjunto de elementos del Backlog seleccionados para el Sprint, más un plan para entregar el Incremento de producto y conseguir el Objetivo del Sprint, es una predicción hecha por el Development Team acerca de qué funcionalidad formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en un Incremento terminado.
La Lista de Pendientes del Sprint hace visible todo el trabajo que el Development Team identifica como necesario para alcanzar el Objetivo del Sprint, es un plan con un nivel de detalle suficiente como para que los cambios en el progreso se puedan entender en el Scrum Diario.
El Development Team modifica la Lista de Pendientes del Sprint durante el Sprint y esta Lista de Pendientes del Sprint emerge a lo largo del Sprint.
Esto ocurre a medida que el Development Team trabaja sobre el plan y aprende más acerca del trabajo necesario para conseguir el Objetivo del Sprint.
Según se requiere nuevo trabajo, el Development Team lo añade a la Lista de Pendientes del Sprint, a medida que el trabajo se ejecuta o se completa, se va actualizando la estimación de trabajo restante, cuando algún elemento del plan pasa a ser considerado innecesario, es eliminado; solo el Development Team puede cambiar su Lista de Pendientes del Sprint durante un Sprint.
Esta Lista de Pendientes del Sprint es una imagen visible en tiempo real del trabajo que el Development Team planea llevar a cabo durante el Sprint, y pertenece únicamente al Development Team.
En cualquier momento durante un Sprint, es posible sumar el trabajo restante total en los elementos de la Lista de Pendientes del Sprint.
El Development Team hace seguimiento de este trabajo restante total al menos en cada Scrum Diario para proyectar la posibilidad de conseguir el Objetivo del Sprint.
Haciendo seguimiento del trabajo restante a lo largo del Sprint, el Development Team puede gestionar su progreso.
El Incremento es la suma de todos los elementos del Backlog completados durante un Sprint y el valor de los incrementos de todos los Sprints anteriores.
Al final de un Sprint, el nuevo Incremento debe estar terminado, lo cual significa que está en condiciones de ser utilizado y que cumple la Definición de Terminado o Done del Equipo Scrum.
El incremento debe estar en condiciones de utilizarse sin importar si el Product Owner decide liberarlo o no. Scrum se basa en la transparencia. Las decisiones para optimizar el valor y controlar el riesgo se toman basadas en el estado percibido de los artefactos. En la medida en que la transparencia sea completa, estas decisiones tienen unas bases sólidas.
En la medida en que los artefactos no son completamente transparentes, estas decisiones pueden ser erróneas, el valor puede disminuir y el riesgo puede aumentar.
El Scrum Master debe trabajar con el Product Owner, el Development Team y otras partes involucradas para entender si los artefactos son completamente transparentes.
Hay prácticas para hacer frente a la falta de transparencia; el Scrum Master debe ayudar a todos a aplicar las prácticas más apropiadas si no hay una transparencia completa. Un Scrum Master puede detectar la falta de transparencia inspeccionando artefactos, reconociendo patrones, escuchando atentamente lo que se dice y detectando diferencias entre los resultados esperados y los reales.
La labor del Scrum Master es trabajar con el Equipo Scrum y la organización para mejorar la transparencia de los artefactos.
Este trabajo usualmente incluye aprendizaje, convicción y cambio. La transparencia no ocurre de la noche a la mañana, sino que es un camino.
Cuando un elemento del Backlog o un Incremento se describe como “Terminado”, todo el mundo debe entender lo que significa “Terminado”. Aunque esto varía significativamente para cada Equipo Scrum, los miembros del Equipo deben tener un entendimiento compartido de lo que significa que el trabajo esté completado, para asegurar la transparencia.
Esta es la definición de “Terminado” para el Equipo Scrum y se utiliza para evaluar cuándo se ha completado el trabajo sobre el Incremento de producto. Esta misma definición que guía al Development Team en saber cuántos elementos del Backlog puede seleccionar durante una reunión de Planificación de Sprint.
El propósito de cada Sprint es entregar Incrementos de funcionalidad que potencialmente se puedan poner en producción, y que se ajustan a la Definición de “Terminado” actual del Equipo Scrum. Los Development Teams entregan un Incremento de funcionalidad de producto en cada Sprint, este Incremento es utilizable, de modo que el Product Owner podría elegir liberarlo inmediatamente.
Si la definición de “Terminado” para un incremento es parte de las convenciones, estándares o guías de la organización de desarrollo, al menos todos los Equipos Scrum deben seguirla. Si “Terminado” para un incremento no es una convención de la organización de desarrollo, el Development Team del Equipo Scrum debe definir una definición de “Terminado” apropiada para el producto.
Si hay múltiples Equipos Scrum trabajando en la entrega del sistema o producto, los equipos de desarrolladores en todos los Equipos Scrum deben definir en conjunto la definición de “Terminado” o “Done”.
Cada Incremento se integra con todos los Incrementos anteriores y es probado exhaustivamente, asegurando que todos los Incrementos funcionan en conjunto.
A medida que los Equipos Scrum maduran, se espera que su definición de “Terminado” se amplíe para incluir criterios más rigurosos para una mayor calidad. Cualquier producto o sistema debería tener una definición de “Terminado” que es un estándar para cualquier trabajo realizado sobre él.
Existen cinco valores en Scrum:
Foco, un sprint bien diseñado debe tener un objetivo claro y medible. Un equipo Scrum debe enfocarse completamente en dicho objetivo y en todo el trabajo que este Sprint implica.
Respeto, dar y pedir retro alimentación siempre es necesario cuando se trabaja en equipos auto organizados y multifuncionales, separar la persona del rol es una frase que debiera repetirse diariamente, trabajo en equipo, compañerismo, confianza en los demás.
Coraje, Los integrantes de un equipo Scrum requieren de gran valor demostrar que existe una forma distinta de hacer las cosas bien, por ejemplo para proponer cambios importantes en cómo hacemos las cosas y eliminar impedimentos grandes, para mostrarnos vulnerables y pedir ayuda cuando la necesitemos.
Compromiso, hacer lo que dices que harás, con los acuerdos de trabajo, con la planificación y los objetivos del sprint. El compromiso es esencial para Scrum ya que es el núcleo fundamental sobre el que se cimienta; la responsabilidad personal, la búsqueda de la superación personal y de una conexión genuina con sus compañeros en el lugar de trabajo y también con su trabajo. En Scrum se les pide a los participantes que adquieran tres compromisos, a saber, el compromiso de entregar trabajo de calidad, el compromiso de mejorar y el compromiso de ayudar. Estos compromisos son el núcleo de una red de compromisos que permiten que este Marco de Trabajo funcione. Cuando los compromisos de unos con otros, el Espíritu de Scrum y el marco son débiles, la entropía, el decaimiento, el cinismo y el olvido comienzan a aparecer.
Apertura, Nos permite una discusión abierta de los problemas que tenemos al realizar nuestros Sprints, la información está disponible para todos, transparencia, sinceridad, compartir.
Entonces.... ¿Scrum es sólo para desarrolladores?
Para contestar esta interrogante debemos decir que Scrum es un marco de trabajo, para el desarrollo y el mantenimiento de productos y proyectos complejos, mediante el cual las personas pueden abordar problemas complejos adaptativos, a la vez que entrega “productos” del máximo valor posible al cliente en cada ciclo, en términos de productividad y creatividad.
Scrum se basa en la teoría de control de procesos empírica. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce.
Scrum emplea un enfoque cíclico e incremental para optimizar la predictibilidad y el control del riesgo. Por eso no es sólo para el ámbito del desarrollo de software.