MAC en producto

Curso de Scrum Master

Fundamentos del Scrum Master

Bienvenida e introducción al curso

¿Qué hace un Scrum Master?

Scrum desde la perspectiva del Scrum Master

Quiz: Fundamentos del Scrum Master

Modelos adaptativos en Scrum

MAC en producto

MAC en proceso

MAC en progreso

Quiz: Modelos adaptativos en Scrum

Servicios del Scrum Master

Servicio al Product Owner

Servicio al Scrum Team

Servicio a la Organización

Scrum Master como Facilitador

Facilitación de Sprint Planning

Facilitación de la Daily Scrum

Facilitación de Sprint Review

Facilitación de Sprint Retrospective

Recomendaciones

Anti patrones de Scrum

Preguntas frecuentes

¿Cómo certificarse?

Quiz: Recomendaciones

Cierre

¿Qué sigue después?

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Si ya tienes una cuenta,

Recursos

Aportes 29

Preguntas 2

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Walter Nicolás Aragón

hace 2 años

Buenas a todos! Dejo mis apuntes sobre el Modelo Adaptativo de Control a nivel de producto.

Transparencia

El product backlog debe ser transparente para todos.
El incremento se revisan en el sprint review, se debe saber que hicimos a lo largo del sprint (a nivel producto).

Inspección

La Sprint Review no se debe presentar con diapositivas, se debe inspeccionar el incremento del producto, el cliente debe interactuar con el producto que se ha llegado a construir en el sprint.

Adaptación

Cuando el cliente interactua con el producto nos puede dar un feedback directo (ej: me funciona, me sirve, no es lo que esperaba, me gustaría cambiar esto, etc) o bien, indirecto (detectar lenguaje corporal, el comportamiento que el cliente tiene al interactuar con el producto). Debemos notar irregularidades para mejorar y transmitir mejor el mensaje del producto.

Esta adaptación ocurre en la siguiente sprint Planning. Debemos planear que vamos a hacer de cara al siguiente sprint para mejorar nuestro incremento de producto.

Sandra Sierra

hace 2 años

Hola, les comparto mis apuntes de la clase:

Jorge Silva Diaz

hace 2 años

MI Resumen de la Clase:

Modelos Adaptativos de Control a nivel de Producto:

Product Backlog: Es un artefacto que debe ser transparente y accesible para todos(Transparencia)
Incremento: Que hicimos a lo largo del Sprint (Transparencia)

Sprint Review: Revision del Sprint (inspeccion) Ver el incremento del producto. (Transparencia)

Inspeccion de producto que busca iterar el cliente con el producto.

Adpatacion: Luego de la revision la capacidad de adaptarse al feedback. Ocurre tambien en el Sprint Planning

Gerardo Andrés Cabrera Medina

hace 2 años

👷🏽‍♂️Adaptativo de Control a nivel de producto.

🌊Transparencia

El Product Backlog debe ser transparente para todos.
El incremento se revisan en el sprint review, se debe saber que hicimos a lo largo del sprint (a nivel producto).

🔍Inspección

La Sprint Review no se debe presentar con diapositivas, se debe inspeccionar el incremento del producto, el cliente debe interactuar con el producto que se ha llegado a construir en el sprint.

🔩Adaptación

Cuando el cliente interactúa con el producto nos puede dar un feedback directo (ej: me funciona, me sirve, no es lo que esperaba, me gustaría cambiar esto, etc) o bien, indirecto (detectar lenguaje corporal, el comportamiento que el cliente tiene al interactuar con el producto). Debemos notar irregularidades para mejorar y transmitir mejor el mensaje del producto.
Esta adaptación ocurre en la siguiente Sprint Planning. Debemos planear que vamos a hacer de cara al siguiente sprint para mejorar nuestro incremento de producto.

Pablo Hurtado

hace 2 años

El spring retrospective es parte del modelo adaptativo de Scrum, ahí se adapta el proceso llevado a cabo por el Scrum Team

Juliana Rios

hace 2 años

TRANSPARECIA:
tener la información visible y accesible a todos.

-En el product backlog se encuentra el potencial futuro de lo que va a tener el producto que se esta desarrollando.
El product backlog debe ser transparente y accesible por todos, es una mala practica que el product backlog este oculto o solo sea de conocimiento para algunos.
-El **incremento **también debe tener transparencia, este es el resultado del sprint, que se hizo a nivel del producto.

