2017 Scrum Guide US - En.es

La guía Scrum ™
La guía definitiva para Scrum:

Las reglas del juego
Noviembre de 2017
Desarrollado y sostenido por los creadores de Scrum: Ken Schwaber y Jeff Sutherland
Tabla de contenido
Propósito de la Guía Scrum ............................................. .................................................. ............. 3
Definición de Scrum ............................................... .................................................. ......................... 3
Usos de Scrum ............................................... .................................................. .................................. 4
Teoría de Scrum ................................................ .................................................. ................................. 4
Valores Scrum ................................................ .................................................. .................................. 5
El equipo Scrum ............................................... .................................................. .............................. 6
El propietario del producto ............................................... .................................................. ..................... 6
El equipo de desarrollo ............................................... .................................................. .............. 7
El Scrum Master ............................................... .................................................. ....................... 7
Scrum Events ................................................ .................................................. .................................. 9
El Sprint ................................................ .................................................. ................................... 9
Planificación de Sprint ................................................ .................................................. ......................... 10
Scrum diario ................................................ .................................................. ............................... 12
Revisión de Sprint ................................................ .................................................. ........................... 13
Retrospectiva de Sprint ................................................ .................................................. ................. 14
Scrum Artifacts ................................................ .................................................. ............................. 14
Pila de Producto ................................................ .................................................. ........................ 15
Sprint Backlog ................................................ .................................................. ........................... dieciséis
Incremento ................................................. .................................................. ................................ 17
Transparencia de artefactos ................................................ .................................................. ................... 17
Definición de "Hecho" ............................................. .................................................. .................... 18
Nota final ................................................ .................................................. ....................................... 19
Agradecimientos ................................................. .................................................. ..................... 19
Personas ................................................. .................................................. ...................................... 19
Historia ................................................. .................................................. ..................................... 19
© 2017 Ken Schwaber y Jeff Sutherland. Se ofrece para la licencia bajo la licencia Atribución Compartir-Igual de Creative Commons, accesible en
http://creativecommons.org/licenses/by-sa/4.0/legalcode y también se describe en forma resumida en http://creativecommons.org/licenses/ by-sa / 4.0
/. Al utilizar esta Guía Scrum, usted reconoce y acepta que ha leído y acepta estar sujeto a los términos de la licencia de Atribución Compartir-Igual de
Creative Commons.
Página | 2
Propósito de la Guía Scrum
Scrum es un marco para desarrollar, entregar y mantener productos complejos. Esta guía contiene la definición de
Scrum. Esta definición consiste en los roles, eventos, artefactos de Scrum y las reglas que los unen. Ken Schwaber
y Jeff Sutherland desarrollaron Scrum; la Guía Scrum está escrita y proporcionada por ellos. Juntos, se paran detrás
de la Guía Scrum.
Definición de Scrum
Scrum (n): un marco dentro del cual las personas pueden abordar problemas adaptativos complejos, al tiempo que ofrecen
productos productivos y creativos del mayor valor posible.
Scrum es:
• Ligero
• Simple de entender
• Difícil de dominar
Scrum es un marco de procesos que se ha utilizado para gestionar el trabajo en productos complejos desde principios de
los años noventa. Scrum no es un proceso, técnica o método definitivo. Más bien, es un marco dentro del cual puede
emplear diversos procesos y técnicas. Scrum deja en claro la eficacia relativa de la gestión de su producto y las técnicas de
trabajo para que pueda mejorar continuamente el producto, el equipo y el entorno de trabajo.
El marco Scrum consta de equipos Scrum y sus roles, eventos, artefactos y reglas asociados. Cada componente
dentro del marco cumple un propósito específico y es esencial para el éxito y uso de Scrum.
Las reglas de Scrum unen los roles, eventos y artefactos, gobernando las relaciones y la interacción entre ellos.
Las reglas de Scrum se describen en todo el cuerpo de este documento.
Las tácticas específicas para usar el marco Scrum varían y se describen en otra parte.
Creative Commons.
Página | 3
Usos de Scrum
Scrum se desarrolló inicialmente para gestionar y desarrollar productos. A principios de la década de 1990, Scrum se ha
utilizado ampliamente en todo el mundo para:
1) Investigar e identificar mercados, tecnologías y capacidades de productos viables;
2) Desarrollar productos y mejoras;

3) Lanzamiento de productos y mejoras, con la frecuencia de tantas veces por día;
4) Desarrollar y mantener Cloud (en línea, seguro, bajo demanda) y otros operativos
entornos para uso de productos; y,

