Self-Learning
>
Scrum
|
3 min de lectura
8 recomendaciones para que tu Sprint Review no sea una demo
Descubre todo lo que debes saber sobre la Sprint Review y cómo hacer para que tu Sprint Review no se convierta en una demo.
Por qué Sprint Review y no demo
La razón de ser de la de la reunión de revisión del sprint es que el incremento pueda ser examinado. En muchas empresas que utilizan Scrum, es una confusión habitual llamar erróneamente Demo Sprint al Sprint Review. Este evento de Scrum no se trata de una "demo" donde los desarrolladores muestran (o cuentan) a los stakeholders lo que hicieron sino un espacio para inspeccionar el incremento y recibir feedback producto de la interacción con él.
Muchas empresas desaprovechan el poder creativo de Scrum y los stakeholders asisten solo a una demostración para asegurarse que se hizo lo prometido y luego todos se van a seguir con lo suyo. Pero no. En la Sprint Review bien hecha los stakeholders utilizan el incremento, no sólo escuchan o ven pantallas. El feedback se da sobre lo experimentado.
Veamos algunas ideas de diseño de agenda para evitar que la Sprint Review se convierta en una demo.
Modelo de agenda
1. ¿Para qué?
Comienza compartiendo el objetivo de la reunión. En este caso, inspeccionar el resultado del Sprint y determinar futuras adaptaciones. Por lo general las personas olvidan esta segunda parte y creen que solo vienen a ver qué se hizo.
2. Ver lo mismo
El Product Owner presenta el Objetivo de Sprint y los developers o desarrolladores el Definition of Done (DoD) utilizado durante el Sprint para que todos estén viendo la misma película.
3. Expectativas
El Product Owner presenta un resumen sobre qué se hizo y qué no se hizo durante el Sprint y recuerda cómo cada Product Backlog Item a presentar está relacionado al Objetivo del Sprint.
4. Empatía
El Scrum Master presenta cuáles fueron los desafíos y aprendizajes a los que el Equipo Scrum se enfrentó durante este periodo de tiempo.
5. Uso
Los stakeholders utilizan el Incremento de Producto creado por el Equipo Scrum, no solo miran pantallas. Proporcionan feedback que cualquier miembro del Equipo Scrum va registrando. Cualquier persona puede sugerir mejoras a partir de la observación de uso del Incremento de Producto.
6. Más allá
Los equipos de producto deben ir más allá de lo que plantea Scrum y revisar conjuntamente los outcomes en producción (principalmente datos cuantitativos). Por ejemplo: conversion rate, churn rate, lifetime customer value, etc.
7. Cómo seguir
Basándose en el feedback identificado y en los insights de los datos, se discuten y determinan modificaciones al Product Backlog a partir del feedback relevado.
8. Cierre
Se realiza una breve retrospectiva sobre esta Sprint Review en busca de mejoras a futuro.
Certified Scrum Master (CSM)
- Filosofía y funcionamiento:Valores y principios, Equipo, desarrollo iterativo e incremental con Sprints, Sprint Backlog, Product Backlog y PBIs, refinamiento, criterios de aceptación, y más.
- El campo de acción del Scrum Master y las cuatro disciplinas de su trabajo cotidiano.
- Las diferencias entre el liderazgo Ágil y el tradicional para adaptarse mejor a los cambios y liderar desde el servicio.
- Estimación Relativa de PBIs o Historias de Usuario, planificación evolutiva de desarrollo ágil de productos digitales y métricas basadas en outcomes.
--
44 min de lectura
Scrum es un marco de trabajo liviano donde los equipos crean soluciones a problemas complejos en entornos cambiantes. Uno de los beneficios de Scrum es el trabajo en iteraciones cortas llamadas Sprints, con determinadas responsabilidades de Equipo (Scrum Master, Scrum Product Owner y Desarrolladores), pero también existen otros secretos de su éxito que veremos a continuación.
4 min de lectura
Extracto del libro "Scrum y algo más: un framework y muchos aprendizajes para creadores ágiles" de Martín Alaimo.
12 min de lectura
Descubre qué hacen el Product Owner, el Scrum Master y los Developers para lograr proyectos exitosos con Scrum.
4 min de lectura
Los desarrolladores (developers) de Scrum poseen competencias multidisciplinarias que los hacen más atractivos que los programadores que se dedican exclusivamente a escribir código. Estas son algunas diferencias desde el punto de vista de Scrum.
5 min de lectura
Descubre las 4 reuniones o eventos de Scrum para que tus equipos trabajen de una forma más ágil.
10 min de lectura
En Scrum, la Sprint Planning es el evento (reunión) que ocurre al inicio de cada Sprint y donde se reúne a todo el equipo Scrum para planificar el Sprint. Conoce más detalles de esta reunión y descubre las otras reuniones de Scrum para que tus equipos trabajen de una forma más ágil.
10 min de lectura
La Daily Scrum es uno de los eventos de Scrum que informalmente se suele conocer como una de las reuniones que suceden dentro del Sprint. Vemos más en detalle sus características principales y qué tener en cuenta a la hora de participar en una.
9 min de lectura
La Daily Scrum o Scrum Diario es la reunión dentro del Sprint de Scrum donde históricamente se respondían 3 preguntas: ¿Qué hice ayer?, ¿Qué voy a hacer hoy? y ¿Qué impedimentos tengo o tuve para hacer mi trabajo? Veamos qué se está haciendo diferente ahora.
7 min de lectura
Aprende sobre las características más importantes de la Sprint Review en Scrum.
6 min de lectura
¿Sabes qué es una Sprint Retrospective? Descubre todo lo que debes saber sobre la Retrospectiva de Scrum y aprende por qué es importante.
3 min de lectura
Los equipos ágiles que utilizan Scrum trabajan en iteraciones cortas llamadas Sprint. El Sprint es uno de los cinco eventos de Scrum.
3 min de lectura
El Sprint Backlog es uno de los tres artefactos o herramientas de Scrum junto con el Product Backlog y el Incremento. El Sprint Backlog refleja el plan del Sprint y su propósito es lograr el Objetivo del Sprint.
10 min de lectura
¿Qué es el Product Backlog y cómo se organiza? Recomendaciones a la hora de ordenar PBIs y hacer refinamientos.
5 min de lectura
Existe una gran diferencia entre el proceso predictivo de seguimiento y control de proyectos que funciona en contextos estables y el proceso empírico o adaptativo de seguimiento y control que incorpora la complejidad de la realidad. Un ejemplo de este paradigma adaptativo son los Sprints de Scrum, donde se practica la inspección y adaptación.
8 min de lectura
El Modelo en Cascada o Waterfall Model de Winston Royce se popularizó luego de ser adoptado por el Departamento de Defensa de los Estados Unidos en los años ochenta. En 2001 surgió el Agile Software Development Manifesto proponiendo otra manera de desarrollar software, pero no es hasta el año 2010 que el Departamento de Defensa decide cambiar a la agilidad. En el 2012, el Standish Group publicó su análisis anual de gestión de proyectos donde menciona que las aplicaciones de software desarrolladas a través del framework ágil tienen tres veces la tasa de éxito del método en cascada tradicional y un porcentaje mucho menor de demoras y sobrecostos.
6 min de lectura
En el año 2000, Dave Snowden, nos introduce al Marco o Modelo Cynefin en donde explica la complejidad y los distintos tipos de dominios de complejidad. Estos dominios de complejidad son: el dominio simple, el dominio complicado, el dominio caótico, el dominio desordenado y el dominio complejo. El Marco Cynefin o Modelo Cynefin nos ayuda a entender cual es el contexto de complejidad en donde es apropiado aplicar Scrum que es cuando nos encontramos dentro del dominio complejo. Dentro del dominio complejo nos enfrentamos a resultados inciertos, y es aquí donde Scrum, como marco de control empírico, nos proporciona innovación, reducción de fallos, comunicación, experimentación e iteración para lograr resultados y así poder actuar, inspeccionar y adaptar las prácticas emergentes de un equipo de trabajo. Scrum es un marco de trabajo que nos permite encontrar prácticas emergentes en dominios complejos, como la gestión de proyectos de innovación.
3 min de lectura
La gestión de proyectos tradicional enfrenta la triple restricción del lado del alcance, para luego determinar el tiempo y costo. Para la mirada de la agilidad, en cambio, se parte del tiempo y costo, para por último determinar el alcance.