INSPECCIÓN:
proceso de analizar la información para posteriormente tomar decisiones.
-En la sprint review se inspecciona el incremento del producto; los stakeholders, los usuarios y clientes deben hacer parte de este evento, el equipo scrum muestra el incremento de producto para que los interesados interactúen con el producto y puedan hacer feedback.
La interacción es la inspección.

ADAPTACIÓN:
feedback indirecto, es el que no se dice, el lenguaje corporal del cliente interactuando con el increment del producto.
De esa forma se pueden observar nuevos retos que pueden ser llevados a la mejora del producto.
La adaptación se trata del cómo mejorar el producto en los futuros incrementos para que genere mas valor al cliente.
La adaptación se da en la Sprint planning

Gina Alexandra Rojas Arias

hace 2 años

El modelo adaptativo se basa de 3 pilares fundamentales Transparencia: El product backlog debe estar al alcance de todo el team sin importar el rol, el incremento del producto debe ser transparente y visible y se revisa en el Sprint review Inspección: En el Sprint review se muestra el incremento de producto al cliente no bajo diapositivas, mostrando la cantidad de puntos de historia o la arquitectura o temas técnicos en el caso de desarrollo de Software,los stakeholders del cliente deben interactuar con el producto. Adaptación: Cuando el cliente interactúa con el producto nos da información de cómo vamos, que se debe mejorar,

Paula Concha

hace 2 años

1.- Identifica Antipatrones:
1.1 Las Responsabilidades no están de acuerdo al marco Scrum.
1.2 Los eventos Daily Scrum, Sprint Review y Sprint no están de acuerdo al marco Scrum.
1.3 El artefacto Product Backlog no se crea de acuerdo al marco Scrum.

Nicolas Martin

hace 7 meses

**Caso de estudio** Antipatrones. 1. Cambio en los tiempos, estructura y razon de ser de cada ''EVENTO''. 2. Artefactos mal usados o implementados 3. no hay transparencia en cuanto a la informacion y las ''RESPONSABILIDADES'' 4. Sin incremento al producto por falta del DoD **PROPUESTA** * Aclaracion de roles y responsabilidades con todos lo involucrados. * Creacion e implementacion de las politicas de manejo ( que, para que y porque), esto evitara cambios en el manejo de los artefactos y eventos. * Capacitacion y manejo por parte del SM con respecto al buen uso de los artefactos. * Buen uso de las retrospectivas para adaptar el marco de trabajo Scrum al equipo de trabajo. la mejora continua es el paso para la transformacion y adaptacion.

Maria Alexandra Yajure Flores

hace 7 meses

Hola, entendiendo que los MAC ayudan a entender la incertidumbre y responder.... para terminar de entender el impacto de estos me gustaría saber cuales pueden ser las consecuencias de no considerarlos, de ser posible un ejemplo . Aun siento que no he entendido del todo la definición de los MAC

Digital

hace 7 meses

