SCRUM: Marco de trabajo Ágil – Guía para Scrum Máster

Visión

Es un marco de trabajo por el cual las personas pueden abordar problemas complejos adaptatibos,  a la vez que entregar productos del máximo valor posible productiva y creativamente.

El sello distintivo de Scrum es su tolerancia y adaptación al cambio. Scrum no promueve el determinar y establecer planes con mucha firmeza y anticipación, ya que opera en la premisa de que el desarrollo del proyecto es muy propenso al cambio y al riesgo. El resultado es un alto grado de flexibilidad y tolerancia al cambio. El proyecto se lleva a cabo y se gestiona de forma ágil e incremental, por lo que generalmente es fácil incorporar cambios a lo largo del proyecto.

Scrum es:

• Liviano 
• Fácil de entender
• Difícil de dominar

No es una técnica, no es un proceso; lo que es realmente es un marco de trabajo dentro del cual se pueden emplear varios tipos de técnicas y procesos. Scrum muestra la eficacia relativa de las técnicas de gestión de producto y las técnicas de trabajo de modo que podamos mejorar continuamente el producto, el equipo y el entorno de trabajo.

El marco de trabajo Scrum consiste en los Equipos Scrum y sus 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 para su uso. Las reglas de Scrum relacionan los roles, eventos y artefactos y rigen las relaciones e interacciones entre ellos.

Usos

Desde principios de los años 90 Scrum se ha usado ampliamente en todo el mundo para: 

• Investigar e identificar mercados viables, tecnologías y capacidades de productos.
• Desarrollar productos y mejoras.
• Liberar productos y mejoras tantas veces como sea posible durante el día.
• Desarrollar y mantener ambientes en la Nube (en línea, seguros, bajo demanda) y otros entornos operacionales para el uso de productos. 
• Mantener y renovar productos.

Scrum se ha usado para desarrollar software, hardware, software embebido, redes de funciones interactivas, vehículos autónomos, escuelas, gobiernos, mercadeo, también para gestionar la operación de organizaciones y casi todo lo que usamos en nuestra vida diaria, como individuo y como sociedad.

La escencia de scrum es el pequeño gupo de personas.

El equipo es altamente flexible y adaptativo. Estas fortalezas continúan operando en un equipo, en varios, en muchos y en redes de equipos que desarrollan, liberan, operan y mantienen el trabajo y los productos de trabajo de miles de personas. Ellos colaboran e interoperan a través de arquitecturas de desarrollo sofisticadas y ambientes finales de liberación.

Cuando las palabras “desarrollar” y “desarrollo” se usan en la Guía de Scrum, se refieren a trabajo complejo, tales como estos identificados anteriormente.

Teoria

Scrum se basa en la teoría de control de procesos empírica o empirismo.

El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. 

Pilares del Scrum

• Trasparencia
• Inspeccion
• Adaptacion

Transparencia

Los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado . La transparencia 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án viendo.

Inspeccion

Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y el progreso hacia un objetivo para detectar variaciones indeseadas . Su inspección no debe ser tan frecuente como para que interfiera en el trabajo . Las inspecciones son más beneficiosas cuando se realizan de forma diligente por inspectores expertos en el mismo lugar de trabajo .

Adaptacion

Uno de los tres pilares del control del proceso empírico ; la retroalimentación se usa para hacer un ajuste al producto de trabajo que se está desarrollando o al proceso por el cual se está desarrollando .

Principios Ágiles

Transparencia

Los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado. La transparencia 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án viendo.

Por ejemplo

• Todos los participantes deben compartir un lenguaje común para referirse al proceso.
• Aquellos que desempeñan el trabajo y quienes inspeccionan el incremento resultante deben compartir una definición común de “Terminado”

Video Trasparencia en la conciencia colectiva

Como mejorar la trasparencia

Inspección

Los usuarios scrum deben inspeccionar frecuentemente los artefactos de scrum y el proceso hacia un objetivo para detectar variaciones indeseadas. 

La inspección tiene lugar durante los siguientes eventos: 

• La Reunión de planificación del Sprint(Sprint Planning),
• El Scrum Diario (Daily Scrum) 
• La Revision del Sprint(Sprint Review)
• La retrospectiva del Sprint(Sprint Restrospective).

Tips

• Las inspección no deben ser tan frecuentes como para que interfiera en el trabajo
• Las inspecciones son mas beneficiosas cuando se realizan de forma voluntaria o por interés o esmero por inspectores expertos en el mismo lugar de trabajo.

Revisión e Inspección aplicada en scrum

Adaptacion

Si un inspector determina que uno mas aspectos de un proceso se desvían de limites aceptables y que el producto resultante sera inaceptable, el proceso o el material que esta siendo procesado deben ajustarse  y el ajuste debe realizarse cuanto antes para minimizar desviaciones mayores. 

La adaptación igual que la inspección tiene lugar durante los siguientes evento

• La Reunión de planificación del Sprint(Sprint Planning),
• El Scrum Diario (Daily Scrum) 
• La Revision del Sprint(Sprint Review)
• La Retrospectiva del Sprint(Sprint Restrospective)

Valores de Scrum

• Compromiso
• Coraje
• Foco
• Apertura
• Respeto

Cuando el equipo Scrum incorpora y vivencia los valores, los pilares Scrum se materializan y fomentan la confianza en todo el mundo. Los miembros del equipo Scrum aprenden y exploran estos valores a medida que trabajan en los eventos, roles y artefactos de Scrum.

Tips

• El uso exitoso de scrum depende de que las personas lleguen a ser mas virtuosas en la convivencia con estos cinco valores. 
• Las personas se comprometen de manera individual a alcanzar las metas del equipo Scrum.
• Los miembros del equipo Scrum tienen coraje para hacer bien las cosas y para trabajar en los problemas difíciles.
• Todos se enfocan en el trabajo del Sprint y las metas del equipo Scrum.
• El equipo Scrum y sus interesados acuerdan estar abiertos a todo el trabajo y a los desafíos que se les presenten al realizar su trabajo.
• Los miembros del Equipo Scrum se respetan entre si para ser personas capaces e independientes.

Definición de «Terminado»

Son los acuerdos del Product Owner con los StakeHolders que contiene todas las condiciones que deben de cumplir los items de Product Backlog para considerar un Sprint completado o finalizado.

Cuando un elemento de la Lista de Producto o un Incremento se describe como «Terminado», todo el mundo debe entender lo que significa «Terminado». Sin embargo esto puede variar significativamente para cada Equipo Scrum, los miembros del Equipo deben tener un entendimiento compartido de lo que significa que el trabajo este completado para segurar la transparencia.