5) Mantener y renovar productos.
Scrum se ha utilizado para desarrollar software, hardware, software embebido, redes de funciones interactivas, vehículos
autónomos, escuelas, gobierno, marketing, gestión del funcionamiento de las organizaciones y casi todo lo que usamos en
nuestra vida cotidiana, como individuos y sociedades.
A medida que la tecnología, el mercado y las complejidades ambientales y sus interacciones han aumentado rápidamente, la utilidad de
Scrum para lidiar con la complejidad se demuestra diariamente.
Scrum demostró ser especialmente efectivo en la transferencia de conocimiento iterativa e incremental. Scrum ahora se usa ampliamente
para productos, servicios y la administración de la organización matriz.
La esencia de Scrum es un pequeño equipo de personas. El equipo individual es altamente flexible y adaptable. Estas
fortalezas continúan operando en una sola, varias, muchas redes de equipos que desarrollan, lanzan, operan y mantienen el
trabajo y los productos de trabajo de miles de personas. Colaboran e interoperan a través de sofisticadas arquitecturas de
desarrollo y entornos de lanzamiento de destino.
Cuando las palabras "desarrollar" y "desarrollo" se utilizan en la Guía Scrum, se refieren a trabajos complejos, como los
tipos identificados anteriormente.
Teoría de Scrum
Scrum se basa en la teoría empírica de control de procesos o empirismo. El empirismo afirma que el conocimiento proviene
de la experiencia. y tomar decisiones basadas en lo que se sabe. Scrum emplea un enfoque iterativo e incremental para
optimizar la previsibilidad y controlar el riesgo.
Tres pilares sostienen cada implementación del control empírico del proceso: transparencia, inspección y
adaptación.
Creative Commons.
Página | 4 4
Transparencia
Los aspectos significativos del proceso deben ser visibles para los responsables del resultado. La transparencia requiere que esos
aspectos se definan mediante un estándar común para que los observadores compartan una comprensión común de lo que se está
viendo.
Por ejemplo
• Todos los participantes deben compartir un lenguaje común que se refiera al proceso; y,
• Los que realizan el trabajo y los que inspeccionan el incremento resultante deben compartir una definición común
de "Listo".
Inspección
Los usuarios de Scrum deben inspeccionar con frecuencia los artefactos de Scrum y avanzar hacia un Objetivo Sprint para detectar variaciones
indeseables. Su inspección no debe ser tan frecuente que la inspección se interponga en el trabajo. Las inspecciones son más beneficiosas
cuando son realizadas diligentemente por inspectores expertos en el punto de trabajo.
Adaptación
Si un inspector determina que uno o más aspectos de un proceso se desvían fuera de los límites aceptables, y
que el producto resultante será inaceptable, el proceso o el material que se procesa debe ajustarse. Se debe
hacer un ajuste lo antes posible para minimizar más desviaciones.
Scrum prescribe cuatro eventos formales para inspección y adaptación, como se describe en el Eventos Scrum sección de este
documento:
• Planificación de Sprint
• Scrum diario
• Revisión de Sprint
• Retrospectiva de Sprint
Valores Scrum
Cuando el equipo Scrum encarna y vive los valores de compromiso, coraje, enfoque, apertura y respeto, los pilares de
transparencia, inspección y adaptación de Scrum cobran vida y crean confianza para todos. Los miembros del Equipo Scrum
aprenden y exploran esos valores a medida que trabajan con los roles, eventos y artefactos de Scrum.
El uso exitoso de Scrum depende de que las personas se vuelvan más competentes para vivir estos cinco valores. Las personas se
comprometen personalmente a lograr los objetivos del Equipo Scrum. Los miembros del Equipo Scrum tienen el coraje de hacer lo
correcto y trabajar en problemas difíciles. Todos se centran en el trabajo del Sprint y los objetivos del Equipo Scrum. El Equipo Scrum y
sus partes interesadas acuerdan ser abiertos sobre todo el trabajo y los desafíos para realizar el trabajo. Los miembros del Equipo Scrum
se respetan mutuamente para ser personas capaces e independientes.
Creative Commons.
Página | 5 5
El equipo de Scrum
El equipo Scrum consta de un propietario del producto, el equipo de desarrollo y un Scrum Master. Equipos Scrum son autoorganizados
y multifuncionales. Los equipos autoorganizados eligen la mejor manera de realizar su trabajo, en lugar de ser dirigidos por otros fuera
del equipo. Los equipos interfuncionales tienen todas las competencias necesarias para realizar el trabajo sin depender de otros que no
forman parte del equipo. El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad. El
equipo Scrum ha demostrado ser cada vez más efectivo para todos los usos mencionados anteriormente y cualquier trabajo complejo.
Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de retroalimentación. Las
entregas incrementales del producto "Listo" aseguran que siempre esté disponible una versión potencialmente útil del producto en
funcionamiento.
El dueño del producto

El propietario del producto es responsable de maximizar el valor del producto resultante del trabajo del equipo de desarrollo. La forma en
que se hace esto puede variar ampliamente entre organizaciones, equipos de Scrum e individuos.
El propietario del producto es la única persona responsable de administrar la cartera de productos. La gestión de la cartera de
productos incluye:
• Expresar claramente los elementos de la cartera de productos;
• Ordenar los artículos en la Lista de Producto para lograr los mejores objetivos y misiones;
• Optimizar el valor del trabajo que realiza el Equipo de Desarrollo;

• Asegurarse de que el Backlog del Producto sea visible, transparente y claro para todos, y muestre en qué trabajará el Equipo
Scrum a continuación; y,
• Asegurarse de que el equipo de desarrollo comprende los elementos de la cartera de productos al nivel necesario.
El propietario del producto puede hacer el trabajo anterior o hacer que el equipo de desarrollo lo haga. Sin embargo, el propietario del producto
sigue siendo responsable.
El propietario del producto es una persona, no un comité. El propietario del producto puede representar los deseos de un comité en la cartera de
productos, pero aquellos que quieran cambiar la prioridad de un elemento de la cartera de productos deben dirigirse al propietario del producto.
Para que el propietario del producto tenga éxito, toda la organización debe respetar sus decisiones. Las decisiones del propietario del
producto son visibles en el contenido y el pedido de la cartera de pedidos del producto. Nadie puede obligar al equipo de desarrollo a trabajar
desde un conjunto diferente de requisitos.
Creative Commons.
Página | 6 6
El equipo de desarrollo
El Equipo de Desarrollo está formado por profesionales que realizan el trabajo de entregar un Incremento potencialmente
liberable del producto "Listo" al final de cada Sprint. Se requiere un incremento "Listo" en la Revisión de Sprint. Solo los
miembros del equipo de desarrollo crean el incremento.
Los equipos de desarrollo están estructurados y capacitados por la organización para organizar y administrar su
propio trabajo. La sinergia resultante optimiza la eficiencia y efectividad general del Equipo de Desarrollo.
Los equipos de desarrollo tienen las siguientes características:
• Son autoorganizados. Nadie (ni siquiera el Scrum Master) le dice al equipo de desarrollo cómo convertir la cartera de
productos en incrementos de funcionalidad potencialmente liberable;
• Los equipos de desarrollo son multifuncionales, con todas las habilidades como equipo necesarias para crear un incremento de producto;
• Scrum no reconoce títulos para los miembros del Equipo de Desarrollo, independientemente del trabajo que realiza la
persona;
• Scrum no reconoce sub-equipos en el Equipo de Desarrollo, independientemente de los dominios que deben abordarse,
como pruebas, arquitectura, operaciones o análisis de negocios; y,
• Los miembros del Equipo de Desarrollo Individual pueden tener habilidades especializadas y áreas de enfoque, pero la responsabilidad
pertenece al Equipo de Desarrollo en su conjunto.
Tamaño del equipo de desarrollo
El tamaño óptimo del equipo de desarrollo es lo suficientemente pequeño como para mantenerse ágil y lo suficientemente grande como para
completar un trabajo significativo dentro de un Sprint. Menos de tres miembros del Equipo de Desarrollo disminuyen la interacción y resultan en
ganancias de productividad más pequeñas. Los equipos de desarrollo más pequeños pueden encontrar limitaciones de habilidad durante el Sprint,
lo que hace que el equipo de desarrollo no pueda entregar un incremento potencialmente liberable. Tener más de nueve miembros requiere
demasiada coordinación. Los grandes equipos de desarrollo generan demasiada complejidad para que un proceso empírico sea útil. Las funciones
de Propietario del producto y Scrum Master no se incluyen en este recuento, a menos que también estén ejecutando el trabajo de Sprint Backlog.
The Scrum Master