Mi proyecto: **Antipatrones:** 1. PO distante, como que solo es una figura de control y vigilancia, para regañar. 1. El PO modifica el Product Backlog a solas y reparte tareas de allí cuando quiere. 1. La Sprint Review no es para presentar lo que se hizo y ya, sino para invitar al cliente y los interesados a interactuar con el producto. 1. No tener un Definition of Done, ya que esto es lo que define a lo que se quiere llegar, los criterios para definir el Sprint como terminado. 1. Que se alarguen tanto los Dailys. 1. Que no exista el hábito de asistir a Sprint Retrospectives y haya tanto tedio con los eventos Scrum. Pasar los Sprints a un mes en vez de a dos semanas para evitar tanto evento de Scrum. 1. Creer tan firmemente que en dos semanas de avance de un Sprint no se entrega valor; puede que no haya tanto valor como con un Sprint terminado, pero los avances también son importantes para ver cómo ha mejorado el producto, y eso también es valor. 1. Que en vez de que el equipo esté dispuesto a encontrar soluciones para mejorar la forma de trabajo y las reuniones como Sprint Retrospectives y Dailys, digan que mejor no hacerlas o hacerlas menos. Esto me dice que hay una falta de pertenencia en el equipo y que todos están hartos por la mala organización. **Backlog de transformación ágil:** 1. Antipatrón 8: empezar a fomentar el sentido de pertenencia en el equipo mediante integraciones intra- y extralaborales, dinámicas, conversaciones, *feedbacks* y creando entornos de trabajo más amenos para todos. 1. Antipatrón 7: revisar los Sprints que tenemos y lo que queremos alcanzar con cada uno, además del esfuerzo y tiempo que suponen: esto ayudaría a gestionar mejor el tiempo de cada Sprint y distribuirlo mejor para cada uno, para así saber si deben durar dos semanas, un mes u otro período de tiempo. 1. Antipatrón 4: crearía junto con el Scrum Team un Definition of Done del Sprint, el cual debe cumplirse en su totalidad al finalizar el Sprint. 1. Antipatrón 1: si bien el PO no hace parte como tal del Scrum Team, pues es más un puente entre este y el cliente, me parece a mí que tiene una actitud de solo llegar a decir “bueno, tú qué hiciste” y de exponer públicamente los errores de miembros de su equipo. Para mí, esta actitud debe cambiar: el PO debe estar más interesado en su equipo, en el bienestar de este y en el Sprint, llegar como un apoyo de cara al cliente y al equipo, enterarse de los avances y aportar con opiniones constructivas y que lleven a la agilidad, la confianza, la productividad. Para esto, lo abordaría en un Feedback Meeting y encontraría junto con él soluciones que lo lleven a cambiar su actitud: propondría nuevas formas de ver los eventos Scrum, haría y propondría ejercicios, etc. 1. Antipatrón 2: el PO debe velar por la claridad y visibilidad de los elementos, herramientas y trabajo de su equipo de cara a este mismo y al cliente. Yo crearía un sistema para tomar requerimientos nuevos del jefe del PO que no implicaran añadirlos al Product Backlog en secreto y que incluyeran el uso de un tiempo del día en específico para esto. Por ejemplo, se cambia el proceso de la siguiente forma: el PO solo añade nuevos requerimientos al Product Backlog la última hora de la jornada laboral, poniendo antes la fecha en que añadió estos requerimientos. Al día siguiente, estas modificaciones se priorizan y se hablan con el Scrum Master para comentarlas y asignarlas rápidamente en el Daily. 1. Antipatrón 6: enseñar al PO y al equipo a dejar la pereza con los eventos Scrum. Esto se lograría al organizarlos mejor y añadirles elementos más dinámicos, divertidos y amenos. Sí, el trabajo no tiene por qué estar lejos de esto. Por ejemplo, yo incentivaría al equipo Scrum a asistir a Sprint Retrospectives mediante la gamificación o mediante un reto, obviamente primero haciéndoles saber, en primera instancia al mismo PO para que haya alineación, cuál es la importancia de este evento. Dentro de este mismo evento y en adelante, cuando vayan viendo la diferencia, les demostraría su importancia. 1. Antipatrón 5: crearía una estrategia para acortar las intervenciones en el Daily: que no me cuenten todos los detalles de lo que avanzaron, pues estos incluso se repiten varios días seguidos, sino enseñar a contestar brevemente a preguntas específicas como qué hiciste y cómo lo hiciste, como si se estuvieran vendiendo (cuando vendes muchas veces no puedes echar la lora de horas y horas). Sería importante enseñar al equipo sobre comunicación efectiva. 2. Antipatrón 3: las Sprint Reviews solo deberían hacerse cuando se pueda mostrar un avance del producto con el que pueda interactuar el cliente.

Dayana Perez

hace 8 meses