La definición de «Terminado» para el Equipo Scrum y se utiliza para evaluar cuando se ha completado el trabajo sobre el Incremento de Producto.

Esta misma definición guia al equipo de Desarrollo a saber cuantos elementos de la lista de Producto puede seleccionar durante la Planificación del Sprint.

Los Equipos de Desarrollo entregan un Incremento de funcionalidad de producto en cada Sprint. Este Incremento es utilizable, de modo que el Dueño de Producto 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 Equipo de Desarrollo del Equipo Scrum debe especificar 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 Desarrollo en todos los Equipos Scrum deben definir en conjunto la definición de “Terminado”.

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. El uso de las nuevas definiciones puede descubrir trabajo por hacer en los incrementos previamente “Terminados”. Cualquier producto o sistema debería tener una definición de “Terminado” que es un estándar para cualquier trabajo realizado sobre él.

Equipo Scrum(Scrum Team)

El equipo scrum esta compuesto por

• Un Dueño de producto(Product Owner)
• El Equipo de Desarrollo(Development Team)
• Un Scrum Master

Los equipos Scrum son autoorganizados y multifuncionales. 

• Los equipos autoorganizdos 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 para llevar a cabo el trabajo sin depender de otras personas que no son parte del equipo.
• El modelo de equipo en scrum esta diseñado para optimizar la flexibilidad, creatividad y productivdad.
• El equipo de scrum ha demostrado ser cada vez mas efectivo para todos los usos anteriores y cualquier trabajo complejo.

Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de obtener retroalimentación. Las entregas incrementales de producto “Terminado” aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto

El Dueño de Producto(Product Owner)

El dueño de producto es el responsable de maximizar el valor del producto resultante del trabajo del

d equipo de desarrollo. El como se lleva a cabo esto podría variar ampliamente entre distintas organizaciones, equipos scrum e individuos.

El dueño de producto es la única persona responsable de gestionar la lista del producto(Product  Backlog). La gestión incluye:

• Transcribe los requerimientos de los interesados hacia historias de usuario.
• Expresar claramente los elementos de la lista del producto.
• Ordenar los elementos de la lista del producto para alcanzar los objetivos y misiones de la mejor manera posible.
• Optimizar el valor del trabajo que el equipo de desarrollo realiza.
• Asegurar que la lista del producto es visible, trasparente y clara para todos y que muestra aquello en lo que el equipo trabajara a continuación.
• Ayuda al refinamiento de las historias de usuario.
• El producto Owner puede hacer revisiones temprana de como va el Sprint.

Para que el Product Owner pueda hacer bien su trabajo toda la organización debe respetar sus decisiones.

Responsabilidades

Características

Product Owner y Scrum Master – Cómo son sus roles

Product Owner: Principales (no todas) responsabilidades

Equipo de Desarrollo(Development Team)

Son los profesionales que realizan el trabajo de entregar un incremento del producto que se pueda poner en producción al fin. Solo los miembros del equipo de desarrollo participan en la creación del incremento.

Un incremento «Terminado» es obligatorio en cada Sprint

La organización es la que se encarga de estructura y empoderar a los Equipos de desarrollo para que estos organicen y gestionen su propio trabajo.

Características

El equipo de desarrollo tiene las siguientes características:

• Son auto organizados. Nadie ni el Scrum Master, indica al Equipo de desarrollo como convertir la Lista del Producto en incrementos de funcionalidad.
• Los equipos de desarrollo son multinacionales, es decir que el equipo cuenta con todas las habilidades necesarias para crear un incremento del producto.
• Scrum no reconoce títulos para los miembros de un equipo de desarrollo independientemente del trabajo que realice cada persona.
• Scrum no reconoce subequipos en los equipos de desarrollo. No importan los dominios que requieran tenerse en cuenta, como pruebas arquitectura, operaciones, etc.
• Los miembros individuales del Equipo de desarrollo pueden tener habilidades especializadas y áreas en las que estén mas enfocadas, pero la responsabilidad recae en el Equipo de desarrollo como un todo.
• Colaboracion
• Altamente motivados
• Proactivos
• Expertos tecnicos
• Buen Miembro de equipo
• Independientes
• Responsables
• Intuitivos
• Orientados a los objetos

Responsabilidades

• Asegurar una compresión clara de los requerimientos
• Estimar las Historias de Usuario Aprobadas por el Product Owner.
• Crear entregables de alta calidad.
• Desarrollar la lista de tareas basada en las Historias de Usuario Aprobadas.
• Calcular el esfuerzo para las tareas
• Desarrollar el Sprint Backlog y el Sprint Burdown Chart
• Crear los entregables
• Identificar el riesgo y ejecutar acciones para su mitigacion
• Identificar oportunidades de mejora
• Participar en la retrospectiva del proyecto Sprint

Tamaño del equipo de desarrollo

El equipo de desarrollo es lo suficiente pequeño como para permanecer ágil y lo suficientemente grande como para completar la cantidad de trabajo significativa. Tener menos de 3 miembros en el equipo reduce la iteracion y las ganancias de productividad mas pequeñas. Tener mas de 9 miembros en el equipo requiere demasiada coordinación.

El dueño del producto(Producto Owner) y Scrum Master no cuentan en el calculo del tamaño de equipo de desarrollo a menos que también este contribuyendo a trabajar en la lista de pendientes de Sprintp(Sprint Backlog).

Scrum Master

El Scrum Master es un evangelizador de Scrum, hacen esto ayudando a todos a entender la teoría, practicas, reglas y valores Scrum.

Caracteristicas

• El Scrum máster es un lider que esta al servicio del equipo scrum.
• El Scrum master ayuda a las personas externa al equipo Scrum a entender que interacciones con el equipo Scrum son útiles y cuales no.
• El Scrum master ayuda a modificar las interacciones para maximizar el valor con el equipo Scrum

Servicio del Scrum Master al Dueño del Producto(Product Owner)

El scrum master entrega servicios al dueño del producto como:

• Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por el equipo scrum.
• Encontrar técnicas para gestionar la lista de productos de manera efectiva
• Ayudar a entender al equipo Scrum la necesidad de contar contar con elementos de Lista de productos claros y concisos. 
• Entender la planificación del producto en un entorno empírico
• Asegurar que el dueño del producto sepa como ordenar la lista de producto para maximizar el valor.
• Entender y practicar la agilidad.
• Facilitar los eventos de scrum segun se requiera

Servicio del Scrum Master al Equipo de Desarrollo

El scrum master entrega servicios al equipo de desarrollo como:

• Guiar al equipo de desarrollo a ser autorganizado y multifuncional
• Ayudar al equipo de desarrollo a crear productos de alto valor.
• Eliminar impedimentos para el progreso del Equipo de Desarrollo
• Facilitar los eventos Scrum según se requiera
• Guiar al equipo de desarrollo en entornos organizarles en los que Scrum no haya sido adoptado y entendido por completo

Servicio del Scrum Master a la Organización

• Liderar y guiar a la organización a la adaptació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.

StakeHolders se dividen en:

• Clientes: El cliente es la persona o la organización que adquiere el producto del proyecto, servicio o cualquier otro resultado.

• Usuarios: El usuario es el individuo o la organizaron que utiliza directamente el producto del proyecto, servicio o cualquier otro resultado; también en algunas industrias el cliente y los usuarios puede ser lo mismo.
• Patrocinador: El patrocinador es la persona o la organización que provee recursos y apoyo para el proyecto, el patrocinador también es el StakeHolder a quien todos le deben rendir cuentas al final.

Eventos de Scrum

Scrum cuenta con eventos definidos los cuales permiten crear regularidades y minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos de Scrum son bloques de tiempo(time-boxes) de tal modo que todos tienen una duración máxima. 

Una vez que comienza un Sprint( evento que contiene eventos), su duración es fija y no puede acortarse o alargarse. 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.

Los eventos fueron diseñados específicamente para habilitar los pilares vitales de transparencia e inspección. La falta de alguno de los eventos da como resultado una reducción de la transparencia y constituye una oportunidad perdida de inspección y adaptación. 

El Sprint

Es el corazón de Scrum, el cual es un bloque de tiempo(time-box) de un mes o menos, durante el cual se crea un incremento de producto «Terminado» utilizable y potencialmente desplegable.

Los Sprints contienen y consisten en:

• La Planificación del Sprint(Sprint Planning)
• Los Scrums Diarios(Daily Scrums)
• El Trabajo de Desarrollo
• La Revision del Sprint(Sprint Review)
• La Retrospectiva del Sprint(Sprint Retrospective)

Durante el Sprint:

• No se realizan cambios que puedan afectar al objetivo del Sprint(Sprint Goal).
• Los objetivos de calidad no disminuyen.
• El alcance puede clarificarse y renegociarse entre el Dueño de Producto  Equipo de Desarrollo a medida que se va aprendiendo mas.

Que tiene un Sprint:

• Un diseño.
• Un plan flexible que guiara la construcción.
• El trabajo del equipo.
• El incremento de producto resultante.

Tips

• Es mas conveniente si la duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo.
• Cada Sprint comienza inmediatamente después de la anterior finalizacion del Sprint anterior

Ventajas

• Habilitan la predictibilidad al asegurar la inspección y adaptación del progreso al menos en cada mes calendario.
• Limitan el riesgo al costo de 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 incrementarse y el riesgo podría aumentar.

Cancelación de un Sprint

Solo el dueño del producto(Producto Owner) tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de los interesados, del equipo de desarrollo o del Scrum máster.

Un sprint se cancelaría si el Objetivo del Sprint llega a quedar obsoleto. En general el Sprint debería cancelarse si no tuviese sentido seguir con él dadas la circunstancias.

El objetivo del Sprint puede quedar obsoleto si la compañía cambia la dirección o si las condiciones del mercado o de la tecnología cambian.

Cuando se cancela un Sprint se

• Revisan todos los Elementos de la lista de Producto que se hayan completado y «terminado».
• Si una parte del trabajo es potencialmente entregable, el Dueño de Producto normalmente la acepta.
• Todos los elementos de la Lista de Producto no completados se vuelve a estimar y se vuelven a introducir en la Lista de Producto. El trabajo finalizado en ellos pierde valor con rapidez y por lo general se debe volver a estimar.

Las cancelaciones de Sprint consumen recursos ya que todos se reagrupan en otra 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.

1. Planificación de Sprint(Sprint Planning)

El trabajo a realizar en el Sprint se planifica en la planificación de Sprint. Este plan se crea mediante el trabajo colaborativo del Equipo Scrum completo.

Tiene un máximo de duración de 8 horas para un Sprint de un mes. Para sprint mas cortos el evento es usualmente mas corto.

Tips

• 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(time-box).
• El Equipo de desarrollo asigna pesos a las historias de usuario.

La planificación de Sprint responde a la preguntas:

• ¿Que puede entregarse en el incremento resultante del Sprint que comienza?: Esta pregunta ayuda para que el Development Team trabaje para proyectar la funcionalidad que se desarrollara durante el Sprint, donde se define objetivo del Sprint(Sprint Goal)
• ¿Como se conseguirá hacer el trabajo necesario para entregar el incremento?

Tema Uno: ¿Que puede hacerse en este Sprint?

Entradas de esta reunión:

• Lista de Producto(Product Backlog)
• El ultimo incremento de Producto
• La capacidad Proyectada del Equipo de Desarrollo para el Sprint
• El rendimiento pasado del Equipo de Desarrollo

El numero de elementos de la lista de Producto seleccionados para el sprint depende únicamente del Equipo de Desarrollo. Solo el Equipo de desarrollo puede evaluar que es capaz de lograr durante el Sprint que comienza.

Tips

• El equipo de desarrollo trabaja para proyectar la funcionalidad que se desarrollara durante el Sprint.
• El dueño del producto discute el objetivo que el Sprint deberia lograr y los Elementos de la Lista de Producto que si se completan en el Sprint, lograrían el Objetivo del Sprinit.
• El equipo Scrum completo colabora en el entendimiento del trabajo del Sprint.
• El Equipo Scrum define un Objetivo del Sprint(Sprint Goal), el cual debera lograrse durante el Srpint a traves de la implementacion de la Lista de Producto. El Sprint Goal proporciona una guia al equipo de desarrollo de por que esta construyendo esto.
• Se realiza la estimación del Product Backlog utilizando Planning Poker asignando un peso para cada historia de usuario.
• Seleccionar las historias de usuario que sumados sus pesos no superen el peso de la velocidad del equipo de Desarrollo.

Tema Dos: ¿Como se conseguirá completar el trabajo seleccionado?

Una vez que se ha establecido el objetivo y seleccionado los elementos de la lista de Producto para el Sprint, el Equipo de Desarrollo decide como construirá esta funcionalidad para formar un incremento de producto «Terminado» durante el Sprint.

Los elementos de la Lista de Producto(Producto Backlog) seleccionados para este Sprint, mas el plan para terminarlos, recibe el nombre de Lita de Pendientes del Sprint(Sprint Backlog)

Tips

