jueves, 30 de septiembre de 2021

Understanding Sprint Review Meetings

El Sprint Review ES una reunión de colaboración donde se busca “feedback” de todos los presentes, fundamentalmente para crear transparencia sobre el incremento de producto y permitir la adaptación del “Product Backlog” y/o el “Release Plan” si fuera el caso.

El Sprint Review NO ES una reunión donde se aprueban los “Product Backlog Items” terminados. Si sucede de esta manera podría indicar falta de colaboración entre el “Product Owner” y el equipo de desarrollo durante el Sprint.

Durante el Sprint y en forma continua el equipo de desarrollo y el “Product Owner” trabajan de manera conjunta para lograr un incremento de producto al final del Sprint. Durante este proceso, muchos de los ítems fueron validados según los criterios de terminado llegando a esta reunión con la confianza de lo que se ha logrado.

Si en lugar de ello, el proceso implica entregar al equipo de desarrollo las historias refinadas al inicio del Sprint y pedirles que se revise al final del Sprint, se está implementando SWAT, sacrificando la colaboración y el empirismo en favor de un proceso y documentos funcionales, yendo en contra de los valores ágiles.

El objetivo principal del Sprint Review es la actualización del Product Backlog en base al feedback de los participantes

El Sprint Review es importante para incorporar los acontecimientos del negocio en la elaboración/actualización del “Product Backlog” y considerar aquello que es importante para el negocio. El “Product Backlog” es un artefacto vivo y es una salida de esta reunión. El “Product Backlog” adaptado considera el “feedback” de los interesados, los últimos acontecimientos de negocio así como el alineamiento estratégico hacia los objetivos de negocio del producto.

Finalmente, hay que destacar que, El equipo de desarrollo tiene un compromiso con el objetivo del Sprint, no con la cantidad de ítems seleccionados en el Sprint Backlog, mucho menos con un determinado consumo de horas. De manera que, las métricas que bien pudieran incorporarse deben reflejar el impacto de negocio y la satisfacción de los clientes del uso del producto, mismas que sirven para considerar perspectivas que ayuden en la definición/re-definición del “Product Backlog”.

Espero que te haya parecido útil e interesante este artículo.

No olvides visitarme en mi perfil de GitHub: https://github.com/era5mx.

………….

Quiero man.tener.me informado: Seguir en Twitter @eldavid_oficial https://twitter.com/eldavid_oficial

Regálame un ME GUSTA. Y si eres solidario, COMPARTE para que otros puedan aprovecharlo.

No hay comentarios.:

Publicar un comentario

Nota: sólo los miembros de este blog pueden publicar comentarios.