Mi proyecto: 1\. Realizar una reunión con el Product Owner (PO) para obtener una visión clara del estado actual del proyecto. 2\. Convocar a una reunión con el PO, el jefe y el vicepresidente para discutir la relevancia de aplicar el marco Scrum conforme a sus directrices, enfatizando los beneficios de una implementación correcta y evitando la priorización de Historias de Usuario (HU) basada únicamente en solicitudes individuales. 3\. Comunicar al PO que su función principal en el equipo es representar la voz del cliente, entendiendo y transmitiendo los requisitos y deseos del cliente al equipo Scrum. 4\. Informar al PO que es crucial trabajar de manera colaborativa con el equipo de desarrollo para lograr los objetivos del proyecto. 5\. Organizar una reunión con todo el equipo Scrum para definir los distintos eventos y sus respectivos intervalos de tiempo, con el fin de mejorar la agilidad del proceso y garantizar una comprensión común de las actividades, artefactos y sus cronogramas. 6\. Presentar al PO las herramientas necesarias para gestionar el backlog del producto de forma ordenada y visible para todo el equipo. 7\. Introducir al PO en técnicas de priorización del backlog del producto, como el Planning Poker y la evaluación basada en el valor de negocio. Es importante destacar que debe colaborar estrechamente con el equipo Scrum y los stakeholders en este proceso. 8\. Establecer con el PO las responsabilidades específicas que debe cumplir con su equipo Scrum, incluyendo la definición de épicas y HU, el refinamiento de las HU junto con el equipo de desarrollo, la definición de criterios de terminación para cada HU, la participación en las Daily Scrum cuando sea posible, entre otros aspectos importantes. 9\. Definir con el equipo de desarrollo sus responsabilidades, como colaborar con el PO en el refinamiento y la estimación de las HU, asignarse tareas según su experiencia, participar en la selección de HU durante la planificación del sprint, realizar las Daily Scrum de manera concisa, asistir a las reuniones de revisión y retrospectiva del sprint, entre otros aspectos relevantes. 10\. Establecer con todo el equipo Scrum la importancia de invitar a usuarios y stakeholders al Sprint Review para recibir retroalimentación sobre el producto entregado, evitar presentaciones con detalles técnicos excesivos y enfocarse en mejorar la agilidad del proceso mediante la participación activa en las retrospectivas de sprint. 11\. Coordinar y acompañar a equipo scrum en todos los eventos facilitándoles las herramientas que sean necesarias para llevar a cabo las mismas de manera satisfactoria.

Jose Carlos Cervantes

hace 10 meses

EN la actividad extra, mi aportaciñon de que antipatron se tiene siguiendo el marco de SCRUM, es que primero la responsabilidad de Product Owner no la tienen bien definidia y falta un scrum master. Segundo no hau transparencia en tareas en el product back log, ya que como vayan llegando, se ponen como prioridad y no se muestran o se discute con el equipo , lo que no genera una adaptaciòn adecuada y la inspecciòn es siguiendo una metodo duro de control de proceso y no de calidad de incremento o como crecio su valor

Douglas Isturiz

hace 10 meses

# Análisis de la situación actual del Desarrollo de la App . ***intercambiagram*** ## MODELOS ADAPTATIVOS DE CONTROL EN PRODUCTO. ## En cuanto a la transparencia: Se evidencia que no hay transparencia, en el modelo adaptativo de control en producto en el proyecto Desarrollo de App Intercambiagram, esto debido a: *

El artefacto Product Backlog se realiza a través de pedidos del vicepresidente y no ha sido desarrollado por el SCRUM TEAM. Es decir, ninguna de las personas que conforman el equipo dentro de este marco de trabajo no participa en el desarrollo de este artefacto. No hay claridad en el objetivo del producto y no hay una lista definida para lograr el objetivo del producto, la lista va creciendo conforme lo indica el vicepresidente. *

Product Backlog debe encontrarse en un lugar público, bien sea físicamente escrito o un lugar virtual como Intranet, donde se haya definido un espacio de acceso a todos los interesados. *