• El Equipo de Desarrollo por lo general comienza Diseñando el sistema y el trabajo necesario para convertir la Lista de Producto en un incremento de producto funciona.
• El trabajo podría ser de tamaño o esfuerzo estimado variable sin embargo la planificación del Sprint se realiza planificando suficiente trabajo como para que el Equipo de Desarrollo pueda hacer una proyección de lo que cree que puede completar en el Sprint que comienza.
• El dueño del Producto puede ayudar a clasificar los elementos de la Lista de Producto seleccionados y hacer conceciones.
• Si el Equipo de Desarrollo determina que tiene demasiado trabajo o que no tiene suficiente trabajo, podría renegociar los elementos de la Lista de Producto seleccionados con el Dueño de Producto.
• El Equipo de Desarrollo podría también invitar a otras personas a que asistan para que proporcionen asesoría técnica o relacionada con el dominio.

Para el final de la reunión el trabajo planificado por el equipo de Desarrollo para los primeros dias del Sprint es descompuesto en unidades de un dia o menos. Al finalizar la Planificación del Sprint, el Equipo de Desarrollo debería ser capaz de explicar al Dueño de Producto y al Scrum Master cómo pretende trabajar como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado.

Estimación

Usando la técnica de Planning Poker se puede conseguir el esfuerzo que se requiere realizar en el Sprint.

Objetivo del Sprint(Sprint Goal) 

Es una meta para el Sprint que puede lograrse mediante la implementacion del Sprint Backlog que tiene el Sprint.

Tips

• Proporciona una guía al Equipo de Desarrollo acerca de por que se esta construyendo el incremento.
• Se crea durante la planificación de Sprint.
• El objetivo del Sprint brinda al equipo de desarrollo flexibilidad con respecto implementada en el Sprint.
• Los elementos del Product Backlog ofrecen una función coherente que puede ser objetivo del Sprint.
• El objetivo del Sprint puede representar otro nexo de union que haga que el Equipo de Desarrollo trabaje en conjunto y no en iniciativas separadas.
• Con el fin de satisfacer el objetivo del Sprint, el equipo implementa funcionalidad y tecnologia.
• Si el trabajo resulta ser diferente de lo que el Equipo de Desarrollo espera, ellos colaboraran con el dueño de producto para negociar el alcance de la lista de pendientes del Sprint(Sprint Backlog).

2. Scrum Diario(Daily Scrum)

Es una reunión de 15 minutos para el Equipo de Desarrollo donde se planea el trabajo para las siguientes 24 horas. 

• El Scrum Diario se lleva a cabo cada dia del Sprint. 
• El Equipo de Desarrollo planea el trabajo para las siguientes 24 horas. Esto optimiza la colaboración y el desempeño del equipo inspeccionando el trabajo avanzado desde el último Scrum Diario y haciendo una proyección del trabajo del Sprint a realizar a continuación.
• El Scrum Diario se realiza a la misma hora y en el mismo lugar todos los días para reducir la complejidad.
• El Equipo de Desarrollo 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 Lista de Pendientes del Sprint.
• El Scrum Diario optimiza las posibilidades de que el Equipo de Desarrollo cumpla el Objetivo del Sprint.
• Cada día, el Equipo de Desarrollo debería entender cómo intenta trabajar en conjunto como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado hacia el final del Sprint.

El Equipo de Desarrollo es el encargado de establecer la estructura de la reunión y esta se puede conducir de diferentes maneras si se enfoca en el progreso hacia la Meta de Sprint. Algunos Equipos de Desarrollo usarán preguntas, algunos se basarán más en discusiones. Aquí hay un ejemplo de lo que podría usarse:

• ¿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 Equipo de Desarrollo o los miembros del equipo a menudo se vuelven a reunir inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para adaptar o replanificar el resto del trabajo del Sprint.

El Scrum Master se asegura de que el Equipo de Desarrollo tenga la reunión pero es el Equipo de Desarrollo el responsable de dirigir el Scrum Diario. El Scrum Master enseña al Equipo de Desarrollo a mantener el Scrum Diario en los límites del bloque de tiempo de 15 minutos. 

El Scrum Diario es una reunión interna del Equipo de Desarrollo. Si otras personas están presentes, el Scrum Master se asegura de que no interrumpan la reunión.

Ventajas

• Mejoran la comunicacion
• Eliminan la necesidad de realizar otras reuniones
• Identifican impedimentos a remover relativos al desarrollo
• Resaltan y promueven la toma rapida de decisiones y mejoran el nivel de conocimiento del Equipo de Desarrollo.
• Es una reunión clave de inspección y adaptación.

3. Revision de Sprint(Sprint Review)

Al final del Sprint se lleva a cabo una Revisión de Sprint para inspeccionar el Incremento y adaptar la Lista de Producto si fuese necesario.

Tips

• Durante la revisión el Equipo Scrum y los interesados colaboran acerca de que fue lo que se hizo durante el Sprint.
• Es una reunión informal no una reunión de seguimiento.
• La presentación del incremento tiene como objetivo facilitar la troalimentacion de información y fomentar la colaboración.

Reunión que tiene una duración de 4 horas para Sprint de un mes y para Sprints mas cortos el evento usualmente es mas 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 a todos a mantener el evento dentro del bloque de tiempo fijado.

En la revisión de Sprint incluyen los siguientes elementos:

• Los asistentes son el equipo Scrum y los interesados clave invitados por el dueño del Producto.
• El dueños de Producto explica que los elementos del Producto Backlog se han «Terminado» y cuales no.
• El equipo de desarrollo habla acerca de que estuvo bien durante el Sprint, que problemas aparecieron y como fueron resueltos esos problemas
• El equipo de desarrollo hace una demostración del trabajo que ha «Terminado» y responde a preguntas acerca del incremento.
• El dueño del producto habla acerca del Producto Backlog en su estado actual. Proyecta objetivos probables y fechas de entrega en el tiempo basándose en el progreso obtenido hasta la fecha.
• El grupo completo colabora de que hacer a continuación, de modo que la revisión del Sprint proporcione información de entrada valiosa para Reuniones de Planificacion de Sprint subsiguientes.
• Revision de como el mercado o el uso potencial del producto podría haber cambiado lo que es mas de valor para hacer a continuación.
• Revision de linea de tiempo, presupuesto, capacidades potenciales y mercado para las próximas entregas de funcionalidad o capacidad prevista del producto.

4. Retrospectiva de Sprint(Sprint Retrospective)

La retrospectiva de Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a si mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint.

El Sprint Retrospective tiene lugar después de la revisión de Sprint antes de la siguiente Planificacion de Sprint(Sprint Plannin)

Es una reunión de maso menos 3 horas para sprint de un mes, para sprints mas cortos el evento suele ser mar corto. 

Tips

