scrum events time boxing
Introducción a los eventos de Scrum:
En nuestros tutoriales anteriores, discutimos Scrum y cómo está estructurado.
Y nuestro tutorial anterior explicó todo sobre Artefactos Scrum en detalle.
Sabemos quién forma el equipo Scrum y qué diferentes artefactos se desarrollan a lo largo del proceso. Hemos establecido una sólida base ahora. Por lo tanto, demos un paso adelante en Scrum y discutamos los eventos / ceremonias clave que constituyen el Proceso Scrum.
En este tutorial, intentaremos comprender qué significa cada uno de los eventos de Scrum, cuáles son las características esenciales y cómo las organizamos en detalle.
Lo que vas a aprender:
- Visión general
- Tipos de eventos de Scrum
- ¿Qué es Time Boxing?
- La planificación del Sprint
- El Standup diario
- La revisión de Sprint
- La retrospectiva del Sprint
- Refinamiento de la cartera de pedidos
- Conclusión
- Lectura recomendada
Visión general
Mientras trabaja en un proyecto basado en Scrum, el equipo de Scrum pasa por una serie de Ceremonias de Scrum.
Algunos pueden llamarlos ceremonias o eventos Scrum y otros pueden llamarlos para rituales o reuniones. Independientemente de las diferentes terminologías que se utilicen aquí, el objetivo de cada evento Scrum sigue siendo el mismo. Cada uno de los eventos de Scrum, en esencia, ayuda a lograr y monitorear el trabajo de Sprint.
Tipos de eventos de Scrum
Cada ceremonia de Scrum es un evento / reunión en persona organizada por el Scrum Master para los grupos dedicados. Además del equipo central, algunas de las reuniones pueden involucrar a las partes interesadas, los gerentes de entrega o incluso al propio cliente. Estas reuniones tienen un tiempo limitado y, por lo tanto, deben completarse dentro del marco de tiempo estipulado.
El objetivo de cada uno de los encuentros es reunir a los participantes y dejarles discutir el trabajo en cuestión. La expectativa de cada participante es mantenerse enfocado, comprometido y participativo.
Se considera como una oportunidad para conversar, examinar y recuperar la retroalimentación del trabajo realizado. A diferencia de las reuniones ordinarias, los eventos Scrum están orientados a resultados, encuadrados en el tiempo, basados en audiencia objetivo y tienen un objetivo específico alineado con cada uno de ellos.
¿Qué es Time Boxing?
El timeboxing es una de las características clave adjuntas a cada evento Scrum. Se espera que los participantes sean conscientes y respetuosos del tiempo asignado a cada uno de los eventos. Los eventos no se pueden extender pero se pueden acortar si los objetivos de la reunión ya se han logrado.
Scrum Master, que también es un facilitador de todos los eventos de Scrum, se asegura de que todos entiendan la importancia del boxeo en el tiempo y también les recuerda que deben concentrarse en el objetivo de la reunión para obtener los mejores resultados y en los resultados de tiempo con desviaciones.
Idealmente, el Timebox para un evento no debería extenderse, pero como sabemos que Scrum no se trata de las reglas, el tiempo puede extenderse a una duración particular si todos los participantes están de acuerdo.
¿Cómo decidimos el cuadro de tiempo para cada uno de los eventos de Scrum?
El cuadro de tiempo para los eventos de Scrum es directamente proporcional a la duración del Sprint. Sin embargo, la única excepción a esta regla es Daily Standup, que tiene un tiempo fijo de 15 minutos independientemente de la duración del Sprint.
Hay marcos de tiempo estándar para cada evento según la duración del Sprint. Sin embargo, el equipo tiene la libertad de decidir los plazos para estos eventos en función de sus requisitos.
Comprendamos más de estos conceptos discutiendo cada evento de Scrum en detalle.
La planificación del Sprint
Como requisito previo para esta ceremonia, el Product Owner debe tener un Product Backlog priorizado estable de historias de usuarios preparadas antes de asistir a la reunión. Las historias de los usuarios deben estar bien formadas y ser lo suficientemente claras para que el equipo las comprenda.
El Product Owner puede buscar ayuda de las Partes Interesadas, el Cliente, el Diseñador y el Scrum Master para desarrollar el Product Backlog.
Es obligatorio tener un criterio de aceptación en una historia de usuario. El equipo está autorizado a rechazar una historia de usuario sin los criterios de aceptación.
Objetivo
La planificación del Sprint es la ceremonia inicial al iniciar un Sprint. El propósito de la reunión de Sprint Planning es crear un Sprint Goal, seleccionar historias de usuarios desde Product Backlog hasta Sprint Backlog y discutirlas en detalle.
El equipo se reúne en una sala de reuniones junto con el Product Owner y el Scrum Master, donde el Product Owner presenta las historias de usuario que deben seleccionarse para el próximo sprint.
El equipo puede hacer tantas preguntas como quiera para saber más sobre la historia y es responsabilidad del propietario del producto abordar las consultas. El equipo también podría cuestionar la historia por su integridad e idoneidad.
Si se requiere información adicional dentro de la historia o tiene una dependencia incompleta o se encuentra incompleta, el equipo tiene el poder de rechazar esa historia.
Después de todo, las dudas se han aclarado y el equipo sabe la cantidad exacta de trabajo que debe realizarse para completar una historia, luego el equipo estima y otorga los Story Points a cada una de las User Story.
De manera similar, se comentan y estiman las otras historias. El equipo ahora selecciona las Historias de la parte superior de la Pila de Producto Priorizada en la Pila de Sprint que creen que podrán comprometer y completar en el Sprint dada su velocidad pasada.
La velocidad está determinada por el número total de puntos de historia completados en un sprint promedio. La velocidad se calcula en función de los Sprints históricos y promediándolos. Cuantos más sprints completemos, más estable será la velocidad de un equipo.
Muchos equipos utilizan cartas de Planning Poker para estimar historias. La técnica de estimación más común es señalar historias utilizando la serie de Fibonacci. La serie de Fibonacci es una serie de números donde cada número siguiente de la serie se constituye sumando los dos números anteriores.
Serie de Fibonacci - 1, 1, 2, 3, 5, 8, 13 y así sucesivamente.
Las historias de usuario estimadas más allá de 13 puntos de historia se consideran muy grandes para ser completadas en un solo sprint y, por lo tanto, se descomponen en historias de usuario lógicas más pequeñas que se pueden estimar individualmente.
Durante una reunión de planificación de Sprint, el equipo también creará tareas en las historias de usuario que se han seleccionado para el Sprint. No se espera que el equipo asigne todas las historias de usuarios durante la planificación del Sprint, pero es suficiente para comenzar. El resto de las tareas se pueden realizar durante el sprint.
El resultado clave de una reunión de planificación de Sprint es el Sprint Goal y el Sprint Backlog, que consiste en las historias de usuario que el equipo se ha comprometido a completar.
Además de las Historias de usuarios, puede haber algún otro tipo de elementos que pueden convertirse en parte del Sprint Backlog.
- Picos
- Deudas técnicas
- Insectos
Picos son las tareas de investigación para encontrar una solución, es decir, cuya necesidad es provocada por la propia historia de usuario. Algunas de las historias pueden no ser sencillas o no tienen la capacidad técnica y, por lo tanto, requerirían más análisis e investigación sobre ellas. Por lo tanto, se crea un pico. También puede incluir un POC si surge la necesidad.
Deudas técnicas son la refactorización del código existente. Muchas veces hay situaciones en las que el equipo tiene que volver a trabajar en el código que se desarrolló anteriormente para adaptarse a los nuevos requisitos.
Insectos en Scrum son generalmente los requisitos nuevos o perdidos que surgen de las historias de usuario aceptadas, pero que son relevantes para los elementos de trabajo actuales. Si no es un requisito, en realidad puede ser un error en el sistema que se descubrió durante los sprints anteriores, pero no se corrigió y se le dio prioridad en este sprint.
Asistentes
Todos en el equipo Scrum son parte de la reunión de planificación de Sprint. Nadie más que el equipo central está invitado a asistir a la reunión.
La reunión de Sprint Planning está organizada y facilitada por el Scrum Master, pero el Product Owner se roba el show.
Caja de tiempo
La reunión de planificación del Sprint puede tardar hasta medio día durante un Sprint de dos semanas. El cuadro de tiempo para una reunión de planificación de Sprint depende directamente de la duración del Sprint. Más corto para un Sprint corto y más largo para un Sprint largo.
La reunión de Sprint Planning tiene un papel muy importante en la Arquitectura Scrum general y afecta directamente al producto que se está desarrollando. Por lo tanto, el equipo debe invertir todo el tiempo que crea necesario para discutir todas las historias de usuario en detalle y puede proponer un cuadro de tiempo alternativo que se adapte a ellos.
Una vez que se decide y se acuerda la casilla de tiempo, es responsabilidad del Scrum Master mantener al equipo enfocado en la meta y al mismo tiempo llevar un registro del tiempo.
El Standup diario
Objetivo
Daily Standup es una reunión que brinda la oportunidad de ilustrar una visión general de la salud del Sprint. También es una plataforma para discutir en qué están trabajando los otros miembros del equipo y si hay algo que se detenga para lograr el objetivo del Sprint.
Durante una reunión diaria de pie, cada miembro del equipo comparte el estado de su progreso en los elementos de trabajo en los que está trabajando. También compartirían y buscarían ayuda de los otros miembros del equipo si hay obstáculos que bloqueen su progreso.
Durante una reunión diaria de pie, cada miembro del equipo alrededor de la mesa responde las siguientes tres preguntas clave una por una:
'¿Qué has hecho desde la última reunión diaria de pie?'
'¿Qué planeas hacer hoy?'
comandos unix entrevista preguntas y respuestas para experimentados
'¿Hay algún impedimento que bloquee su trabajo?'
Se espera que los otros miembros del equipo presten atención cuando alguien comparta el estado y ofrezcan ayuda si surge la necesidad. Tan pronto como el último miembro del equipo haya respondido las tres preguntas, la reunión termina ahí.
La reunión diaria de Standup brinda una imagen general de cuál es el estado de finalización actual y general de la iteración en la que están trabajando actualmente. Scrum Master juega un papel muy importante para mantener la reunión Daily Standup enfocada y encuadrada en el tiempo. También es responsable de resolver los impedimentos que impiden que el equipo avance con sus Historias de usuario.
Scrum Master también debe asegurarse de que nadie más que el equipo central haga preguntas y presente el estado. Puede permitir discusiones rápidas sobre las historias de los usuarios si es necesario, pero debe estar al tanto del tiempo todo el tiempo y puede intervenir en cualquier momento y pedir a los miembros del equipo que tengan una discusión fuera de línea.
Asistentes
Cualquiera puede asistir a una reunión diaria de Standup. Sin embargo, es obligatorio que el equipo central asista a la reunión y presente el estado de su trabajo.
Cualquier otra persona, incluso ajena al equipo, que esté interesada en conocer el progreso del Sprint, puede asistir a la Daily Standup Meeting, pero no puede presentar el estado de su trabajo ni cuestionar a los miembros del Equipo de Desarrollo sobre su trabajo.
Solo los miembros del equipo central pueden compartir su progreso de trabajo y se espera que todos los demás escuchen en silencio.
La reunión diaria de Standup debe realizarse incluso si hay un solo miembro del equipo presente.
El equipo puede llevar a cabo la Daily Standup Meeting por su cuenta o puede pedirle al Scrum Master que se la facilite.
Caja de tiempo
Como sugiere el nombre, una reunión diaria de pie se lleva a cabo todos los días y se espera que los participantes se pongan de pie, ya que es una reunión corta de solo 15 minutos. La idea es ceñirse a la agenda y no desviar el enfoque, por lo que la reunión se mantiene corta. Mantener la reunión también ayuda a las personas a comprometerse fácilmente con ella, ya que solo requiere 15 minutos.
La reunión diaria de Standup también se realiza a la misma hora y en el mismo lugar todos los días para reducir la confusión entre los participantes y los gastos generales para reservar las salas de reuniones todos los días. Se desaconseja el uso de computadoras portátiles, computadoras de escritorio o teléfonos móviles durante la reunión.
Los equipos pueden decidir cuándo celebrar la reunión Daily Standup y atenerse a ella. Sin embargo, la tendencia normal es mantener las reuniones a primera hora de la mañana. Para los equipos que trabajan en diferentes zonas horarias, la llamada de la mañana puede no funcionar y, por lo tanto, pueden tener la llamada de la tarde o lo que más les convenga.
El Scrum Master también puede compartir las noticias o actualizaciones importantes al final de la reunión con el equipo si el tiempo lo permite, pero no se le permite extender la reunión a ningún costo.
La revisión de Sprint
Objetivo
Sprint Review Meeting se trata de demostrar el trabajo realizado y recopilar comentarios y aceptación. En algunos lugares, la reunión Sprint Review también se conoce como Sprint Demo. La reunión de revisión de Sprint generalmente se realiza al final del Sprint pero antes de la reunión de Sprint Retrospective.
Los representantes elegidos del equipo demuestran los elementos de trabajo de Sprint actuales. Por lo general, el desarrollador que trabaja en la historia del usuario demuestra el trabajo y responde a las consultas planteadas por cualquier persona de la audiencia.
Las historias de usuario que se elaboran según la Definición de Terminado son las únicas candidatas para la demostración en la Reunión de Revisión de Sprint.
El Product Owner juega un papel muy importante durante la Sprint Review Meeting. Él es el responsable de evaluar cada una de las historias de usuario que se demuestran contra sus criterios de aceptación y acepta o rechaza la historia.
Las historias aceptadas se integran luego con el Done Increment, que es un entregable potencialmente enviable. A dónde iría una historia rechazada o incompleta es la llamada del Product Owner. Las historias rechazadas pueden convertirse en parte del próximo sprint o pueden pasar al Product Backlog desde donde se priorizarán nuevamente.
El resultado clave de la reunión de Revisión de Sprint es una imagen general de la fecha de finalización del Proyecto. El Product Owner acepta / rechaza la historia y las historias aceptadas luego se integran con el Incremento (creado durante sprints anteriores) como un todo para dar una mejor idea de dónde estamos para completar el producto completo.
Otro resultado clave de la reunión de Sprint Review es que los miembros del equipo aprenden algo sobre la estimación. La cantidad de historias de usuario aceptadas determina la cantidad de puntos de historia logrados en un sprint.
Así, de forma gradual, sprint a sprint, el equipo puede desarrollar la capacidad de estimar correctamente y tomar una decisión informada con respecto a los puntos de la historia que son factibles de lograr.
A menudo se observa que tales reuniones arrojan luz sobre los Criterios de Aceptación incompletos o sobre los nuevos requisitos que surgen. La mejor manera de salir de esta situación es cerrar las historias y marcarlas como hechas si cumplen con todos los Criterios de aceptación acordados inicialmente durante la Reunión de planificación del Sprint.
Todo lo que supere esto se considerará como un nuevo requisito y el propietario del producto es responsable de esos requisitos para el sprint futuro.
Asistentes
Los miembros del equipo asisten a la reunión de revisión de Sprint, incluidos el Scrum Master y el propietario del producto. Otros participantes en la Sprint Review Meeting son las partes interesadas, los gerentes de entrega, los clientes / usuarios finales o cualquier persona que esté interesada en ser parte de Sprint Review.
Caja de tiempo
En un escenario ideal para un sprint de dos semanas, pasamos aproximadamente 2 horas en la reunión de Revisión del Sprint. Esto puede variar según la duración del Sprint. Para un sprint más corto, Sprint Review más corto y para un sprint más largo, Sprint Review más largo.
Al igual que otras reuniones, el Scrum Master es responsable de mantener el impulso de la reunión y asegurarse de que las actividades (demostrando las historias, respondiendo las consultas, aceptando las historias, comentarios anotados, etc.) encajen dentro del marco de tiempo estipulado.
La retrospectiva del Sprint
Objetivo
Sprint Retrospective se trata de incorporar lo que dice Agile: ' Reflexiones periódicas sobre cómo ser más eficaz '. Sprint Retrospective brinda una oportunidad para que todo el equipo reflexione y contemple cómo fue el sprint y qué se debe hacer para improvisar los procesos. Sprint Retrospective se realiza al final de cada sprint.
Durante una reunión de Sprint Retrospective, todo el equipo se reúne y discute el Sprint que se acaba de completar. Se espera que el equipo sea transparente y dé opiniones honestas, pero no hay juegos de culpa.
Recuerda que el objetivo del encuentro es dar un paso adelante en el ámbito de la improvisación y no retener al equipo aumentando la tensión entre los integrantes.
Todos en Se espera que el equipo responda a las cuatro preguntas básicas:
El Scrum Master pide a los miembros del equipo que escriban sus puntos para cada uno de los cuadrantes como se muestra arriba en notas adhesivas. En algunos lugares, las herramientas se utilizan con el mismo propósito.
¿Qué salió bien?
Los miembros del equipo dan uno o más puntos por lo que salió bien en el último Sprint. Esta sección también se puede tomar como una oportunidad para apreciar y reconocer a los otros miembros del equipo por su buen trabajo.
¿Que has aprendido?
Scrum se considera una oportunidad para aprender algo nuevo en cada sprint. Esta área de un cuadrante es para discutir las conclusiones clave y los aprendizajes del último Sprint.
¿Qué no salió bien?
En esta sección, el equipo analiza los problemas y obstáculos que enfrentaron durante el último sprint. Esta parte de la reunión tiende a ser la más frágil, ya que las personas pueden plantear cuestiones que pueden hacer que los demás se sientan incómodos.
Es responsabilidad del Scrum Master tranquilizar la atmósfera si es necesario y enseñar a las personas a plantear sus problemas de manera constructiva en lugar de pasar por rondas de ataques personales.
Si alguno de los miembros se siente incómodo al enfrentar los problemas frente a los otros compañeros de equipo, puede ir al Scrum Master más adelante y discutir los problemas.
¿Qué se podría hacer mejor?
Esta parte de la reunión brinda a todos los miembros del equipo la oportunidad de discutir todos los problemas planteados anteriormente y encontrar la manera de resolverlos. Todos en el equipo son bienvenidos para proponer soluciones al problema en cuestión. Entonces, el equipo decide en unidad las mejores soluciones adecuadas.
El equipo también debe considerar atenerse a las cosas que se discutieron en la sección de lo que salió bien para los sprints futuros y, en el futuro, esas cosas se pueden agregar como parte integral del proceso.
El resultado de la reunión de Sprint Retrospective es una lista de elementos de acción acordados por los participantes para mejorar el proceso para el próximo Sprint.
Asistentes
Todo el equipo Scrum, incluido el Scrum Master y el Product Owner. Pero a diferencia de una reunión diaria de pie, el Scrum Master y el Producto también participan proporcionando sus aportes y puntos retrospectivos.
Al igual que la reunión Daily Standup, la reunión Sprint Retrospective también es facilitada por el Scrum Master. Scrum Master se asegura de que todos en el equipo, incluido él mismo, tengan la oportunidad de abrirse y hablar tanto de lo positivo como de lo negativo.
Tenga en cuenta que los participantes fuera del equipo no están invitados a la Reunión retrospectiva de Sprint. Sprint Retrospective se considera un pequeño entorno personal y emocional que permite a los miembros del equipo abrirse sin dudar y discutir los problemas que han enfrentado durante el último sprint.
Caja de tiempo
mejor limpiador de registro para windows 7
Se dice con razón que todas las Ceremonias de Scrum tienen un recuadro de tiempo y su recuadro de tiempo depende de la duración del Sprint. Dicho esto, para un sprint de dos semanas, es ideal tener una reunión de Sprint Retrospective durante 2 horas.
Sin embargo, si consideramos la Retrospectiva de Sprint como una oportunidad para comunicar, hacer una retrospectiva y comprometerse con las mejoras, está muy justificado dedicar suficiente tiempo a la reunión para evitar perder puntos de vista y conocimientos importantes.
Por lo tanto, es bueno marcar el tiempo de la reunión, pero no debe hacerse a costa de la comunicación y la progresión. Otro evento muy importante en Scrum es el refinamiento del backlog. Tomemos un breve momento para aclararlo.
Refinamiento de la cartera de pedidos
El Refinamiento del Backlog, que también se conoce como preparación del Backlog, es una reunión para discutir las historias de los usuarios en el Product Backlog que podrían ser parte del próximo Sprint. En una reunión de refinamiento del trabajo pendiente, todo el equipo se sienta junto y discute las historias de los usuarios, proporcionando así sus aportes.
La idea general es preparar el Product Backlog para el próximo Sprint y asegurarse de que las historias de usuarios estén listas para ser seleccionadas. La reunión de Refinamiento del Backlog se organiza durante el sprint 'n-1' para prepararse para los elementos que se seleccionarán en el sprint 'n'.
Conclusión
Con esto, llegamos al final de este tutorial sobre 'Scrum Events', que es imprescindible para leer uno. Scrum Events es, con mucho, el tema más importante y significativo de la serie Scrum.
En este tutorial, hemos discutido los cinco eventos de Scrum, es decir Sprint, Sprint Planning, Daily Standup, Sprint Review y Sprint Retrospective . Cada evento que no sea el standup diario tiene un ciclo regular por sprint, es decir, se realiza una vez en cada sprint.
Los eventos dan una idea de cómo se realizan las tareas en un entorno Scrum. Todos los eventos de Scrum son oportunidades de mejora, adaptación e inspección.
A continuación, se presenta un tutorial sobre 'Defect Triaging', que es una reunión formal en la que se discuten y clasifican todos los defectos del Sprint actual, es decir, se priorizan.
PREV Tutorial | SIGUIENTE Tutorial
Lectura recomendada
- Scrum Artifacts: Product Backlog, Sprint Backlog e Incrementos de producto
- Tutorial de JIRA Scrum Board: Scrum Handling con Jira para gestionar el Sprint
- Cuestionario en línea de Agile Scrum: Pon a prueba tu conocimiento de Agile Scrum
- Cómo ofrecer funciones de software de alto valor en un corto período de tiempo utilizando Agile Scrum Process
- Triaging de defectos en Scrum: cómo se organiza en una configuración de Scrum
- Oportunidad de trabajo independiente a tiempo parcial para expertos en selenio
- Funciones y responsabilidades del equipo Scrum: Scrum Master y Product Owner
- 10 mejores software de reloj de tiempo gratuito para el seguimiento del tiempo de los empleados