El Scrum Master es responsable de promover y apoyar Scrum como se define en la Guía Scrum. Los Scrum Masters hacen esto
al ayudar a todos a comprender la teoría, las prácticas, las reglas y los valores de Scrum.
El Scrum Master es un líder de servicio para el Equipo Scrum. El Scrum Master ayuda a aquellos fuera del Equipo Scrum a
comprender cuáles de sus interacciones con el Equipo Scrum son útiles y cuáles no. El Scrum Master ayuda a todos a
cambiar estas interacciones para maximizar el valor creado por el Equipo Scrum.
Creative Commons.
Página | 7 7
Servicio Scrum Master para el propietario del producto
Scrum Master sirve al propietario del producto de varias maneras, que incluyen:
• Asegurarse de que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el Equipo Scrum lo mejor
posible;
• Encontrar técnicas para la gestión eficaz de la cartera de productos;
• Ayudar al equipo Scrum a comprender la necesidad de elementos claros y concisos de la cartera de productos;
• Comprender la planificación de productos en un entorno empírico;
• Asegurarse de que el propietario del producto sepa cómo organizar la cartera de productos para maximizar el valor;
• Comprender y practicar la agilidad; y,

• Facilitar eventos Scrum según lo solicitado o necesario.
Servicio Scrum Master para el equipo de desarrollo

Scrum Master sirve al equipo de desarrollo de varias maneras, que incluyen:
• Coaching del equipo de desarrollo en autoorganización y funcionalidad cruzada;
• Ayudar al equipo de desarrollo a crear productos de alto valor;

• Eliminar los impedimentos para el progreso del Equipo de Desarrollo;
• Facilitar eventos Scrum según lo solicitado o necesario; y,
• Coaching del equipo de desarrollo en entornos organizacionales en los que Scrum aún no se ha adoptado y entendido
completamente.
Servicio Scrum Master a la Organización

El Scrum Master sirve a la organización de varias maneras, que incluyen:
• Liderando y entrenando a la organización en su adopción de Scrum;
• Planificación de implementaciones de Scrum dentro de la organización;
• Ayudar a los empleados y partes interesadas a comprender y promulgar Scrum y el desarrollo empírico de productos;
• Causar cambios que aumenten la productividad del equipo Scrum; y,