• El Scrum master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito.
• El Scrum master se asegura que la reunion sea positiva y productiva.
• El Scrum master enseña a todos a mantener el evento dentro del bloque de tiempo fijado.
• El Scrum master participa en la reunion como un miembro del equipo ya que la responsabilidad del proceso Scrum recae sobre él.

Propósito del evento:

• Inspeccionar como fue el ultimo Sprint en cuanto a personas, relaciones, procesos y herramientas.
• Identificar y ordenar los elementos mas 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 máster alienta al equipo para que mejore, dentro del marco de proceso Scrum, su proceso de desarrollo y sus practicas para hacerlos mas efectivos y amenos para el siguiente sprint.

Durante cada Retrospectiva de Sprint, el Equipo Scrum planifica formas de mejorar la calidad del producto mediante el mejoramiento de la calidad de los procesos o adaptando la Definición de “Terminado” (Definition of “Done”) según sea conveniente y no entre en conflicto con los estándares del producto u organizacionales.

Para el final de la Retrospectiva de Sprint el Equipo Scrum debería haber identificado mejoras que implementara en el próximo Sprint. El hecho de implementar estas mejoras para el siguiente Sprint constituye la adaptación subsecuente a la inspección del Equipo Scrum 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.

Etapas de las retrospectiva

Son etapas que ayudarían a entender como se podria mejorar el desempeño para los siguientes sprints

1. Dar inicio a la reunión
2. Reunir datos que sean relevantes de ese Sprint (Lluvia de ideas)
3. Interiorizarlo
4. Tomar Accion
5. Cerrar

Artefactos Scrum

Los artefactos Scrum representan trabajo o valor en diversas formas que son útiles para proporcionar trasparencia 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 la cual es necesaria para asegurar que todos tengan el mismo entendimiento del artefacto.

Lista de Producto(Product Backlog)

La lista de producto es una lista ordenada de todo lo que se conoce que es necesario en el producto.

El Product Owner es el único responsable del Product Backlog, incluyendo su contenido, disponibilidad y ordenación.

La lista de producto enumera todas las características, funcionalidades, requisitos, mejoras y correcciones que constituyen cambios a realizarse sobre el producto para entregas futuras.

Atributos de los elementos del Product Backlog:

• Descripcion
• Orden
• Estimacion
• Valor

Los de la lista de producto muchas veces incluyen descripciones de las pruebas que demostraran la completitud de tales elementos cuando este «terminados». Requisitos que debe cumplir para considerarse completado el elemento.

Los requisitos nunca dejan de cambiar asi que el Product 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 la lista de producto. 

Puede usarse emplearse un atributo de la lista de Producto para agrupar los elementos.

Refinamiento(Refinement)

Es un acto de añadir detalle, estimaciones y orden a los elementos de la lista de Producto. Se trata de un proceso continuo en el cual el Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos de la Lista de Producto.

El refinamiento se realiza en los Sprint Planning

Durante el refinamiento se examinan y revisan sus elementos, el equipo Scrum decide como y cuando se hace el refinamiento, este usualmente consume no mas del 10% de la capacidad del Equipo de Desarrollo. Sin embargo los elementos de la Lista de Producto pueden actualizarse en cualquier momento por el Dueño de Producto a criterio suyo.

Tips

• Una lista de producto nunca esta completa
• El desarrollo mas temprano de la lista de producto solo refleja los requisitos conocidos y mejor entendidos.
• La lista de Producto evoluciona a medida de que el producto y el entorno en el que se usara también lo hacen.
• La lista de producto es dinámica, cambia constantemente para identificar lo que el producto necesita para ser adecuado, competitivo y útil.
• Si un producto existe, su lista de producto también existe.
• Los elementos de la Lista de Producto de orden mas alto son generalmente mas claros y detallados que los de menor orden.
• Se realizan estimaciones mas precisas basándose en la mayor claridad y detalle, cuanto mas alto es el orden menor es el detalle. 
• Los elementos de la lista de Producto de los que se ocupara el Equipo de Desarrollo en el siguiente Sprint tienen una granularidad mayor, habiendo sido descompuestos de forma que cualquier elemento pueda ser «Terminado» dentro de los limites del bloque de tiempo del Sprint.
• El equipo de desarrollo es el responsable de proporcionar todas las estimaciones. El dueño de Producto podría influenciar al Equipo ayudandoles a entender y seleccionar sus compromisos, pero las personas que harán el trabajo son las que hacen la estimación final.

Los elementos de la lista de Producto que pueden ser «Terminados» por el equipo de desarrollo en un sprint son considerados «Preparados» o «Accionables» para ser seleccionados en una reunion de planificacion de Sprint(Sprint Planning)

Seguimiento de Progreso Hacia los Objetivos

En cualquier momento es posibler sumar el trabajo total restante para alcanzar el objetivo. El dueño de Producto hace seguimiento a este trabajo restante total al menos en cada Revision de Sprint. El Dueño de Producto compara esta cantidad con el trabajo restante en Revisiones de Sprint previas, para evaluar el progreso hacia la finalizacion del trabajo proyectado en el tiempo deseado para el objetivo. Esta informcion se muestra de forma trasparente a todos los interesados.

Practicas de proyección de tendencias para predecir el progreso:

• Trabajo pendiente: Burndown
• Trabajo Completado: Burnup
• Flujo Acumulado: Cumulative Flow

Estas practicas sopn utilies sin embargo no reemplazan la importancia del empirismo. Ya que en entornos complejos se desconoce que ocurrira, solo lo que ya ha ocurrido puede utilizarse para la toma de decisiones con miras al futuro.

Lista de Pendientes del Sprint(Sprint Backlog)

La lista de pendientes es un conjunto de elementos de la lista de Productos seleccionados para el Sprint, mas un plan para entregar el Incremento de Producto y conseguir el objetivo del Sprint.

La lista de pendientes es una predicción hecha por el Equipo de Desarrollo acerca de que funcionalidad formara parte del Proximo incremento y del trabajo necesario para entregar esa funcionalidad en un incremento «Terminado».

Cuando se requiere un nuevo trabajo , el Equipo de Desarrollo lo adiciona a la Lista de Pendientes del Sprint. A medida que el trabajo se ejecuta se va actualizando la estimación de trabajo restante.

 Tips

