Artefactos
Product Backlog
El Product Backlog es una lista ordenada de todo lo que se sabe que tiene que tener el producto. Es la única fuente de requisitos del producto. El Product Owner es responsable del contenido, de la disponibilidad y del orden del Product Backlog.
El Product Backlog nunca está completo. Al inicio del desarrollo se empieza por los requisitos de los que se tiene mayor conocimiento y se entienden mejor. El Product Backlog evoluciona a la par que el producto y el entorno. Por tanto, el Product Backlog es dinámico, se encuentra en un proceso de constante cambio para identificar cuales son las necesidades apropiadas, competitivas y útiles. El Product Backlog existe mientras exista el producto.
El Product Backlog lista todas las funcionalidades, funciones, requisitos, mejoras, y correcciones que constituyen los cambios que habrá que hacer en futuras versiones. Los Product Backlog Items tienen descripción, orden, estimación y valor y, a menudo, también incluyen descripciones sobre como probar que están "Done".
Mientras se usa el producto y va ganando valor, el mercado va dando feedback, el Product Backlog se va haciendo cada vez más grande y se convierte en una lista cada vez más exhaustiva. Los requisitos no paran de cambiar, asi que el Product Backlog es un artefacto vivo. Los cambios en los requisitos de negocio, las condiciones del mercado y la tecnología pueden alterar el Product Backlog.
A menudo, varios Scrum Teams trabajan juntos en el mismo producto. En cualquier caso, solo se usa un Product Backlog para describir el trabajo a realizar en el futuro. En este caso se puede emplear un atributo que agrupe los Product Backlog Items.
El refinamiento del Product Backlog es el acto de agregar detalles, estimaciones y reordenar los Product Backlog Items. Este es un proceso continuo en el que Product Owner y el Development Team colaboran para detallar cada uno. Durante un reginamiento los Product Backlog Items se repasan y se revisan. El Scrum Team decide como y cuando se hace un refinamiento, pero normalmente no sobrepasa el 10% de la capacidad del Development Team. No obstante, los Product Backlog Items pueden ser modificados por el Product Owner o según su criterio.
Cuanto más alto se encuentra un Product Backlog Item, más claro y más detallado suele estar. Cuanto más claros están y con mayor detalle más sencilla y precisa puede ser la estimación. Los Product Backlog Items de los que se encargue el Development Team se refinan para que puedan quedar "Done" dentro del siguiente Sprint. Estos Product Backlog Items que pueden acabar "Done" en un Sprint se suelen considerar "Ready" para que puedan ser seleccionados en futuros Sprint Plannings. Los Product Backlog Items adquieren el grado de transparencia adecuado a través de sucesivos refinamientos.
El Development Team es responsables de las estimaciones. El Product Owner puede influenciar al Development Team ayudandoles a entender y seleccionando soluciones intermedias, pero quienes van a realizar el trabajo son los que dan una estimación al final.
Progreso hacia los objetivos
En cualquien momento, se puede ver el trabajo que queda por hacer. El Product Owner puede sabe el trabajo que queda por hacer al menos en cada Sprint Review. El Product Owner compara la cantidad de trabajo que queda con los Sprint Reviews anteriores para evaluar el progreso hacia la consecución de los objetivos. Esta información es transparente para todos los interesados.
Se usan varias técnicas para predecir el progreso, entre ellas destacan graficos del tipo burn-down, burn-up y gráficos apilados. Aunque este tipo de herramientas pueden ser útiles no remplazan la importancia del empirismo. En entornos complejos en los que se desconoce lo que puede ocurrir, solo se puede usar para tomar decisiones con vistas al futuro lo que ya ha ocurrido.
Sprint Backlog
El Sprint Backlog es el conjunto de los Product Backlog Items seleccionados para el Sprint, junto con el plan para entregar el Product Increment y completar el Sprint Goal. El Sprint Backlog es una estimación hecha por el Development Team sobre la siguiente funcionalidad que se puede construir como Product Increment y el trabajo que necesita para entregar esa funcionalidad "Done".
El Sprint Backlog representa todo el trabajo que el Development Team considera necesario para conseguir el Sprint Goal. Para asegurar la mejora continua, se incluye al menos un proceso de mejora de alta prioridad identificado en el Sprint Retrospective anterior.
El Sprint Backlog es un plan con suficiente detalle en el que los cambios en progreso se pueden entender en la Daily. El Development Team modifica el Sprint Backlog a lo largo del Sprint, y el Sprint Backlog emerge durante el Sprint. Este surgimiento ocurre porque el Development Team trabaja de acuerdo al plan y aprende sobre el trabajo que necesita para alcanzar el Sprint Goal.
Si se requiere nuevo trabajo, el Development Team lo agrega al Sprint Backlog. A medida que el trabajo se realiza, la estimación del trabajo restante se actualiza. Cuando hay elementos del plan que se consideran innecesarios, se eliminan. Solo el Development Team puede cambiar el Sprint Backlog durante el Sprint. El Sprint Backlog es visible, y debe ser una foto a tiempo real del trabajo que el Development Team tiene planeado completar durante el Sprint, y pertenece solo al Development Team.
Progreso del Sprint
En cualquier momento de un Sprint, el trabajo restante total del Sprint Backlog se puede consultar. El Development Team hace un seguimiento del trabajo restante total al menos en cada Daily para predecir la probabilidad de conseguir el Sprint Goal. Al hacer el seguimiento del trabajo restante a lo largo del Sprint, el Development Team gestiona su progreso.
Product Increment
El Product Increment es la suma de todos los Product Backlog Items completados durante el Sprint y el valor generado en todos los Sprints anteriores. Al final del Sprint, debe haber un Product Increment "Done", lo que significa que está en condiciones para ser usado y que reune todas las caracteristicas que ha definido el Scrum Team como "Done" tanto si el Product Owner decide sacar una nueva versión como si no. Un Product Increment es un paso más hacia una vision o una meta.
Transparencia en los artefactos
En Scrum se confía en la transparencia. Las decisiones para optimizar el valor y el control del riesgo se toman en función del estado de los artefactos. Siempre que haya transparencia completa, estas decisiones tendrán una base solida. Cuando la transparencia sea incompleta, las decisiones tendrán fallos, disminuirá el valor y aumentará el riesgo.
El Scrum Master debe trabajar con el Product Owner, el Development Team y los demás involucrados para saber si los artefactos son completamente transparentes. El Scrum Master es responsable de ayudar a todos a encontrar las prácticas más apropiadas para conseguir completa transparencia. El Scrum Master puede encontrar signos de falta de transparencia examinando los artefactos, buscando patrones, escuchando atentamente lo que se dice y detectando diferencias entre los resultados esperados y los obtenidos realmente.
El deber del Scrum Master es trabajar con el Scrum Team y la organización para incrementar la transparencia de los artefactos. Este trabajo normalmente incluye aprendizaje, convencimiento y cambio. La transparencia no se consigue de la noche a la mañana, pero es el camino a seguir.
Definición de "Done"
Cuando un Product Backlog Item o un Product Increment se describe como "Done", todo el mundo debe entender que significa "Done". Aunque esto pueda variar significativamente en cada Scrum Team, los miembros deben tener una idea compartida sobre lo que significa que el trabajo este completo y se asegure su transparencia. Esto es el Definition of Done para el Scrum Team y se usa para asegurarse de cuando el trabajo está terminado en un Product Increment.
La misma definiciones guían al Development Team al conocer cuantos Product Backlog Items pueden seleccionar durante un Sprint Planning. El proposito de cada Sprint es entregar Product Increments de funcionalidad potencialmente desplegable que encaje con la definición actual de "Done".
Los Development Teams entregan Product Increments cada Sprint. Este incremento es usable, asi que el Product Owner puede elegir, publicarlo inmediatamente. Si la definición de "Done" para un incremento es parte de las convenciones, estándares o guias de desarrollo de la organización, todos los Scrum Teams deben seguirlas como mínimo.
Si "Done" para un Product Increment no es una convención de la organización, el Development Team debe definir un Definition of Done apropiado para el producto. Si hay varios Scrum Teams trabajando en el sistema, todos los Development Team deben definir conjuntamente el Definition of Done.
Cada Product Increment se suma a todos los Product Increments anteriores y se prueba completamente, asegurando que toda la funcionalidad funciona junta.
Según los Scrum Teams maduran, sus Definition of Done irá siendo cada vez más extenso, incluyendo criterios para aumentar la calidad. Las nuevas definiciones, pueden no cubrir el trabajo realizado en anteriores Sprints. Cualquier producto o sistema debería tener un Definition of Done que fuera estándar para cualquier trabajo realizado.
Más información
La fuente de información principal es la Scrum Guide. En el sitio oficial de Scrum se puede encontrar información relacionada con Scrum así como todo lo necesario para poder certificarse en los diferentes roles definidos en la guía.