Manteniendo el Backlog y trabajando en equipo
Product Backlog de Scrum
En la definición más simple, el Product Backlog es simplemente una lista de todo lo que se debe hacer dentro del proyecto. Reemplaza los artefactos de especificación de requisitos tradicionales. Estos artículos pueden tener una naturaleza técnica o pueden ser centrados en el usuario, en forma de historias de usuario. El propietario del Product Backlog es el Product Owner. El ScrumMaster, el equipo de desarrollo y otros Stakeholders. Todos contribuyen a tener una lista de tareas amplia y completa.
Trabajar con un Backlog no significa que el equipo de desarrollo no tenga permiso para crear y usar otros artefactos. Los ejemplos de artefactos adicionales podrían ser un resumen de los diversos roles de usuario, descripciones de flujo de trabajo, pautas de interfaz de usuario, guiones gráficos o prototipos de interfaz de usuario. Sin embargo, estos artefactos no reemplazan el Backlog sino que complementan y detallan su contenido.
El Product Owner utiliza el Product Backlog durante la reunión de planificación del Sprint para describir los objetivos principales del equipo. El equipo de desarrrollo luego determina qué elementos pueden completar durante el próximo sprint.
Cada Backlog tiene ciertas características que lo diferencian de una simple lista de tareas pendientes:
Una entrada en el Backlog siempre agrega valor para el cliente
Las entradas en el Backlog del Producto de Scrum se priorizan y se ordenan en consecuencia
El nivel de detalle depende de la posición de la entrada dentro del Backlog
Todas las entradas son estimadas
El Backlog del producto de Scrum es un documento vivo
No hay elementos de acción o tareas de bajo nivel en el Backlog
Solo añadir entradas que agregan valor
Cada entrada en el Backlog debe tener algún tipo de valor para el cliente. Las entradas sin ningún valor para el cliente son un desperdicio puro y no deberían estar presentes de todos modos. El Product Backlog puede incluir entradas para explorar las necesidades del cliente o varias opciones técnicas, una descripción de los requisitos funcionales y no funcionales, el trabajo necesario para lanzar el producto y otros elementos, como la configuración del entorno o la corrección de defectos. Algunas tareas pueden no agregar valor directo a la funcionalidad. Sin embargo, podrían agregar valor aumentando la calidad o reducir incidentes a largo plazo.
Documentación en tiempo real
El Backlog del producto de Scrum se cambia a lo largo de todo el proyecto. Si es necesario, se agregan nuevos requisitos y los existentes pueden modificarse, definirse con más detalle o incluso eliminarse. Los requisitos ya no se congelan desde el principio. En su lugar, el conjunto final de requisitos dentro del Backlog también se desarrolla iterativamente, junto con el software resultante. Esto es diferente a la ingeniería de requisitos tradicional, pero permite maximizar el valor para el cliente y minimiza el esfuerzo de desarrollo.
Diferente nivel de detalles
Los requisitos del Backlog tienen una granularidad diferente. Solo aquellos requisitos que se implementarán durante uno de los siguientes sprints se definen con mayor detalle y todo lo demás es más grueso. La razón simple de esto es que no tiene sentido invertir tiempo y esfuerzo en la especificación de estos requisitos, ya que la mayoría de estos requisitos habrán cambiado de todos modos hasta que comience la implementación.
Sin tareas de bajo nivel
El Backlog no contendrá la información detallada de los requisitos. Idealmente, los requisitos finales se definen junto con el cliente durante el sprint. El desglose y la distribución de estos requisitos es responsabilidad del equipo de desarrollo.
El Product Backlog debe estar ordenado
Todas las entradas son priorizadas y posteriormente se agregan al Product Backlog. El Product Owner con la ayuda del equipo de desarrollo realiza la priorización. El valor agregado, los costos y los riesgos son los factores más comunes para la priorización. Con esta priorización, el Product Owner decide lo que se debe hacer a continuación.
Todas las entradas son estimadas
Todas las entradas dentro del Backlog deben estimarse de acuerdo con la definición acordada (por ejemplo, puntos de historia). Esta estimación se puede usar para priorizar las entradas en el Backlog y planificar lanzamientos.
Trabajar con el Backlog
El trabajo atrasado necesita atención y cuidado regulares; necesita ser administrado cuidadosamente. Al comienzo del proyecto, el equipo de desarrollo y el Product Owner comienzan por anotar todo lo que pueden pensar fácilmente. Esto es casi siempre más que suficiente para un primer sprint.
Después de esta configuración inicial, el Backlog debe mantenerse en un proceso continuo que comprende los siguientes pasos:
A medida que se descubren nuevos elementos, se describen y agregan a la lista. Los existentes se cambian o eliminan según corresponda.
Ordenar el Backlog. Los elementos más importantes se mueven a la parte superior.
Preparar las entradas de alta prioridad para la próxima reunión de planificación de Sprint
Re-estimar las entradas en el Backlog
El Product Owner es responsable de asegurarse de que el Backlog esté en buenas condiciones; se trata de un proceso colaborativo. Al usar Scrum, aproximadamente el 10% del tiempo total del equipo de desarrollo debe reservarse para mantener actualizado el Backlog (discusión, estimación, etc.).
El mantenimiento colaborativo del Product Backlog ayuda a aclarar los requisitos y crea una aceptación del equipo de desarrollo.
Artículo original: https://www.scrum-institute.org/The_Scrum_Product_Backlog.php