• Trabajando con otros Scrum Masters para aumentar la efectividad de la aplicación de Scrum en la organización.
Creative Commons.
Página | 8
Eventos Scrum
Los eventos prescritos se usan en Scrum para crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum.
Todos los eventos son eventos de tiempo, de modo que cada evento tiene una duración máxima. Una vez que comienza un Sprint,
su duración es fija y no se puede acortar o alargar. Los eventos restantes pueden finalizar siempre que se logre el propósito del
evento, asegurando que se pase una cantidad de tiempo adecuada sin permitir desperdicio en el proceso.
Además del Sprint, que es un contenedor para todos los demás eventos, cada evento en Scrum es una oportunidad formal para
inspeccionar y adaptar algo. Estos eventos están diseñados específicamente para permitir la transparencia crítica y la inspección.
Si no se incluye ninguno de estos eventos, se reduce la transparencia y se pierde la oportunidad de inspeccionar y adaptarse.
El sprint
El corazón de Scrum es un Sprint, un lapso de tiempo de un mes o menos durante el cual se crea un Incremento de producto "Listo",
utilizable y potencialmente liberable. Los sprints tienen duraciones constantes a lo largo de un esfuerzo de desarrollo. Un nuevo Sprint
comienza inmediatamente después de la conclusión del Sprint anterior.
Los Sprints contienen y consisten en la Planificación de Sprint, Scrums diarios, el trabajo de desarrollo, la Revisión de Sprint y la
Retrospectiva de Sprint.
Durante el Sprint:
• No se realizan cambios que pongan en peligro el Objetivo Sprint;
• Los objetivos de calidad no disminuyen; y,
• El alcance puede aclararse y renegociarse entre el propietario del producto y el equipo de desarrollo a medida que se aprende
más.
Cada Sprint puede considerarse un proyecto con un horizonte no mayor a un mes. Al igual que los proyectos, los Sprints se usan
para lograr algo. Cada Sprint tiene una meta de lo que se va a construir, un diseño y un plan flexible que guiará la construcción, el
trabajo y el incremento del producto resultante.
Los sprints están limitados a un mes calendario. Cuando el horizonte de un Sprint es demasiado largo, la definición de lo que se está
construyendo puede cambiar, la complejidad puede aumentar y el riesgo puede aumentar. Los sprints permiten la previsibilidad al garantizar la
inspección y la adaptación del progreso hacia un Objetivo Sprint al menos cada mes calendario. Los sprints también limitan el riesgo a un mes
calendario de costo.
Creative Commons.
Página | 9 9
Cancelar un Sprint
Un Sprint puede cancelarse antes de que termine el tiempo de Sprint. Solo el propietario del producto tiene la autoridad
para cancelar el Sprint, aunque puede hacerlo bajo la influencia de las partes interesadas, el equipo de desarrollo o el
Scrum Master.
Un Sprint se cancelaría si el Objetivo Sprint se vuelve obsoleto. Esto puede ocurrir si la empresa cambia de dirección o si
cambian las condiciones del mercado o de la tecnología. En general, un Sprint debe cancelarse si ya no tiene sentido dadas
las circunstancias. Pero, debido a la corta duración de Sprints, la cancelación rara vez tiene sentido.
Cuando se cancela un Sprint, se revisan todos los elementos de la Lista de Producto finalizados y "Listo". Si parte del trabajo es potencialmente
liberable, el propietario del producto generalmente lo acepta. Todos los elementos incompletos de la cartera de productos se vuelven a estimar y se
vuelven a colocar en la cartera de productos. El trabajo realizado en ellos se deprecia rápidamente y debe reestimarse con frecuencia.
Las cancelaciones de Sprint consumen recursos, ya que todos se reagrupan en otro Sprint Planning para iniciar otro Sprint. Las
cancelaciones de sprint a menudo son traumáticas para el equipo Scrum y son muy poco frecuentes.
Planificación de Sprint
El trabajo a realizar en el Sprint se planifica en la Planificación del Sprint. Este plan es creado por el trabajo colaborativo
de todo el Equipo Scrum.
La planificación de Sprint tiene un límite de tiempo de hasta ocho horas para un Sprint de un mes. Para Sprints más cortos, el
evento suele ser más corto. El Scrum Master asegura que el evento se lleve a cabo y que los asistentes comprendan su propósito.
El Scrum Master le enseña al Equipo Scrum a mantenerlo dentro del tiempo.
Sprint Planning responde a lo siguiente:
• ¿Qué se puede entregar en el Incremento resultante del próximo Sprint?

• ¿Cómo se logrará el trabajo necesario para lograr el Incremento?
Tema uno: ¿Qué se puede hacer este Sprint?
El equipo de desarrollo trabaja para pronosticar la funcionalidad que se desarrollará durante el Sprint. El propietario del
producto discute el objetivo que el Sprint debe alcanzar y los elementos de la Lista de Producto que, si se completa en el
Sprint, alcanzarían el Objetivo Sprint. Todo el equipo Scrum colabora para comprender el trabajo del Sprint.
La aportación a esta reunión es la cartera de productos, el último incremento de producto, la capacidad proyectada del equipo de
desarrollo durante el Sprint y el desempeño pasado del equipo de desarrollo. El número de elementos seleccionados del
Backlog del Producto para Sprint depende únicamente del Equipo de Desarrollo. Solo el equipo de desarrollo puede evaluar lo
que puede lograr en el próximo Sprint.
Creative Commons.
Página | 10
Durante la planificación de Sprint, el equipo Scrum también crea un objetivo de Sprint. El objetivo de Sprint es un objetivo que se cumplirá
dentro del Sprint a través de la implementación de la cartera de productos, y proporciona orientación al equipo de desarrollo sobre por
qué está construyendo el incremento.
Tema dos: ¿Cómo se realizará el trabajo elegido?

