Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Incremento. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Incremento. Mostrar todas las entradas

martes, noviembre 28, 2023

Los artefactos Scrum: un enfoque unificado para el éxito del producto

 

Fuente: https://www.linkedin.com/feed/update/urn:li:activity:7132793258551726080/

He tenido el privilegio de guiar a numerosos equipos y empresas a través de implementaciones exitosas de Scrum. Una de las preguntas más comunes que encuentro es: "¿Cuál es el artefacto principal en Scrum: el Product Backlog, el Sprint Backlog o el Incremento?"

En una encuesta reciente en LinkedIn realizada por Scrum Inc., a manera de trivia, el 74 % de los encuestados, incluyéndome, indicaron que los tres artefactos son igualmente críticos para el éxito de Scrum. Esto se alinea con mi propia experiencia, donde he sido testigo de cómo cada artefacto desempeña un papel distinto pero complementario a la hora de impulsar el desarrollo de productos.

Pero qué pasa con quienes dieron respuestas diversas: el 13% estaba a favor del Product Backlog, el 6% optó por el Sprint Backlog y otro 6% creía que el Incremento era el más crucial. Este último parece tener sentido, después de todo, se trata del objeto final de la iniciativa de producto, ir creándolo en pequeñas partes, pero ni siquiera tuvo una mayoría favorecedora dentro de los artefactos individuales.

La ilusión de la separación: un nombre inapropiado

Si bien cada artefacto posee sus propios méritos disímiles, la verdadera magia de Scrum radica en su interacción sinérgica. El Product Backlog proporciona una visión general, el Sprint Backlog traduce esa visión en tareas procesables y el Increment manifiesta esas tareas en valor tangible.

Es definitivo: la noción de que un artefacto reina sobre los demás es un error. Es como afirmar que los cimientos, las paredes o el techo de una casa son más importantes que los demás. Cada componente juega un papel crucial en la integridad de la estructura. De manera similar, cada artefacto Scrum contribuye al éxito general del proceso de desarrollo del producto.

El Product Backlog: la brújula visionaria

El Product Backlog sirve como base de Scrum y representa la visión en constante evolución del producto. Es una lista ordenada de características, requisitos y mejoras que definen el estado deseado del producto. Continuamente refinado y actualizado, el Product Backlog guía los esfuerzos del equipo, asegurando que estén alineados con la dirección estratégica del producto.

El Sprint Backlog: la hoja de ruta táctica

El Sprint Backlog, derivado del Product Backlog, traduce la visión del producto en tareas procesables para un solo sprint. Es una lista dinámica de historias de usuario, errores, tareas y otros elementos de trabajo que el equipo se compromete a completar durante el sprint. El Sprint Backlog proporciona enfoque y claridad, lo que permite al equipo ofrecer valor tangible al final de cada sprint.

El Incremento: la expresión concreta del progreso

El Incremento, la culminación de cada sprint, representa el producto funcional que está potencialmente disponible para los clientes. Es la manifestación tangible de los esfuerzos del equipo, que muestra las capacidades en evolución del producto y permite que se proporcione retroalimentación temprana para una mejora continua. El Incremento sirve como un faro de progreso, motivando al equipo y validando la dirección del producto.

Adoptando la naturaleza entrelazada de Scrum

El verdadero dominio de Scrum radica en reconocer la interconexión de estos artefactos. No son entidades aisladas sino más bien elementos interdependientes que se entrelazan para formar el tejido del éxito de Scrum. Descuidar un artefacto inevitablemente afecta a los demás, lo que dificulta la capacidad del equipo para entregar valor de manera consistente.

Cuando aceptamos el significado colectivo de los artefactos Scrum, liberamos el verdadero potencial del framework. Normalmente, capacito a los equipos para que naveguen por las complejidades del desarrollo de productos con agilidad, enfoque y mejora continua. Juntos, el Product Backlog, el Sprint Backlog y el Increment forman la piedra angular del éxito de Scrum, lo que permite a los equipos ofrecer productos que deleitan a los clientes e impulsan el crecimiento y la innovación en las empresas.

En mi experiencia, los intentos de aislar un artefacto como el más crucial a menudo conducen a una comprensión incompleta del enfoque holístico de Scrum. Cada artefacto juega un papel indispensable y su integración armoniosa forma la base del éxito de las iniciativas Scrum.

Estos instrumentos no son meras herramientas; son el alma de Scrum, son las expresiones tangibles de una mentalidad ágil. Encarnan los principios de mejora continua, colaboración y adaptabilidad, transformando el proceso de desarrollo de productos en un viaje de experiencias y evolución continuas.

Entonces, la próxima vez que reflexiones sobre la importancia relativa de los artefactos Scrum, recuerda que no son entidades aisladas sino hilos interconectados que tejen el tapiz del éxito de Scrum.

viernes, marzo 13, 2020

Sobre el Incremento de Producto y el Refinamiento

Imagen de mohamed Hassan en Pixabay
Llegan algunas preguntas de colegas a mi buzón:

En el review:

¿A quién se le hace la entrega el incremento?

¿Este incremento debe ponerse en producción antes o después del review? (Si es antes, ¿qué pasa si el PO no lo avala o si es después, sería una tarea del siguiente Sprint?)

En el refinamiento:

¿En qué momento se contextualiza al equipo de trabajo sobre una funcionalidad o cambio sobre las funcionalidades pactadas? Es que entiendo que el refinamiento puede ser en cualquier momento entre todo el equipo.

¿Debería existir un día en el Sprint para refinar? ¿Eso no distrae al equipo de desarrollo?

Veamos algunas ideas al respecto:

Sobre la entrega del incremento

En la Revisión del Sprint se presenta el incremento del producto funcionando. El responsable de entregar este  incremento de Valor es el Equipo Scrum en pleno. ¿A quiénes se hace la entrega? A un grupo de interesados en el producto: patrocinadores, usuarios finales o consumidores, jefes, alta gerencia, personas de mercadeo y ventas, publicidad, operaciones u otras áreas que tengan que ver con el producto, entre otros. Tampoco se trata de una reunión “amplia” con mucha gente, se trata de algunos “interesados clave” invitados por el Dueño de Producto.

Esta es una reunión informal, no de seguimiento. El Dueño de Producto ya debe tener conocimiento previo de lo que se va a entregar, de su estado (solo se entrega producto terminado), de la calidad, etcétera. Después de todo, se supone que el Dueño de Producto está trabajando con el equipo de Producto de manera cotidiana. 

Dos aspectos clave de la reunión son que:

  • El Dueño de Producto explica qué elementos del backlog de Producto se han “Terminado” y cuales no se han “Terminado”; y
  • El Equipo de Desarrollo hace una demostración del trabajo que ha “Terminado” y responde preguntas acerca del Incremento;

Pero la reunión va más allá. Es en este momento cuando siempre sugiero volver a leer la guía de Scrum.

Además de lo que dice la guía de Scrum, Jorge ha publicado, entre otros, los siguientes artículos sobre el tema de la revisión del sprint:

[Agenda Scrum] Pasos para Realizar el Review o Revisión

Sobre el incremento

Imagen de Gerd Altmann en Pixabay
El incremento debe estar probado y funcionando, es decir, debe ser potencialmente distribuible, que se pueda poner en producción. Este incremento cumple la Definición de “Terminado” del Equipo Scrum. Debe representar en buena medida la meta del sprint. En la práctica, no concibo un Incremento de Valor que no aporte en un altísimo porcentaje hacia el cumplimiento del objetivo del Sprint.

Normalmente el incremento se pone en producción después de la Revisión. Es posible que sea antes pero es algo difícil en los entornos actuales. Este asunto de la puesta en producción tiene su propia complejidad porque, si no estamos en un entorno con cultura DevOps, donde haya automatización y herramientas, el incremento quizás se tenga que entregar a un equipo externo y este, a su vez, deberá pasar por uno o más comités de "Paso a Producción", entre otras restricciones y, las cosas así, el paso final puede tardar desde algunas horas, hasta algunos días o semanas. En cualquier caso, es el Dueño de Producto quien autoriza el paso, al menos por el lado del producto. Ya los demás comités y áreas harán lo suyo.

Importante: el objetivo del Equipo Scrum es entregar un incremento de producto en cada Sprint. Que tenga valor para el negocio, los usuarios o consumidores. Es decir, que genere retorno de la inversión, que haga ganar más dinero, que minimice costos, que mejore procesos, que evite más costo de la demora innecesario, entre otros aspectos. Si tu equipo no lo está logrando, es tiempo de una retrospectiva cuyo foco sea precisamente este de la no entrega de valor.

Sobre el refinamiento

Imagen de Gerd Altmann en Pixabay 
La contextualización sobre una funcionalidad o cambio en las funcionalidades pactadas se hace, precisamente, durante el refinamiento. Es el mejor momento.

El refinamiento es una tarea diaria del Dueño de Producto, con su equipo de producto, con los usuarios, con los interesados, con los consumidores finales, etcétera. Y, de tanto en tanto, durante el Sprint, se reúne con el equipo para contarles sobre las funcionalidades que vienen en los dos siguientes Sprints. 

Scrum nos sugiere que podemos usar hasta un 10% del tiempo del sprint para el refinamiento. Pero el equipo debe o debería estar completo con el Dueño de Producto a bordo. Para que todos vayan con el mismo conocimiento a las siguientes planificaciones y refinamientos. 

Sobre cuándo hacer el refinamiento

Se puede seleccionar un día del sprint o dos, dependiendo de la duración del mismo. Por ejemplo, sesiones de 2 horas o de 4 horas máximo vienen bien. Se recomienda que sean a mediados del sprint, nunca al principio y mucho menos al final. De hecho, el equipo puede tomar este tiempo como un "respiro" de sus tareas más complejas de desarrollo, así que puede ser beneficioso. Lo que no puede suceder es que se hagan tres o más reuniones de refinamiento en el sprint, que sean breves, eso no. Aunque es cuestión de experimentar, no creo que este último sea el camino, eso sí puede distraer al equipo, puede hacer que pierdan el foco continuamente, en fin, veo algunas desventajas en hacerlo así. Una o dos sesiones máximo.

Más sobre refinamiento en:

Purga ágil de producto
http://www.gazafatonarioit.com/2016/06/purga-agil-de-producto.html

Sobre el Backlog de Producto, el Refinamiento del Producto y el Rol del Dueño de Producto
http://www.gazafatonarioit.com/2017/06/sobre-el-backlog-de-producto-el.html

En este mismo Gazafatonario.