El artefacto Increment no se produce ya que este no hay Definición de Terminado (Definition of Done), según la guía de SCRUM es necesario que haya una descripción formal del estado de Increment. En ningún momento el equipo en conjunto ha descrito las medidas de calidad que se debe cumplir y/o qué aspectos determinan cuando un trabajo se ha completado. Las acciones para que El Product Backlog sea transparentes son las siguientes: 1. El SCRUM MASTER deberá colocarse el sombrero de entrenador para apoyar y ayudar a el equipo SCRUM e interesados a comprender la teoría y práctica del marco de trabajo del SCRUM. 2. Es necesario que el Product Owner redefina el Product Backlog tomando en cuenta los requerimientos de todos los interesados o stakeholders. 3. El Product Owner debe responsabilizarse por definir y exponer el Objetivo del Producto, previa validación con el vicepresidente (en este caso puede solicitar la mentoría del SCRUM MASTER para evitar cambios a voluntad del vicepresidente). 4. Dado el objetivo definido, el Product Owner debe obtener y comunicar una lista de forma ordenada y con prioridad de todos los elementos que se requiere del producto. 5. El Product Owner debe hacer público el Product Backlog resultante, para que así se cumpla uno de los pilares empíricos del Scrum la transparencia. 6. En esta redefinición es importante que sea comunicada al SCRUM TEAM. 7. El Scrum Master participará con los diferentes sombreros en cada una de la fase de la redifinición: facilitador para que haya participación del equipo, entrenador para dar a conocer a los diferentes interesados, en especial al Product Owner y Vicepresidente en qué consiste el Marco de Trabajo y cómo mentor para que la lista sea desarrollada de manera de que cada elemento de la lista sea transparentes, visible y se entienda. ## En cuanto a la inspección: En el modelo adaptativo de control en producto la inspección se realiza a través del evento Sprint Review, ya que se hace una revisión del sprint. Ésta es realizada por todo el equipo Scrum y los interesados, evalúan los resultados y de allí pueden surgir mejoras o cambios. Es un evento que le permite la interacción con el producto. En el desarrollo de la app no se efectúa INSPECCIÓN DEL PRODUCTO, por las siguientes razones: *

Los Devolopers en primer lugar, sólo le presentan avances al Producto Owner y no todo el equipo incluyendo los interesados. *

Proyectan un documento PowerPoint información relacionada con historias de usuarios, debido a que no hay Definición de Terminado, a consecuencia no está presente el artefacto Increment, por lo que no tienen producto completo terminado para mostrar. Las acciones para que exista Inspección en el modelo adaptativo del producto son las siguientes: 1. El Scrum Team debe crear una Definición de Terminado para cada uno de los elementos del Product Backlog, tomando en cuenta los estándares de la organización. 2. El SCRUM MASTER debe convocar a todos los interesados y/o stakeholders a la Sprint Review 3. Realizar una demostración del producto y permitir su interacción a todos los asistentes al Sprint Review. ## En cuanto a la adaptación: En el desarrollo del app no existe el pilar de la adaptación a nivel de modelo adaptativo de control, en el evento de la Sprint Review se da una serie de información al Product Owner acerca de las historias de los usuarios y los interesados no tienen una interacción directa con el producto, por lo que nos pueden tomar todos aquellos elementos de mejora. Una vez que se ejecuten las acciones definidas anteriormente, principalmente y de forma inmediata: **El SCRUM MASTER deberá colocarse el sombrero de entrenador para apoyar y ayudar a el equipo SCRUM e interesados a comprender la teoría y práctica del marco de trabajo del SCRUM.** El Pilar de la Adaptación estará presente en el Modelo Adaptativo de Control del Producto.

Douglas Isturiz

hace 10 meses

**TRANSPARENCIA.** La transparencia, se efectúa en el producto backlog y en el increment: ü Product Backlog: Se obtiene la lista de todos los potenciales, es un artefacto el potencial, este debe ser visible y accesible para todos (indica el futuro que tendrá el producto por eso debe ser transparente para todos). ü El incremento del producto se revisa en el sprint review y da transparencia. **INSPECCIÓN:** Se efectúa en sprint review. El objetivo del Sprint Review es inspeccionar el incremento del producto, los usuarios deben estar presente y el equipo scrum presentan el sprint review, se hace cuando interactúa con el producto. Inspección de producto es la interacción del cliente con el producto. Lo recomendable es no utilizar el print review para hacer seguimiento del trabajo del sprint. **ADAPTACIÓN** Está relacionada con adaptar el feedback recibido del cliente (directa o indirectamente) al producto, se debe observar muy bien en la interacción que tiene el usuario e interesados con el producto para captar todos los puntos de mejoras. La adaptación se realiza en el Sprint Planner: qué se realizará para aplicar todas las mejoras detectadas.

Jhon Jairo Santiago Carvajalino

hace un año

En la Sprint Retrospective también se hace adaptation.

Guillermo Paz Errobidart

hace un año

Pobre la gente que trabaja en la empresa del proyecto! jajaja necesitan urgente un buen scrum master

Guillermo Alomia Monjaraz

hace un año

No olvidar el Product Backlog debe ser transperente para todos y por ende el Incremento igual El Sprint Review debe ser realizado por el cliente, en compañia de los miembros del team, este dará su feedback y esto entrará al sprint planning