• La Lista de Pendientes del Sprint hace visible todo el trabajo que el Equipo de Desarrollo identifica como necesario para alcanzar el Objetivo del Sprint.
• Para asegurar el mejoramiento continuo, la lista de Pendientes del Sprint incluye almenos una mejora de procesos de alta prioridad identificada en la retrospectiva inmediatamente anterior.
• La lista de Pendientes 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 Equipo de Desarrollo modifica la lista de pendientes a lo largo del Sprint y esta lista de Pendientes emerge a lo largo del Sprint, esto ocurre a medida que el equipo de desarrollo trabaja en lo planeado y aprende mas acerca del trabajo necesario para conseguir el Objetivo del Sprint.
•  Cuando algún elemento del plan se considera innecesario, es eliminado.
• Solo el Equipo de Desarrollo puede cambiar su Lista de Pendientes del Sprint durante un Sprint.
• La Lista de Pendientes del Sprint es una imagen visible en tiempo real del trabajo que el Equipo de Desarrollo planea llevar a cabo durante el Sprint y pertenece únicamente al Equipo de Desarrollo. 

Priorizacion

• Las decisiones del Dueño de Producto se reflejan en el contenido y en la priorización de la Lista del Producto.
• Nadie puede forzar al Equipo de Desarrollo a que trabaje con base en un conjunto diferente de requisitos.
• El Dueño de Producto podría representar los deseos de un comité en la Lista del Producto, pero aquellos que quieran cambiar la prioridad de un elemento de la Lista deben hacerlo a través del Dueño de Producto

Seguimiento del Progreso del Sprint

El equipo de Desarrollo 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 Equipo de Desarrollo puede gestionar su progreso.

Incremento

El incremento es la suma de todos los elementos de la Lista de Producto completados durante un Sprint y el valor de los incrementos de todos los Sprint anteriores.

Al final de un Sprint el nuevo Incremento debe estar «Terminado», lo cual significa que esta en condiciones de ser utilizando y que cumple la definición de «Terminado» del Equipo Scrum.

Un incremento es un cuerpo de trabajo inspeccionable y terminado que respalda el empirismo al final del Sprint. EL incremento es un paso hacia una visión o meta. El incremento debe estar en condiciones de utilizarse sin importar si el Dueño de Producto decide liberarlo o no

Transparencia de los Artefactos

Scrum se basa en la transparencia. Las decisiones para optimizar el valor y controlar el riesgo se toma basadas  en el estado percibido de los artefactos.

• En la medida que los artefactos no son completamente trasparentes estas decisiones pueden ser erróneas, el valor puede disminuir y el riesgo puede aumentar.

El scrum master debe trabajar con el Producto Owner, el Development Team y otras partes involucradas para entender si los artefactos son completamente trasparentes. Hay practicas para hacer frente a la falta de transparencia, el Scrum master Debe ayudar a todos a aplicarlas practicas mas apropiadas si no hay una transparencia completa.

El scrum master puede detectar la falta de transparencia inspeccionado 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
• cambio.

 La transparencia no ocurre de la noche a la mañana, sino que es un camino.

Historias de Usuario

Clasificación

• Épicas: Es una historia de usuario que es demasiado grande para caber en un sprint. A menudo grande para caber en un sprint. Generalmente ese termino se utiliza para describir una gran historia de usuario que tendrá que ser dividida en historias mas pequeñas.
• Historias de Usuario: Es una representación de un requisito del usuario en forma escrita, de una o dos frases utilizando el lenguaje común del usuario.
• Task: Es una representación del requisito que esta en lenguaje del usuario, pero de una forma técnica donde esta definido como se va a trabajar y quien va a participar.

Nivel de detalle

¿Como esta conformada?

Una historia de usuario debe estar conformada por las 3C

• Card(tarjeta): Descripción escrita de lo que necesita el usuario.
• Conversación: El Product Owner y Development Team aclaran los detalles
• Confirmación: Sirve para determinar lo que se espera.

Características

Modelo INVEST

• Independencia
• Negociables
• Valiosa
• Estimable
• Pequeña
• Verificable

Estructura

Tarea(Task)

Es el trabajo técnico que realiza un equipo de desarrollo para completar un item de retraso acumulado para el producto.

La mayoría de las tareas se definen como pequeñas, lo que representa no mas de unas pocas horas a un dia mas o menos de trabajo.

¿Como esta conformada una tarea?

Caracteristicas

Usando el modelo SMART:

• S: Specific(Especifico)
• M: Measurable (Medible)
• A: Achievable (Alcanzable)
• R: Relevant (Relevante)
• Time-boxed (Tiempo-caja)

Time-Boxing

Ventajas

Time-boxing es una practica critica en Scrum y debe aplicarse con cuidado.

Un Time-boxing arbitratio puede llevar a la desmotivacion del equipo y puede tener como consecuencia la creación de un entorno opresivo, por lo que debe ser utilizado de manera apropiada.

Beneficios

• Procesos de desarrollo eficiente
• Menos gastos generales
• Alta velocidad para los equipos
• Ayuda a gestionar eficazmente la planificación y ejecución de proyectos.

¿Donde se utilizan?

Declaraciones de Interdependencia

La Declaración de interdependencia en la gestión de proyectos fue escrita a principios del 2005 por un grupo de 15 líderes de proyectos como un suplemento al “Manifiesto Ágil”

1. Aumentamos el retorno de inversión, al enfocarnos en el flujo continuo de valor.
2. Ofrecemos resultados fiables mediante la participación del cliente en las iteraciones frecuentes, donde también son responsables por el trabajo.
3. Asumimos que habrá incertidumbre y las superamos a través de iteraciones, anticipación y adaptación.
4. Damos rienda suelta a la creatividad y la innovación al reconocer que las personas son la fuente máxima de valor y creamos un entorno en el que puedan tener un impacto positivo.
5. Aumentamos el rendimiento a través de la rendición de cuentas por parte del grupo en cuestión de resultados y eficacia del equipo, responsabilidades que todos comparten.
6. Mejoramos la eficacia y la fiabilidad a través de estrategias situacionalmente específicas, procesos y prácticas

Notas Adicionales

Nota 1

En el Scrum Diario (Daily Scrum) el Scrum Master se asegura de que el Equipo de Desarrollo tenga la reunión, pero es el Equipo de Desarrollo el responsable de dirigir el Scrum Diario. El Scrum Master enseña al Equipo de Desarrollo a mantener el Scrum Diario en los límites del bloque de tiempo de 15 minutos. El Scrum Diario es una reunión interna del Equipo de Desarrollo. Si otras personas están presentes, el Scrum Master se asegura de que no interrumpan la reunión.

Nota 2

Uno de los principales objetivos de un equipo auto-organizado es mantener la estabilidad de los miembros del equipo durante la duración del proyecto al no cambiar los miembros, a menos que sea inevitable.

Nota 3

El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto (Product Backlog). La gestión de la Lista del Producto incluye optimizar el valor del trabajo que el Equipo de Desarrollo realiza.

Nota 4

