Cómo podemos definir un buen backlog?

 
Un Backlog es un activo importante para cualquier equipo Agile. Se vuelve aún más importante para una empresa que entienda el valor que de él puede retirar. Desde requisitos bien organizados, con calidad, transparencia sobre el producto y su estado del producto, un medio de actualización para todo el equipo y empresa. Estos son los mayores outputs que se retiran de un backlog de calidad.

Un Backlog se puede definir como una lista de requisitos que, dependiendo de la proximidad a la estrategia o la implementación. Puede ser escrito en sagas, epics, stories o tasks (el requisito más granular para la implementación).
Un Backlog debe ser independiente en el sentido de que el equipo de desarrollo, el Product Owner, el Scrum Master deben ser totalmente libres para organizarlo. Con base en él, crean un entendimiento común sobre el producto, las historias, su prioridad y contribuición para el producto.
 

Pero si estamos en una organización de productos interdependientes, ¿cómo puede un backlog ser independiente?

Sí! Puede ser independiente en el sentido en que permita al equipo de desarrollo, producir valor en cada Sprint. Aceptar para implementar las historias que cumplan la definición de Ready (DoR). Por lo tanto, el Backlog es independiente respondiendo a las cuestiones de cómo implementar, pero es dependiente en el sentido en que contribuye a la realización de los requisitos de un nivel superior, orientados a la concreción de la visión estratégica de la empresa.

Negociable y estimado

Un backlog debe ser negociable y para ello, debe haber sido anteriormente estimado. Todo el equipo debe conocer las dependencias para la implementación, la contribución individual, para el producto, de cada Epic, Funcionalidad y Story.


(adsbygoogle = window.adsbygoogle || []).push({});

Viable y realizable

Un backlog debe ser viable y realizable, en el sentido de que el equipo de desarrollo, manteniéndose estable en su capacidad, y dentro del período de tiempo de la release, lo logra realizar.
El equipo de desarrollo, para entregar el backlog, durante la estimación de esfuerzo, debe considerar requisitos funcionales, requisitos no funcionales, legales y de conformidad vigentes en la empresa (incluyendo calidad, seguridad, etc). Este consejo está muy relacionado con los conceptos y la relación entre Minimum Viable Product y Minimum Possible Product.

Probado y comprensible en el idioma del cliente

Se deben incluir y estimar las tareas de prueba en todos los niveles del backlog. Como parte de la definición de Done, en cada nivel de requisitos (saga, epic, funcionalidad, story y task) las tareas de prueba y aceptación deben ser consideradas.
Un backlog debe ser comprensible en el idioma del cliente. Asumiendo que el Product Owner expresa los deseos del cliente, será la voz de aclaración de cada story frente al equipo de desarrollo.
La condición previa para una buena planificación de Sprint es que el Product Owner debe tener el backlog preparado / listo y cada story debe cumplir los criterios de aceptación y cumplir con la definición de Ready para entrar en el sprint.
Resumiendo las premisas para un backlog de calidad:

  • Tener contenido de alta calidad escrito en cada nivel de requisitos conocido en el backlog;
  • Refinar regularmente las historias para que el atasco esté estimado;
  • Tener el backlog organizado por prioridad para, en cualquier momento, tener contenido listo para entrar en Sprint.

Beneficios de un backlog de alta calidad

Hay evidentes beneficios en tener un baclog con contenido de alta calidad y bien organizado:

  • Claridad – en torno a lo que se tiene que construir, mapeando cada requisito en la imagen global del producto. Un backlog debe dar esa claridad en una perspectiva de 360 ​​grados: para el equipo y fuera del equipo. Lo que queremos, adónde vamos, donde estamos.
  • Responsabilidad – el equipo debe creer que es capaz de entregar, y que los procesos montados ayudan a la entrega del producto y no constituyen impedimentos.
  • Progreso mensurable – un backlog estimado, respetando y repitiendo todos los ciclos de ceremonias, corresponde a una forma creíble de medir el progreso:
    • Tamaño del backlog
    • Velocidad
    • Burn-down
    • Bugs no corregidos (Escaped Defects)
    • Commit% Ratio
    • Porcentaje de historias aceptadas por el Product Owner
    • Porcentaje de modificación de requisitos


    (adsbygoogle = window.adsbygoogle || []).push({});

Uncategorized

Leave a Reply