Después de establecer el Objetivo de Sprint y seleccionar los elementos de la Lista de Producto para el Sprint, el Equipo de Desarrollo
decide cómo va a construir esta funcionalidad en un Incremento de producto "Listo" durante el Sprint. Los elementos del Backlog del
producto seleccionados para este Sprint más el plan para entregarlos se llama Sprint Backlog.
El equipo de desarrollo generalmente comienza diseñando el sistema y el trabajo necesario para convertir la cartera de productos en un
incremento de producto que funcione. El trabajo puede ser de diferente tamaño o esfuerzo estimado. Sin embargo, se planifica suficiente
trabajo durante la planificación de Sprint para que el equipo de desarrollo pronostique lo que cree que puede hacer en el próximo Sprint. El
trabajo planeado para los primeros días del Sprint por el Equipo de Desarrollo se descompone al final de esta reunión, a menudo en unidades
de un día o menos. El Equipo de Desarrollo se autoorganiza para emprender el trabajo en el Backlog de Sprint, tanto durante la Planificación
de Sprint como según sea necesario durante todo el Sprint.
El propietario del producto puede ayudar a aclarar los elementos seleccionados del Backlog del producto y hacer compensaciones. Si el Equipo de
desarrollo determina que tiene demasiado o muy poco trabajo, puede renegociar los elementos de la Pila de productos seleccionados con el
Propietario del producto. El equipo de desarrollo también puede invitar a otras personas a asistir para brindar asesoramiento técnico o de dominio.
Al final de la planificación de Sprint, el equipo de desarrollo debería poder explicarle al propietario del producto y al
Scrum Master cómo tiene la intención de trabajar como un equipo autoorganizado para lograr el objetivo de Sprint y crear
el incremento previsto.
Gol Sprint
El objetivo de Sprint es un conjunto de objetivos para el Sprint que se puede cumplir mediante la implementación de la cartera de productos.
Proporciona orientación al Equipo de Desarrollo sobre por qué está construyendo el Incremento. Se crea durante la reunión de planificación
de Sprint. El Objetivo Sprint le da al Equipo de Desarrollo cierta flexibilidad con respecto a la funcionalidad implementada dentro del Sprint.
Los elementos seleccionados del Backlog del producto ofrecen una función coherente, que puede ser el objetivo de Sprint. El objetivo de
Sprint puede ser cualquier otra coherencia que haga que el equipo de desarrollo trabaje en conjunto en lugar de iniciativas separadas.
A medida que el Equipo de Desarrollo trabaja, tiene en mente el Objetivo Sprint. Para satisfacer el objetivo de Sprint,
implementa funcionalidad y tecnología. Si el trabajo resulta ser diferente al esperado por el Equipo de Desarrollo, colaborarán
con el Propietario del Producto para negociar el alcance de la Reserva de Sprint dentro de Sprint.
Creative Commons.
Página | 11
Scrum diario
El Daily Scrum es un evento de 15 minutos para el equipo de desarrollo. El Daily Scrum se lleva a cabo todos los días del Sprint. En
él, el Equipo de Desarrollo planea trabajar para las próximas 24 horas. Esto optimiza la colaboración y el rendimiento del equipo al
inspeccionar el trabajo desde el último Daily Scrum y pronosticar el próximo trabajo de Sprint. El Daily Scrum se lleva a cabo a la
misma hora y lugar cada día para reducir la complejidad.
El Equipo de Desarrollo usa el Scrum diario para inspeccionar el progreso hacia la Meta de Sprint y para inspeccionar la
tendencia del progreso hacia completar el trabajo en el Backlog de Sprint. El Daily Scrum optimiza la probabilidad de que el
Equipo de Desarrollo cumpla con el Objetivo Sprint. Todos los días, el Equipo de Desarrollo debe comprender cómo tiene la
intención de trabajar juntos como un equipo de autoorganización para lograr el Objetivo Sprint y crear el Incremento anticipado
al final del Sprint.
La estructura de la reunión es establecida por el Equipo de Desarrollo y puede llevarse a cabo de diferentes maneras si se enfoca en
el progreso hacia la Meta Sprint. Algunos equipos de desarrollo usarán preguntas, algunos estarán más basados en la discusión.
Aquí hay un ejemplo de lo que podría usarse:
• ¿Qué hice ayer que ayudó al Equipo de Desarrollo a alcanzar el Objetivo Sprint?
• ¿Qué haré hoy para ayudar al Equipo de Desarrollo a alcanzar el Objetivo Sprint?
• ¿Veo algún impedimento que me impida a mí o al Equipo de Desarrollo alcanzar el Objetivo Sprint?
El Equipo de Desarrollo o los miembros del equipo a menudo se reúnen inmediatamente después del Daily Scrum para discusiones
detalladas, o para adaptar o volver a planificar el resto del trabajo del Sprint.
El Scrum Master asegura que el Equipo de Desarrollo tenga la reunión, pero el Equipo de Desarrollo es responsable de
llevar a cabo el Daily Scrum. El Scrum Master le enseña al Equipo de Desarrollo a mantener el Daily Scrum dentro del
plazo de 15 minutos.
Daily Scrum es una reunión interna para el equipo de desarrollo. Si hay otros presentes, el Scrum Master se
asegura de que no interrumpan la reunión.
Los Scrums diarios mejoran las comunicaciones, eliminan otras reuniones, identifican impedimentos para el desarrollo para su
eliminación, resaltan y promueven la toma de decisiones rápidas y mejoran el nivel de conocimiento del Equipo de Desarrollo. Esta
es una reunión clave de inspección y adaptación.
Creative Commons.
Página | 12
Revisión de Sprint
Se realiza una Revisión de Sprint al final del Sprint para inspeccionar el Incremento y adaptar la Cartera de Producto si es necesario.
Durante la Revisión de Sprint, el Equipo Scrum y las partes interesadas colaboran sobre lo que se hizo en Sprint. En base a eso y a
cualquier cambio en el Backlog del Producto durante el Sprint, los asistentes colaboran en las siguientes cosas que podrían hacerse
para optimizar el valor. Esta es una reunión informal, no una reunión de estado, y la presentación del Incremento está destinada a
generar comentarios y fomentar la colaboración.
Esto es como máximo una reunión de cuatro horas para Sprints de un mes. Para Sprints más cortos, el evento suele ser más corto. El
Scrum Master asegura que el evento se lleve a cabo y que los asistentes comprendan su propósito. El Scrum Master enseña a todos los
involucrados a mantenerlo dentro del timebox.
La Revisión de Sprint incluye los siguientes elementos:
• Los asistentes incluyen el equipo Scrum y las partes interesadas clave invitadas por el propietario del producto;
• El propietario del producto explica qué elementos del Backlog del producto se han "hecho" y qué no se ha "hecho";
• El Equipo de Desarrollo discute qué salió bien durante el Sprint, qué problemas encontró y cómo se
resolvieron esos problemas;
• El Equipo de Desarrollo demuestra el trabajo que ha "Hecho" y responde preguntas sobre el Incremento;
• El propietario del producto discute la acumulación de productos tal como está. Él o ella proyectan fechas de entrega y objetivo
probables basadas en el progreso hasta la fecha (si es necesario);
• Todo el grupo colabora en qué hacer a continuación, para que la Revisión de Sprint proporcione información valiosa para la
Planificación de Sprint posterior;
• Revisión de cómo el mercado o el uso potencial del producto podrían haber cambiado lo que es lo más valioso a
hacer a continuación; y,
• Revisión de la línea de tiempo, el presupuesto, las capacidades potenciales y el mercado para los próximos lanzamientos
anticipados de funcionalidad o capacidad del producto.
El resultado de la Revisión de Sprint es una Revisión del Producto Backlog que define los elementos probables del Producto Backlog para el
próximo Sprint. La cartera de productos también se puede ajustar en general para satisfacer nuevas oportunidades.
Creative Commons.
Página | 13
Retrospectiva de Sprint
La Retrospectiva de Sprint es una oportunidad para que el Equipo Scrum se inspeccione a sí mismo y cree un plan de mejoras que se
implementarán durante el próximo Sprint.
La Retrospectiva de Sprint ocurre después de la Revisión de Sprint y antes de la próxima Planificación de Sprint. Esto es como
máximo una reunión de tres horas para Sprints de un mes. Para Sprints más cortos, el evento suele ser más corto. El Scrum Master
asegura que el evento se lleve a cabo y que los asistentes comprendan su propósito.
El Scrum Master asegura que la reunión sea positiva y productiva. El Scrum Master enseña todo para
mantenerlo dentro del tiempo. El Scrum Master participa como miembro del equipo en la reunión desde la
responsabilidad sobre el proceso Scrum.
El propósito de la Retrospectiva de Sprint es:
• Inspeccione cómo fue el último Sprint con respecto a las personas, las relaciones, el proceso y las herramientas;
• Identifique y ordene los elementos principales que salieron bien y las posibles mejoras; y,
• Cree un plan para implementar mejoras en la forma en que el Equipo Scrum hace su trabajo.
El Scrum Master alienta al Equipo Scrum a mejorar, dentro del marco del proceso Scrum, su proceso de desarrollo y sus prácticas
para hacerlo más efectivo y agradable para el próximo Sprint. Durante cada Retrospectiva de Sprint, el Equipo Scrum planifica
formas de aumentar la calidad del producto mejorando los procesos de trabajo o adaptando la definición de "Listo", si es
apropiado y no está en conflicto con los estándares del producto u organización.
Al final de la Retrospectiva de Sprint, el Equipo Scrum debería haber identificado mejoras que implementará en el próximo
Sprint. La implementación de estas mejoras en el próximo Sprint es la adaptación a la inspección del propio Equipo Scrum.
Aunque las mejoras se pueden implementar en cualquier momento, la Retrospectiva de Sprint brinda una oportunidad formal
para enfocarse en la inspección y la adaptación.
Artefactos Scrum
Los artefactos de Scrum representan trabajo o valor para proporcionar transparencia y oportunidades de 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 para que todos
tengan la misma comprensión del artefacto.
Creative Commons.
Página | 14
Pila de Producto
La cartera de productos es una lista ordenada de todo lo que se sabe que se necesita en el producto. Es la única fuente de
requisitos para cualquier cambio que se realice en el producto. El propietario del producto es responsable de la acumulación de
productos, incluido su contenido, disponibilidad y pedidos.
Una cartera de productos nunca se completa. El primer desarrollo del mismo establece los requisitos inicialmente conocidos y mejor
entendidos. La cartera de productos evoluciona a medida que evoluciona el producto y el entorno en el que se utilizará. La cartera de
productos es dinámica; cambia constantemente para identificar lo que el producto necesita para ser apropiado, competitivo y útil. Si
existe un producto, también existe su Backlog del producto.
El Backlog del producto enumera todas las características, funciones, requisitos, mejoras y correcciones que constituyen los cambios que se
realizarán en el producto en futuras versiones. Los elementos de la Lista de Producto tienen los atributos de una descripción, orden, estimación y
valor. Los elementos de la Cartera de productos a menudo incluyen descripciones de prueba que demostrarán su integridad cuando esté "Hecho".
A medida que se utiliza un producto y gana valor, y el mercado proporciona comentarios, la cartera de productos se convierte en una lista
más amplia y exhaustiva. Los requisitos nunca dejan de cambiar, por lo que un Producto acumulado es un artefacto vivo. Los cambios en
los requisitos comerciales, las condiciones del mercado o la tecnología pueden causar cambios en la cartera de productos.
Varios equipos Scrum a menudo trabajan juntos en el mismo producto. El Backlog de un producto se utiliza para describir el próximo
trabajo en el producto. A continuación, se puede emplear un atributo de Producto atrasado que agrupa elementos.
El refinamiento de la cartera de productos es el acto de agregar detalles, estimaciones y pedidos a los elementos de la cartera de productos.
Este es un proceso continuo en el que el propietario del producto y el equipo de desarrollo colaboran en los detalles de los elementos de la
cartera de productos. Durante el refinamiento de la cartera de productos, los artículos se revisan y modifican. El Equipo Scrum decide cómo y
cuándo se realiza el refinamiento. El refinamiento generalmente no consume más del 10% de la capacidad del Equipo de Desarrollo. Sin
embargo, los elementos de la Lista de Producto pueden ser actualizados en cualquier momento por el Propietario del Producto o a discreción del
Propietario del Producto.
Los elementos de la cartera de productos de orden superior suelen ser más claros y detallados que los de orden inferior. Se realizan
estimaciones más precisas basadas en la mayor claridad y el mayor detalle; cuanto menor es el orden, menos detalles. Los elementos de la
Lista de Producto que ocuparán el Equipo de Desarrollo para el próximo Sprint se refinan para que cualquier elemento pueda ser "Hecho"
razonablemente dentro del plazo de Sprint. Los elementos de la cartera de productos que el equipo de desarrollo puede "hacer" en un Sprint se
consideran "listos" para su selección en una planificación de Sprint. Los elementos de la cartera de productos suelen adquirir este grado de
transparencia a través de las actividades de refinación descritas anteriormente.
El equipo de desarrollo es responsable de todas las estimaciones. El propietario del producto puede influir en el equipo de desarrollo al
ayudarlo a comprender y seleccionar compensaciones, pero las personas que realizarán el trabajo hacen la estimación final.
Creative Commons.
Página | 15
Monitorear el progreso hacia las metas
En cualquier momento, se puede sumar el trabajo total restante para alcanzar una meta. El propietario del producto rastrea este trabajo
total restante al menos en cada revisión de Sprint. El propietario del producto compara esta cantidad con el trabajo restante en las
revisiones previas de Sprint para evaluar el progreso hacia la finalización del trabajo proyectado en el momento deseado para el objetivo.
Esta información se hace transparente para todos los interesados.
Se han utilizado diversas prácticas proyectivas sobre tendencias para pronosticar el progreso, como quemaduras, quemaduras o
flujos acumulativos. Estos han demostrado ser útiles. Sin embargo, estos no reemplazan la importancia del empirismo. En
entornos complejos, lo que sucederá es desconocido. Solo lo que ya sucedió puede usarse para tomar decisiones con visión de
futuro.
Backlog de Sprint
El Backlog de Sprint es el conjunto de elementos de la Lista de Producto seleccionada para el Sprint, más un plan para entregar el
Incremento del producto y alcanzar el Objetivo Sprint. El Backlog de Sprint es un pronóstico del Equipo de Desarrollo sobre qué
funcionalidad estará en el próximo Incremento y el trabajo necesario para entregar esa funcionalidad en un Incremento "Listo".
El Backlog de Sprint hace visible todo el trabajo que el Equipo de Desarrollo identifica como necesario para cumplir con el
Objetivo de Sprint. Para garantizar la mejora continua, incluye al menos una mejora del proceso de alta prioridad identificada en
la reunión retrospectiva anterior.
El Backlog de Sprint es un plan con suficiente detalle para que los cambios en progreso se puedan entender en el Daily Scrum.
El equipo de desarrollo modifica el Backlog de Sprint en todo el Sprint, y el Backlog de Sprint emerge durante el Sprint. Este
surgimiento ocurre cuando el Equipo de Desarrollo trabaja a través del plan y aprende más sobre el trabajo necesario para
lograr el Objetivo Sprint.
Como se requiere un nuevo trabajo, el equipo de desarrollo lo agrega a la reserva de Sprint. A medida que se realiza o se
completa el trabajo, se actualiza el trabajo restante estimado. Cuando los elementos del plan se consideran innecesarios, se
eliminan. Solo el Equipo de Desarrollo puede cambiar su Backlog de Sprint durante un Sprint. El Backlog de Sprint es una imagen
muy visible en tiempo real del trabajo que el Equipo de Desarrollo planea realizar durante el Sprint, y pertenece únicamente al
Equipo de Desarrollo.
Creative Commons.
Página | dieciséis
Monitoreo del progreso de Sprint
En cualquier momento en un Sprint, se puede sumar el trabajo total restante en el Backlog de Sprint. El equipo de desarrollo realiza un
seguimiento de este trabajo total restante al menos para cada Scrum diario para proyectar la probabilidad de lograr el objetivo de
Sprint. Al rastrear el trabajo restante a lo largo del Sprint, el Equipo de Desarrollo puede administrar su progreso.
Incremento
El Incremento es la suma de todos los elementos de la Pila del Producto 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 "Listo", lo que significa que debe estar en
condiciones utilizables y cumplir con la definición del Equipo Scrum de "Listo". Un incremento es un cuerpo de trabajo inspeccionable
realizado que respalda el empirismo al final del Sprint. El incremento es un paso hacia una visión u objetivo. El incremento debe estar
en condiciones de uso, independientemente de si el propietario del producto decide liberarlo.
Transparencia de artefactos
Scrum se basa en la transparencia. Las decisiones para optimizar el valor y controlar el riesgo se toman en función del estado percibido de los
artefactos. En la medida en que la transparencia sea completa, estas decisiones tienen una base sólida. En la medida en que los artefactos sean
completamente transparentes, estas decisiones pueden ser defectuosas, el valor puede disminuir y el riesgo puede aumentar.
El Scrum Master debe trabajar con el propietario del producto, el equipo de desarrollo y otras partes involucradas para
comprender si los artefactos son completamente transparentes. Existen prácticas para hacer frente a una transparencia
incompleta; Scrum Master debe ayudar a todos a aplicar las prácticas más apropiadas en ausencia de una transparencia total. Un
Scrum Master puede detectar una transparencia incompleta al inspeccionar los artefactos, detectar patrones, escuchar
atentamente lo que se dice y detectar diferencias entre los resultados esperados y reales.
El trabajo del Scrum Master es trabajar con el Equipo Scrum y la organización para aumentar la transparencia de los artefactos. Este
trabajo generalmente implica aprender, convencer y cambiar. La transparencia no ocurre de la noche a la mañana, sino que es un
camino.
Creative Commons.
Página | 17
Definición de "Hecho"
Cuando un elemento del Producto acumulado o un Incremento se describe como " Listo ", todos deben entender qué" Listo " medio. Aunque
esto puede variar significativamente según el Equipo Scrum, los miembros deben tener una comprensión compartida de lo que significa que el
trabajo sea completo, para garantizar la transparencia. Esta es la definición de "Hecho" para el Equipo Scrum y se utiliza para evaluar cuándo
se completa el trabajo en el Incremento del producto.
La misma definición guía al equipo de desarrollo para saber cuántos elementos de la cartera de productos puede seleccionar durante una
planificación de Sprint. El propósito de cada Sprint es ofrecer incrementos de funcionalidades potencialmente liberables que se adhieran
a la definición actual del equipo Scrum de "Listo".
Los equipos de desarrollo ofrecen un incremento de la funcionalidad del producto cada Sprint. Este incremento es utilizable, por lo que el
propietario del producto puede optar por liberarlo de inmediato. Si la definición de "Hecho" para un incremento es Como parte de las
convenciones, estándares o pautas de la organización de desarrollo, todos los equipos Scrum deben seguirlo como mínimo.
Si "Listo" para un incremento es no una convención de la organización de desarrollo, el Equipo de Desarrollo del Equipo
Scrum debe definir una definición de "Hecho" apropiada para el producto. Si hay varios equipos Scrum trabajando en el
lanzamiento del sistema o producto, los equipos de desarrollo de todos los equipos Scrum deben definir mutuamente la
definición de "Listo".
Cada Incremento es aditivo a todos los Incrementos anteriores y se prueba exhaustivamente, asegurando que todos los Incrementos
trabajen juntos.
A medida que los Equipos Scrum maduren, se espera que sus definiciones de "Hecho" se expandan para incluir criterios más estrictos para una
mayor calidad. Las nuevas definiciones, tal como se usan, pueden descubrir el trabajo que se realizará en incrementos previamente
"terminados". Cualquier producto o sistema debe tener una definición de "Hecho" que es un estándar para cualquier trabajo realizado en él.
Creative Commons.
Página | 18 años
Nota final
Scrum es gratis y se ofrece en esta Guía. Los roles, eventos, artefactos y reglas de Scrum son inmutables y, aunque es
posible implementar solo partes de Scrum, el resultado no es Scrum. Scrum existe solo en su totalidad y funciona bien como
un contenedor para otras técnicas, metodologías y prácticas.
Agradecimientos
Personas
De las miles de personas que han contribuido a Scrum, debemos destacar a aquellos que fueron fundamentales
al principio: Jeff Sutherland trabajó con Jeff McKenna y John Scumniotales, y Ken Schwaber trabajó con Mike
Smith y Chris Martin, y todos trabajaron juntos . Muchos otros contribuyeron en los años siguientes y sin su
ayuda Scrum no sería refinada como lo es hoy.
Historia
Ken Schwaber y Jeff Sutherland trabajaron en Scrum hasta 1995, cuando presentaron en forma conjunta Scrum en la
Conferencia de OOPSLA en 1995. Esta presentación esencialmente documentó el aprendizaje que Ken y Jeff obtuvieron en los
últimos años, e hizo pública la primera definición formal de Scrum .
La historia de Scrum se describe en otra parte. Para honrar los primeros lugares donde fue probado y refinado,
reconocemos a Individual, Inc., Newspage, Fidelity Investments e IDX (ahora GE Medical).
La Guía Scrum documenta Scrum tal como fue desarrollado, evolucionado y sostenido durante más de 20 años por Jeff
Sutherland y Ken Schwaber. Otras fuentes le proporcionan patrones, procesos e ideas que complementan el marco de Scrum.
Estos pueden aumentar la productividad, el valor, la creatividad y la satisfacción con los resultados.
Creative Commons.
Página | 19