A menudo, varios Equipos Scrum trabajan juntos en el mismo producto. Para describir el trabajo a realizar sobre el producto se utiliza una única Lista de Producto (Product Backlog). En ese caso podría emplearse un atributo de la Lista de Producto para agrupar los elementos.

Nota 5

El Sprint, es un bloque de tiempo de un mes o menos el cual termina cuando su time-box expira y se crea un incremento de producto “Terminado”utilizable y potencialmente desplegable.

Nota 6

En la reunión de Revisión de Sprint:

•  El Dueño de Producto explica qué elementos de la Lista de Producto se han “Terminado” y cuales no se han “Terminado, por otro lado.
• El Equipo de Desarrollo hace una demostración del trabajo que ha “Terminado” y responde preguntas acerca del Incremento.
• El Dueño de Producto habla acerca de la Lista de Producto en su estado actual. Proyecta objetivos probables y fechas de entrega en el tiempo basándose en el progreso obtenido hasta la fecha (si fuera necesario)

Nota  7

El Scrum Diario se realiza a la misma hora y en el mismo lugar todos los días para reducir la complejidad.

Nota 8

Si hay múltiples Equipos Scrum trabajando en la entrega del sistema o producto, los Equipos de Desarrollo en todos los Equipos Scrum deben definir enconjunto la definición de “Terminado”.

Notas 9

Los Equipos de Desarrollo son multifuncionales, y como equipo deben contar con todas las habilidades necesarias para crear un Incremento de producto, por lo que dentro del equipo multifuncional, es importante contar con las habilidades necesarias para llevar a cabo actividades del proyecto, aunque en ocasiones los Equipos de Desarrollo podrían encontrar limitaciones en cuanto a las habilidades necesarias durante un Sprint, por ejemplo en pruebas, control de calidad, herramientas y entornos de pruebas.

Nota 10

El Sprint Backlog es una predicción hecha por el Equipo de Desarrollo acerca de qué funcionalidad formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en un Incremento “Terminado”. El Sprint Backlog es propiedad del Equipo de Desarrollo, no de sus miembros.

Nota 11

Scrum se basa en la teoría de control de procesos empírica o empirismo. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce.

En Scrum, las decisiones se basan en la observación y la experimentación en vez de la planificación inicial detallada. El control del proceso empírico se basa en las tres ideas principales de la transparencia, inspección y adaptación.

Nota 12

Al utilizar la terminología ya utilizada en la organización, la gerencia se puede sentir menos ansiosa. Además, sin un nuevo vocabulario como un recordatorio del cambio, solo un cambio muy pequeño en realidad podría suceder. Por otro lado, la organización no podrá entender lo que ha cambiado con Scrum y el valor agregado del Framework, así como también las ventajas de Scrum se pueden perder.

Nota 13

El tamaño óptimo del Equipo de Desarrollo 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 Equipo de Desarrollo reduce la interacción y resulta en ganancias de productividad más pequeñas. Tener más de nueve miembros en el equipo requiere demasiada coordinación

Nota 14

Un Sprint puede cancelarse antes de que el bloque de tiempo llegue a su fin. Solo el Dueño de Producto 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. Sin embargo, debido a la corta duración de los Sprints, su cancelación rara vez tiene sentido.

Nota 15

El Dueño de Producto (Product Owner) es el responsable de la Lista de Producto (Product Backlog), incluyendo su contenido, disponibilidad y ordenación de los elementos de la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible.

Los elementos de la Lista de Producto 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.

Nota 16

Quién debe saber más sobre el progreso hacia un objetivo de negocio o una entrega es el Dueño del producto (Product Owner) por ser la «voz del cliente». El Scrum Master es quien más sabe sobre dirección del equipo y eliminación de obstáculos. El Equipo de Desarrollo debe trabajar para terminar los elementos, y no se le debe molestar pidiéndole y rastreando el avance de objetivos del negocio. Por otro lado, el rol de Project Manager no existe en el framework de Scrum.

Nota 17

La reunión de retrospectiva del sprint es un elemento importante del framework de “inspección-adaptación” de Scrum y es el último paso en un sprint. Todos los miembros del Equipo Scrum (Product Owner, Development Team, Scrum Master) asisten a la reunión, misma que organiza y modera el Scrum Master. Se recomienda que asista el Product Owner, aunque no es obligatorio. Un integrante del equipo se desempeña como secretario y documenta las discusiones y los elementos para acciones a futuro. Es esencial celebrar esta reunión es un entorno abierto y relajado a fin de fomentar la completa participación de todos los miembros del equipo. Las discusiones en la reunión de retrospectiva del sprint abarcan tanto lo que salió mal como lo que salió bien.

Nota 18

El acrónimo DEEP resume los atributos clave de un buen Product Backlog:

• Detalladamente (Detailed appropriately). Las historias de usuarios sobre el Product Backlog que se realizarán pronto deben entenderse lo suficiente como para que puedan completarse en el próximo sprint. Las historias que no se desarrollarán por un tiempo se deben describir con menos detalles.
• Estimado (Estimated). Product Backlog es más que una lista de todo el trabajo por hacer; también es una herramienta de planificación útil. Debido a que los elementos que están más abajo en la lista de espera aún no se conocen bien (todavía), las estimaciones asociadas con ellos serán menos precisas que las estimaciones de los elementos que se encuentran en la parte superior.
• Emergente (Emergent). Un Product Backlog no es estático. Cambiará con el tiempo. A medida que se aprenda más, las historias de usuario en el Product Backlog se agregarán, eliminarán o cambiarán de prioridad.
• Priorizado (Prioritized). El Product Backlog debe clasificarse con los elementos más valiosos en la parte superior y los menos valiosos en la parte inferior. Al trabajar siempre en orden de prioridad, el equipo puede maximizar el valor del producto o sistema que se está desarrollando.

Nota 19

El Sprint Burndown Chart debe actualizarse por el Scrum Master o el Equipo de Desarrollo al final de cada día conforme se concluye el trabajo. Dicha gráfica muestra el progreso que ha realizado el Equipo de Desarrollo y permite también la detección de estimaciones que pudieron haberse hecho incorrectamente. Si el Sprint Burndown Chart muestra que el Equipo de Desarrollo no va por el rumbo correcto en la conclusión a tiempo del sprint, el Scrum Master debe identificar cualquier obstáculo o impedimento de una conclusión satisfactoria e intentar eliminarlos.

Nota 20

Priorizado (Prioritized). El Product Backlog debe clasificarse con los elementos más valiosos en la parte superior y los menos valiosos en la parte inferior. Al trabajar siempre en orden de prioridad, el equipo puede maximizar el valor del producto o sistema que se está desarrollando.

Nota 21

