Fundacin Telefnica Colombia 1 Fundacin Telefnica Colombia 2
Fundación Telefónica Colombia 1
Fundación Telefónica Colombia 2
Diplomado Servicio técnico comercial + 3
Scrum Gonzalo Andrés Lucio + 4
Tabla de contenido 1. Scrum y su origen 2. ¿Por que utilizar Scrum? 3. Modelo Scrum 4. Scrum y su organización 5. Metodología ágil 6. Etapas esperadas en un proyecto 7. Scrum Team – Scrum core roles 8. Product - Owner 9. Scrum Master 10. Development Team 11. Interrelación entre roles 12. Conceptos claves SCRUM + 13. Definición del DONE 5
Tabla de contenido 14. Reuniones o ceremonias de SCRUM a. Sprint b. Tipos de sprint c. Cancelación de un Sprint 15. ¿Qué puede ser terminado? 16. Artefactos a. Product Backlog b. Sprint Backlog c. Burn-Down Chart (Product, Sprint) d. Incremento del producto 17. Método Kanban + 6
Objetivo Promover procesos de reflexión y aprendizaje que permitan identificar la metodología ágil de Proyectos de Innovación SCRUM para implementar en proyectos donde se utilizan las metodologías clásicas, permitiendo: El entendimiento de que los roles y responsabilidades definidos en un proyecto de Scrum es muy importante para asegurar la exitosa implementación de Scrum. El conocimiento de los sprints para involucrarlos en el ciclo de vida de los proyectos. La diferenciación de los roles que se presentan en ciclo de vida del proyecto SCRUM. + 7
1. SCRUM y su Origen A mediados de la década de los 80 s, Hirotaka Takeuchi y Ikujiro Nonaka definieron una estrategia de desarrollo de producto flexible e incluyente donde el equipo de desarrollo trabaja en unidad para alcanzar un objetivo común. Describieron un método innovador para el desarrollo de productos al que llamaron enfoque holístico o “rugby”, “donde un equipo intenta llegar hasta el final como una unidad, pasando el balón hacia atrás y adelante”. + 8
1. SCRUM y su Origen Basaron su enfoque en los estudios de casos de diversas industrias de fabricación. Takeuchi y Nonaka propusieron que el desarrollo de productos no debe ser como una carrera de relevos secuencial, sino que debería ser análogo al del juego de rugby, donde el equipo trabaja en conjunto, pasando el balón hacia atrás y hacia adelante a medida que se desplaza en unidad por el campo. + 9
1. SCRUM y su Origen El concepto de rugby de un “Scrum” (donde un grupo de jugadores se junta para reiniciar el juego) se introdujo en este artículo para describir la propuesta de los autores de que el desarrollo de productos debe implicar “mover al Scrum campo abajo”. El framework de Scrum, tal como se define en la Guía SBOK™, está estructurado de tal manera que es compatible con el desarrollo de productos y servicios en todo tipo de industrias y en cualquier tipo de proyecto, independientemente de su complejidad. + 10
1. SCRUM y su Origen Una fortaleza clave de Scrum radica en el uso de equipos interfuncionales (cross-functional), autoorganizados y empoderados que dividen su trabajo en ciclos de trabajo cortos y concentrados llamados Sprints. La figura 01 proporciona una visión general de flujo de un proyecto Scrum. + Fuente. 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 11
1. SCRUM y su Origen El ciclo de Scrum empieza con una reunión de stakeholders, durante la cual se crea la visión del proyecto. Después, el Product Owner desarrolla una Backlog Priorizado del Producto (Prioritized Product Backlog) que contiene una lista requerimientos del negocio y del proyecto por orden de importancia en forma de una historia de usuario. Cada sprint empieza con una reunión de planificación del sprint (Sprint Planning Meeting) durante la cual se consideran las historias de usuario de alta prioridad para su inclusión en el sprint. Un sprint generalmente tiene una duración de una a seis semanas durante las cuales el Equipo + 13
1. SCRUM y su Origen Scrum trabaja en la creación de entregables (del inglés deliverables) en incrementos del producto. Durante el sprint, se llevan cabo Daily Standups muy breves y concretos, donde los miembros del equipo discuten el progreso diario. Haca el final del sprint, se lleva a cabo una Reunión de Revisión del Sprint (Sprint Review Meeting) en la cual se proporciona una demostración de los entregables al Product Owner y a los stakeholders relevantes. + 14
1. SCRUM y su Origen El Product Owner acepta los entregables sólo si cumplen con los criterios de aceptación predefinidos. El ciclo del sprint termina con una Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting), donde el equipo analiza las formas de mejorar los procesos y el rendimiento a medida que avanzan al siguiente sprint. + 15
2. ¿Por qué utilizar Scrum? Adaptabilidad: El control del proceso empírico y el desarrollo iterativo hacen que los proyectos sean adaptables y abiertos a la incorporación del cambio. Transparencia: Todos los radiadores de información tales como un Scrumboard y el Sprint Burndown Chart se comparten, lo cual conduce a un ambiente de trabajo abierto. Retroalimentación continua: La retroalimentación continua se proporciona a través de los procesos de Realizar Daily Standup y Demostrar y validar el sprint. Mejora continua: Los entregables se mejoran progresivamente sprint por sprint a través del proceso de Refinar el Backlog Priorizado del Producto. + 17
2. ¿Por qué utilizar Scrum? Entrega continúa de valor: Los procesos iterativos permiten la entrega continua de valor tan frecuentemente como el cliente lo requiere a través del proceso de Envío de entregables. Ritmo sostenible: Los procesos Scrum están diseñados de tal manera que las personas involucradas pueden trabajar a un ritmo sostenible que, en teoría, puede continuar indefinidamente. Entrega anticipada de alto valor: El proceso de Crear el Backlog Priorizado del Producto asegura que los requisitos de mayor valor del cliente sean los primeros en cumplirse. Proceso de desarrollo eficiente: El Time-boxing y la reducción al mínimo del trabajo que no es esencial conducen a mayores niveles de eficiencia. + 18
2. ¿Por qué utilizar Scrum? Motivación: Los procesos de Realizar Daily Standup y Retrospectiva del sprint conducen a mayores niveles de motivación entre los empleados. Resolución de problemas de forma más rápida: La colaboración y coubicación de equipos interfuncionales conducen a la resolución de problemas con mayor rapidez. Entregables efectivos: El proceso de Crear el Backlog Priorizado del Producto, y las revisiones periódicas después de la creación de entregables aseguran entregas eficientes al cliente. Centrado en el cliente: El poner énfasis en el valor del negocio y tener un enfoque de colaboración con los stakeholders asegura un framework orientado al cliente. + 20
2. ¿Por qué utilizar Scrum? Ambiente de alta confianza: Los procesos de Realizar Daily Standup y la Retrospectiva del Sprint promueven la transparencia y colaboración, dando lugar a un ambiente de trabajo de alta confianza que garantiza una baja fricción entre los empleados. Responsabilidad colectiva: El proceso de Comprometer Historias de Usuarios permite que los miembros del equipo hagan suyo el proyecto y su trabajo lleve a una mejor calidad. Alta velocidad: Un framework de colaboración permite a los equipos interfuncionales altamente cualificados alcanzar su potencial y una alta velocidad. Ambiente innovador: Los procesos de Retrospectiva de Sprint y Retrospectiva del Proyecto crean un ambiente de introspección, aprendizaje y capacidad de adaptación que conllevan a un ambiente de trabajo innovador y creativo. + 21
3. Modelo Scrum + Fuente. Elaboración propia 23
4. Scrum y su organización + Fuente. 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 24
5. Metodología ágil Los procesos ágiles evitan los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados. + Fuente. Elaboración propia, tomada de, http: //agilemanifesto. org/iso/es/manifesto. html 26
5. Metodología ágil A los individuos y su interacción, por encima de los procesos y las herramientas. El software que funciona, por encima de la documentación detallada. La colaboración con el cliente, por encima de la negociación contractual. La respuesta al cambio, por encima del seguimiento de un plan. Aunque hay valor en los elementos de la derecha, se valoran más los de la izquierda. + SCRUM Fuente. Elaboración propia, tomada de, http: //agilemanifesto. org/iso/es/manifesto. html 27
6. Etapas esperadas en un proyecto Scrum es aplicable para proyectos de cualquier magnitud, en caso de que el equipo sea mayor a diez miembros pueden crearse varios equipos para trabajar en el proyecto. Debe prevalecer la sincronización entre los equipos, de lo que se hace cargo el proceso de Convocación de Scrums. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 29
7. Scrum Team – Scrum Core Roles 1 Product Owner 2 Scrum Master Development. Team + 3 30
8. Product– Owner + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 32
8. Product– Owner + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 33
8. Product– Owner + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 34
9. Scrum – Master + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 36
9. Scrum – Master + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 37
9. Scrum – Master + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 38
9. Scrum – Master + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 39
10. Development– Team + 41
10. Development– Team 1 Auto-gestionado Utiliza ciclos rápidos de desarrollo Sprints 5 Empoderado + Fuente. Elaboración propia. 2 4 Auto-organizado 3 Multifuncional 42
Development – Team (Auto-gestionado) Administración autónoma, uso de metodo, habilidad y estrategia a través de las cuales los integrantes del equipo pueden guiar el logro de sus objetivos con autonomía en el manejo de los recursos. + ept onc b. C e W e erc mm o C e hy rap tog o h P g sin erti Adv Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 43
Development – Team (Auto-organizado) Los equipos auto-organizados eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 45
Development – Team (Multifuncional) 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. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 46
Development – Team (Empoderado) Proceso para dotar al grupo de herramientas para aumentar su fortaleza, mejorar sus capacidades y acrecentar su potencial, todo esto con el objetivo de que pueda mejorar su actualidad. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 47
Development – Team (Utiliza ciclos rápidos de desarrollo] Este es el corazón de la agilidad, el bloque de tiempo (time-box) de un mes o menos durante el cual se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 48
Development – Team + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 50
Development – Team + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 51
Development – Team + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 52
11. Interrelación entre – Roles + La interrelación entre roles desde el cliente quien proporciona los requerimientos de una manera formal, por medio de una herramienta, al Product Owner, quien es la voz del cliente, transmite los requerimientos del negocio, los prioriza creando el product backlog y los criterios de aceptación. El Scrum Master asegura un entorno de trabajo adecuado para el equipo de desarrollo y finalmente el equipo de desarrollo crea los entregables del proyecto. Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 54
12. Conceptos claves – en Scrum Épicas. Es una historia de usuario que es demasiado grande para caber en un sprint, a menudo, este término se utiliza para describir una gran historia de usuario que tendrá que ser dividido en historias más 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. Tareas. Es una representación del requisito que está en lenguaje del usuario, pero de una forma técnica donde está definido como se va a trabajar y quien van a participar. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 55
13. Definición del– DONE Son los acuerdos del PO con los Stakeholders que contiene todas las condiciones que deben de cumplir los ítems del Product Backlog para considerar un Sprint completado o Finalizado. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 57
13. Definición del– DONE El ciclo de vida, basado en una entrega de valor, en un proyecto Scrum es un emprendimiento colaborativo para crear nuevos productos o servicios, o para obtener resultados como los que se definen en la declaración de la visión del proyecto (Project Vision Statement). + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 58
13. Definición del– DONE Los proyectos por lo general se ven afectados por limitaciones de tiempo, costo, alcance, calidad, personal y la capacidad de la organización. Por lo general, se busca que los resultados que generen los proyectos resulten en algún tipo de valor de negocio o servicio. a que el valor es una razón principal de cualquier organización para seguir adelante con un proyecto, la entrega basada en valor (del inglés: Value-Driven Delivery) debe ser el principal enfoque. El ofrecer valor es algo que está arraigado en el framework de Scrum. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 59
13. Definición del– DONE Scrum facilita la entrega anticipada de valor en el proyecto y lo sigue haciendo a lo largo del ciclo de vida del mismo. Una de las características claves de cualquier proyecto es la incertidumbre de los resultados. Es imposible garantizar el éxito del proyecto, independientemente de su tamaño o complejidad. Por lo tanto, tomando en cuenta esta incertidumbre de alcanzar el éxito, es importante empezar a entregar resultados durante el proyecto tan pronto como sea posible. Esta entrega temprana de buenos resultados, y por lo tanto de valor, brinda una oportunidad para la reinversión, demostrando el valor del proyecto a los stakeholders interesados. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 60
13. Definición del– DONE Los criterios de aceptación: Son los componentes, objetivos por los cuales se juzga la funcionalidad de un User Story. Done: Done es un conjunto de reglas que se aplican a todas los User. Stories en un determinado Sprint. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 61
14. Reuniones o ceremonias – SCRUM Para que cualquier proyecto tenga éxito, la comunicación es importante. Los equipos de Scrum emplean una serie de reuniones clave para estructurar el trabajo del equipo. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 63
a. El Sprint Los sprints son una buena estrategia para perder peso y romper con el estancamiento de su rutina de ejercicios. Este entrenamiento involucra piques, es decir alcanzar la velocidad máxima personal por un período corto de tiempo. + 64
a. El Sprint tiene una duración de 1 a 4 semanas, cada Sprint se puede considerar como un esfuerzo temporal es decir un proyecto con un horizonte no mayor de un mes. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 65
b. Tipos de Sprint Daily Standup Meeting Sprint Planning Meeting Sprint Review Meeting Restrospect Sprint Meeting Sprint Goal + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 67
Daily Standup Meeting Sprint En este proceso se lleva a cabo diariamente una reunión altamente focalizada con un time-box asignado y denominada: Daily Standup Meeting. Es un foro para que el equipo Scrum se ponga al día sobre sus progresos y sobre cualquier impedimento que pudieran estar enfrentando. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 68
Planning Meeting Sprint Cada sprint empieza con una reunión de planificación del sprint (Sprint Planning Meeting) durante el cual se consideran las historias de usuario de alta prioridad para su inclusión en el sprint. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 69
Review Meeting Sprint El final del sprint, se lleva a cabo una reunión de revisión del sprint (Sprint Review Meeting) en el cual se proporciona una demostración de los entregables al Product Owner y a los stakeholders relevantes. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 70
Retrospect Meeting Sprint En esta reunión el equipo revisa lo sucedido en el sprint anterior en relación a los procesos seguidos. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 71
Las cinco etapas de la Retrospectiva + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 73
Goal Objetivo Sprint Es una meta establecida para el Sprint que puede lograrse mediante la implementación de la lista de producto, proporciona una guía al equipo de desarrollo acerca de por qué está construyendo el incremento. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 74
c. Cancelación de un Sprint Un Sprint puede ser cancelado antes de que el bloque de tiempo llegue a su fin, siempre y cuando el objetivo del Sprint llegara a quedar obsoleto o no tiene sentido seguir con el Sprint. Solo el PO tiene la autoridad para cancelar el Sprint. Algoritmo de cancelación de un Sprint por el Product Owner + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 75
15. ¿Que puede ser terminado? Esta pregunta nos ayuda para que el Scrum Team trabaje para proyectar la funcionalidad que se desarrollara durante el Sprint, donde se define objetivo del Sprint (Sprint. Goal). El número de elementos del Product Backlog seleccionados para el Sprint depende únicamente del Development Team. % 87 Faltan todas las explicaciones / desarrollos conceptuales de todas las figuras expuestas; falta mucha información. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 77
15. ¿Que puede ser terminado? En la reunión del Sprint Goal se plantea una guía para que el equipo de desarrollo trabaje el objetivo del Sprint. Una vez determinado cuales Sprint Goal y seleccionado los PBI para cumplirlo, los Development deciden técnicamente como construirá el incremento del producto, esto hace referencia a la creación de las Task por parte del Development Team. Esta es una de la técnica más reconocida en Scrum, ya que es muy sencilla, divertida y eficaz, donde los Development estiman como grupo el esfuerzo a + realizar en el Sprint. Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 78
16. Artefactos Los artefactos en Scrum son herramientas que propone Scrum para mantener organizado un proyecto, estos son: a. Product Backlog b. Sprint Backlog c. Burn-Down Chart (Product, Sprint) d. Incremento del producto + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 80
a. Product Backlog Es uno de los artefactos más esenciales de Scrum, es una lista priorizada de las ideas para el producto, todo el trabajo que realiza el Development Team proviene del Product Backlog. Este documento es escrito en formato de historias de los usuarios User. Stories. El Product Owner es el responsable del Product Backlog, incluyendo el contenido, disponibilidad y orden, aunque puede y debería recibir ayuda para construirlo y mantenerlo actualizado. + Fuente. Elaboración propia, tomada de, 2017 SCRUMstudy™. Una guía para el conocimiento de Scrum (SBOK™ Guide) 81
Product Backlog + Fuente. Una guía para el conocimiento de Scrum (SBOK™ Guide) 2017 SCRUMstudy™. 82
b. Sprint Backlog Es la lista de tareas del Product Backlog refinados que han sido elegidos para ser desarrollados en el Sprint actual. Generado el Sprint Backlog, comienza el Sprint y el equipo de desarrollo implementa el nuevo incremento de producto definido por el Sprint Backlog. Este se ve representado por medio de las tableros de Scrum. + Fuente. Una guía para el conocimiento de Scrum (SBOK™ Guide) 2017 SCRUMstudy™. 84
c. Burn-Down Chart , (Product, Sprint) Un diagrama Burn-Down o diagrama de quemados, es una representación gráfica del trabajo por hacer en un proyecto o muestra el esfuerzo restante durante un periodo determinado de tiempo. A este radicado de información se le puede dar dos usos: Product Burn-Down Sprint Burn-Down YOUR TEXT HERE + Fuente. Una guía para el conocimiento de Scrum (SBOK™ Guide) 2017 SCRUMstudy™. 85
Burn-Down Chart , (Product, Sprint) + Fuente. Una guía para el conocimiento de Scrum (SBOK™ Guide) 2017 SCRUMstudy™. 86
Product Burn- Down Visión global del proyecto, se realiza a partir del Product Backlog. + Fuente. Una guía para el conocimiento de Scrum (SBOK™ Guide) 2017 SCRUMstudy™. 87
Sprint Burn- Down Visión concreta para cada Sprint, se realiza a partir del Sprint Backlog. + Fuente. Una guía para el conocimiento de Scrum (SBOK™ Guide) 2017 SCRUMstudy™. 89
d. Incremento del Producto Al final de cada Sprint, el equipo de desarrollo es responsable de presentar un incremento de producto potencialmente entregable. 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. 30% 20% + 54% 69% 100% 83% Fuente. Una guía para el conocimiento de Scrum (SBOK™ Guide) 2017 SCRUMstudy™. 90
17. Método Kanban es una palabra japonesa que significa “tarjetas visuales” (kan significa visual, y ban tarjeta). Esta técnica se creó en Toyota, y se utiliza para controlar el avance del trabajo, en el contexto de una línea de producción. OBJETIVO: ACCIONES CLIENTE Resultados Claves (RETOS). BACKLOG Lo que debemos Lo que estamos hacer haciendo Lo que ya hicimos + Fuente. Elaboración propia, extraído de Una guía para el conocimiento de Scrum (SBOK™ Guide) 2017 SCRUMstudy™. 91
Referencias bibliográficas y electrónicas 1. Una guía para el cuerpo de conocimiento de Scrum (Guía SBOK™) Tercera edición. Incluye escalamiento de Scrum en grandes proyectos y escalamiento de Scrum para la empresa. Una guía integral para la entrega de proyectos utilizando Scrum Título original en inglés: A Guide to the Scrum Body Of Knowledge (SBOK™Guide) – 3 rd Edition ISBN: 978 -0 -9899252 -0 -4 1. Panorama general AGILE-SCRUM, SCRUM-BOARD, BURNDOWN CHART, Prak. TIva SAS-2018. Versión 1. 0 1. Manifiesto ágil, Manifiesto por el desarrollo ágil de software. http: //agilemanifesto. org/iso/es/manifesto. html 1. Scrum Body of Knowledge | SBOK 2017 1. La guía de Scrum, La guía definitiva de Scrum: Las reglas del juego. Noviembre-2017. + Desarrollado y soportado por los creadores de Scrum: Ken Schwaber y Jeff Sutherland. 93
94
- Slides: 94