2017 Scrum Guide US - En.es

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

2017 Scrum Guide US - En.es

Caricato da

Copyright:

Formati disponibili

La guía Scrum ™

La guía definitiva para Scrum:

Definición de Scrum ............................................... .................................................. ......................... 3

Usos de Scrum ............................................... .................................................. .................................. 4

Teoría de Scrum ................................................ .................................................. ................................. 4

Valores Scrum ................................................ .................................................. .................................. 5

El equipo Scrum ............................................... .................................................. .............................. 6

El propietario del producto ............................................... .................................................. ..................... 6

El equipo de desarrollo ............................................... .................................................. .............. 7

El Scrum Master ............................................... .................................................. ....................... 7

Scrum Events ................................................ .................................................. .................................. 9

El Sprint ................................................ .................................................. ................................... 9

Planificación de Sprint ................................................ .................................................. ......................... 10

Scrum diario ................................................ .................................................. ............................... 12

Revisión de Sprint ................................................ .................................................. ........................... 13

Retrospectiva de Sprint ................................................ .................................................. ................. 14

Scrum Artifacts ................................................ .................................................. ............................. 14

Pila de Producto ................................................ .................................................. ........................ 15

Sprint Backlog ................................................ .................................................. ........................... dieciséis

Incremento ................................................. .................................................. ................................ 17