Alberto Farah Uparela

hace un año

Como Obtener a través de Scrum, transparencia a nivel de PRODUCTO en MAC (Modelo adaptativo de control. Esto para obtener una visión visible y accesible. 1\. Product Backlog = Artefacto que muestra el futuro potencial que tendrá el producto que se encuentra en desarrollo. 2\. Increment = Artefacto que provee transparencia de lo que se realizó durante el Sprint. 3\. Inspección = Cliente interactúa con el producto (Entregando un Fedback del producto). este debe ser preferiblemente supervisado para ver a usabilidad y el comportamiento del cliente con el producto. 4\. Adaptación = Analizar y definir como se va a mejorar y potenciar el producto, de tal modo que se pueda generar mas valor al cliente. Sucede durante el Sprint Planing (Mostrando lo que se realizará durante el siguiente Sprint para mejorar el INCREMENTO DE PRODUCTO.

Juan Wilton Torvisco Salas

hace 2 años

Martin Miguel Erro

hace un año

Transparencia: Product Backlog “Artefacto”. Incremento “Artefacto”.

Inspeccion: Sprint Review “Ceremonia”,

Adaptacion: Sprint Planning “Ceremonia”,

lquijije

hace un año

_Artefactos de Transparencia: _

Product Backlog
Incremento

Artefactos de Inspección:

Sprint Review

Artefactos de Adaptación:

Sprint Planning

Santiago Rodriguez Chaves

hace un año

Dentro de scrum se tienen dos artefactos donde se puede tener transparencia a nivel de producto:

Product backlog: lista con todas las características y detalles del producto a desarrollar Debe ser visible y accesible a todo

Incremento: se revisa en el sprint review, aqui se hace transparente que es lo que se hizo dentro del sprint.

Manuel Villegas

hace 2 años

Caso de estudio: Scrum Mastery | Identificación de antipatrones del proyecto:

Organizar adecuadamente las ceremonias de SCRUM, implementando cronómetros para adecuar los tiempos.
Ayudar a designar correctamente los papeles que se deben ejercer por rol dados por el marco Scrum.
Establecer un mural accesible por el equipo y la organización donde se aclare el Product Backlog y sprint backlog.
Ayudar al equipo a establecer una defición de Terminado
Implementar sesiones de entrenaimiento en vivir cinco valores: Compromiso, Foco, Franqueza, Respeto y Coraje.

Eduardo Rodriguez Cisneros

hace 2 años

Comparto mi mapa mental de la clase

Silvia Isabel Lozano Argel

hace 2 años

Yo creo que obtenemos transparencia en las dailys y basado en el backlog

Jhon Jairo Santiago Carvajalino

hace 2 años

La inspección debe ser constante por parte del equipo y generar adaptaciones para que el objetivo propuesto se cumpla durante el sprint. Todos los eventos de Scrum están diseñados para generar cambios y esto se logra con una inspección frecuente y un equipo empoderado.

irma lida Cardona Henao

hace 2 años

Hola mis notas del Modelo Adaptativo de Control de Producto:
Tres pilares: Transparencia, Inspección y Adaptación

Transparencia: Generar información accesible y visible. Se ve en el Product Backlog, Increment
Inspección Obtener la información, analizarla y tomar decisiones. Se ve en el Sprint Review
Adaptación: Tomar decisiones en función de lo que estamos observando y si se debe tomar otra vía alterna. Se ve en el Sprint Planning

Jesús Movilla

hace 2 años

Comparto, donde están reflejado los 3 pilares del modelo adaptativo de control en el proceso scrum.

Transparencia:
La transparencia se ve reflejada en el product backlog que es donde se encuentran cada una de las tareas a ejecutar para ir obteniendo incrementos del producto final. además de que esta lista de tareas debe irse actualizando a mediada que avanza el proceso scrum.

Luego tenemos el incremento: que se podría decir que es el avance del producto final, es el reflejo del trabajo realizado

Inspeccion
sprint review: que es donde se expone a las partes interesadas sobre el incremento realizado, además de que se obtiene retroalimentación del trabajo realizado y del próximo a realizar

Adaptación
Sprint planning: donde se definen las siguientes actividades a trabajar del producy backlog y se trabaja en la retroalimentación del sprint review