El refinamiento se trata de un proceso continuo en el cual el Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos de la Lista de Producto. Durante el refinamiento de la Lista de Producto, 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 Equipo de Desarrollo.

Nota 22

Cada Equipo de Desarrollo debe tener un Product Owner, ya que él es el responsable de optimizar el valor del trabajo que el Equipo de Desarrollo realiza.

Nota 23

El Scrum Master se asegura de que la reunión de Retrospectiva de Sprint (Sprint Retrospective) sea positiva y productiva. Para lo cual, 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.

Nota 25

Cuando un elemento de la Lista de Producto o un Incremento sedescribe como “Terminado” (Done), todo el mundo debe entender lo que significa“Terminado”. Lo cual puede variar 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.

Nota 26

En Scrum los Equipos de Desarrollo son por naturaleza auto- organizados y empoderados, donde nadie tiene una verdadera autoridad sobre otro integrante del equipo. Aunque el Equipo de Desarrollo puede incluir personas con diferentes niveles de experiencia y conocimientos, cada miembro se trata por igual y nadie tiene la autoridad de ser el principal tomador de decisiones.

Nota 27

Debido a que Scrum requiere que el trabajo se realice en incrementos durante los Sprints, esto hace que los errores o defectos se noten con más facilidad mediante pruebas de calidad repetitivas y no simplemente cuando el producto final o servicio esté casi terminado. Por otra parte, las tareas relacionadas a la calidad (por ejemplo, desarrollo, pruebas y documentación) se completan como parte del mismo sprint por el mismo equipo. Esto asegura que la calidad sea inherente a cualquier entregable que se crea como parte de un sprint.

Nota 28

El Product Owner es la persona responsable de lograr el máximo valor empresarial para el proyecto, así como también es responsable de la articulación de requisitos del cliente y de mantener la justificación del negocio para el proyecto.

Nota 29

Scrum Diario (Daily Scrum) es una reunión con un bloque de tiempo de 15 minutos para el Equipo de Desarrollo. El Scrum Diario se lleva a cabo cada día del sprint. En él, el Equipo de Desarrollo planea el trabajo para las siguientes 24 horas. El Equipo de Desarrollo 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 Lista de Pendientes del Sprint.

Nota 30

El Sprint Backlog es una lista de tareas a ser ejecutadas por el Equipo de Desarrollo en el próximo sprint. El Sprint Backlog contiene el conjunto de elementos del Product Backlog seleccionados para el Sprint, más un plan para entregar el Incremento de producto y conseguir el Objetivo del Sprint.

Nota 40

El Scrum Master es responsable de guiar al Equipo de Desarrollo en entornos organizacionales en los que Scrum aún no haya sido adoptado y entendido por completo. Adicionalmente, debe liderar y guiar a la organización en la adopción de Scrum. También, es responsable de asegurarse de que todos los miembros del equipo, incluyendo el Product Owner estén cumpliendo correctamente el proceso de Scrum.

Nota 41

Todos los eventos de Scrum son bloques de tiempo (time-boxes), de tal modo que todos tienen una duración máxima. Scrum trata al tiempo como uno de los limitantes más importantes en la gestión de un proyecto. Para hacer frente a la restricción del tiempo, Scrum introduce un concepto de Time-boxing (o asignación de un bloque máximo de tiempo), que propone la fijación de una cierta cantidad máxima de tiempo para cada evento en un proyecto Scrum. Esto garantiza que los miembros del Equipo Scrum no ocupen demasiado o muy poco tiempo para un trabajo determinado, y que no desperdicien su tiempo y energía en un trabajo para el cual tienen poca claridad.

Nota 42

Cada historia de usuario contará con sus criterios de aceptación de historia de usuario, que son los componentes objetivos mediante los cuales se juzga la funcionalidad de una historia de usuario. Los criterios de aceptación los desarrolla el Product Owner según su experiencia en los requerimientos del cliente. El Product Owner después comunica las historias de usuario que están en el Product Backlog a los miembros del Equipo Scrum, buscando un común acuerdo. Los criterios de aceptación deben delinear explícitamente las condiciones que deben satisfacer las historias de usuario. Los criterios de aceptación claramente definidos son de suma importancia para la entrega eficaz y oportuna de la funcionalidad definida en las historias de usuario, lo cual, en última instancia, determinan el éxito del proyecto.

Nota 43

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. En Scrum, los Equipos de Desarrollo son multifuncionales, ya que cuentan con todas las habilidades necesarias para crear un Incremento de producto. El uso de equipos multifuncionales garantiza también de que todas las habilidades y conocimientos necesarios para llevar a cabo el trabajo del proyecto existan dentro del equipo.

Nota 44

Se recomienda que los miembros del Equipo trabajen de tiempo completo en el proyecto, por lo que generalmente estarán invirtiendo la mayor parte de su tiempo en realizar el trabajo necesario para generar el Incremento del Sprint.

Nota 45

Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de obtener retroalimentación a través de los eventos de Scrum, incluyendo: los Scrums Diarios (Daily Scrums), la Revisión del Sprint (Sprint Review), y la Retrospectiva del Sprint (Sprint Retrospective).

Nota 46 

Los equipos miembros de un Equipo de Desarrollo no deben tener diferentes Product Owners y Scrum Masters. Cada Equipo de Desarrollo debe tener un único Product Owner y un Scrum Master con los cuales deben colaborar.

Nota 47

Las tareas no se estiman mediante la asignación de puntos de historia, sino a través de esfuerzo (preferentemente en horas). No existen reglas para la asignación de las tareas a ninguno de los miembros del Equipo de Desarrollo.

Nota 48

El Scrum Diario es una reunión interna del Equipo de Desarrollo. Si otras personas están presentes, el Scrum Master se asegura de que no interrumpan la reunión. En caso de que el Product Owner desee participar en el Scrum Diario (Daily Scrum), el Scrum Master debe asegurarse de que le transmita al Equipo de Desarrollo la razón de su participación y de asegurarse de no interrumpir mucho al Equipo.

Preguntas que surgen durante el estudio

¿que son las interacciones?

¿Cual es el plan que se debe entregar en el incremento para cumplir el objetivo del sprint?

¿Cual es la agilidad de Scrum?

¿Como identificar los impedimentos del equipo de Desarrollo?

¿Cuales son los objetivos de calidad de un sprint?

¿Como identificar el objetivos de calidad de un sprint?

¿Como identificar los elementos mas importantes del sprint restrospective?

¿Cuales son las practicas para tener transparencia en los artefactos?

¿Como saber la velocidad del equipo de Desarrollo?

¿Como calcular la capacidad un equipo de desarrollo?

Referencias

• Scrum Basics – Scrum Guides