Transparencia de artefactos ................................................ .................................................. ................... 17

Definición de "Hecho" ............................................. .................................................. .................... 18

Nota final ................................................ .................................................. ....................................... 19

Agradecimientos ................................................. .................................................. ..................... 19

Personas ................................................. .................................................. ...................................... 19

Historia ................................................. .................................................. ..................................... 19

productos productivos y creativos del mayor valor posible.

utilizado ampliamente en todo el mundo para:

1) Investigar e identificar mercados, tecnologías y capacidades de productos viables;

2) Desarrollar productos y mejoras;

entornos para uso de productos; y,

nuestra vida cotidiana, como individuos y sociedades.

Scrum para lidiar con la complejidad se demuestra diariamente.

para productos, servicios y la administración de la organización matriz.

desarrollo y entornos de lanzamiento de destino.

tipos identificados anteriormente.

optimizar la previsibilidad y controlar el riesgo.

cuando son realizadas diligentemente por inspectores expertos en el punto de trabajo.

se respetan mutuamente para ser personas capaces e independientes.

El dueño del producto

• Expresar claramente los elementos de la cartera de productos;

• Optimizar el valor del trabajo que realiza el Equipo de Desarrollo;

sigue siendo responsable.

desde un conjunto diferente de requisitos.

miembros del equipo de desarrollo crean el incremento.

Los equipos de desarrollo tienen las siguientes características:

productos en incrementos de funcionalidad potencialmente liberable;

como pruebas, arquitectura, operaciones o análisis de negocios; y,

pertenece al Equipo de Desarrollo en su conjunto.

Tamaño del equipo de desarrollo

The Scrum Master

• Encontrar técnicas para la gestión eficaz de la cartera de productos;

• Comprender la planificación de productos en un entorno empírico;

• Comprender y practicar la agilidad; y,

Servicio Scrum Master para el equipo de desarrollo

• Coaching del equipo de desarrollo en autoorganización y funcionalidad cruzada;

• Ayudar al equipo de desarrollo a crear productos de alto valor;

• Facilitar eventos Scrum según lo solicitado o necesario; y,

Servicio Scrum Master a la Organización

• Liderando y entrenando a la organización en su adopción de Scrum;

• Planificación de implementaciones de Scrum dentro de la organización;

• Causar cambios que aumenten la productividad del equipo Scrum; y,

comienza inmediatamente después de la conclusión del Sprint anterior.