El product backlog
El trabajo pendiente del producto es una lista emergente y ordenada de lo que se necesita para mejorar el producto. Es la única fuente de trabajo emprendida por el equipo Scrum. Los elementos de trabajo pendiente de producto que puede ser hecho por el equipo de Scrum dentro de un Sprint se consideran listos para su selección en un evento de planificación de Sprint. Por lo general adquieren este grado de transparencia después de las actividades de refinación.
El refinamiento de Backlog del producto es el acto de descomponer y definir aún más los elementos de trabajo pendiente del producto en artículos más pequeños y precisos.
Esta es una actividad en curso para agregar detalles, como una descripción, un pedido y un tamaño. Los atributos a menudo varían con el dominio del trabajo. Los desarrolladores que realizarán el trabajo son responsables del tamaño. El Propietario del Producto (Product Owner) puede influir en los desarrolladores ayudándoles a entender y seleccionar mejores alternativas.
Compromiso: Objetivo del producto (Product Goal), que describe un estado futuro del producto que puede servir como objetivo para el equipo Scrum contra el cual planificar.
El product Backlog y los objetivos
El objetivo del producto se encuentra en el trabajo pendiente del producto (Product Backlog). El resto del trabajo pendiente del producto surge para definir “qué” cumplirá el objetivo del producto.
Un producto es un vehículo para entregar valor. Tiene un límite claro, partes interesadas conocidas, usuarios o clientes bien definidos. Un producto podría ser un servicio, un producto físico o algo más abstracto.
La pila del Sprint (Sprint Backlog)
El trabajo pendiente de Sprint se compone del objetivo sprint (por qué), el conjunto de elementos de trabajo pendiente de producto seleccionados para el Sprint (qué), así como un plan accionable para entregar el incremento (cómo). El trabajo pendiente de Sprint es un plan por y para los desarrolladores.
Es una imagen muy visible y en tiempo real del trabajo que los desarrolladores planean realizar durante el Sprint para lograr el Objetivo Sprint. Por lo tanto, el Sprint Backlog se actualiza a lo largo del Sprint a medida que se aprende más. Debe tener suficientes detalles para que puedan inspeccionar su progreso en el Scrum Diario.
El impacto del incremento
Si Scrum tuviera que ser reducido a una sola cosa, sería a entregar una pieza de software terminado cada Sprint.
El incremento es la suma de todas las tareas, casos de uso, use stories y cualquier elemento que se haya desarrollado durante el Sprint y que será puesto a disposición del usuario final en forma de software al final del mismo.
RECORDEMOS LA CONSTANTE ENTREGA DE VALOR EN DEVOPS.
El Sprint Goal es el único objetivo para el Sprint. Aunque el objetivo de Sprint es una compromiso de los desarrolladores, proporciona flexibilidad en términos del trabajo exacto necesario para lograrlo. El Objetivo Sprint también crea coherencia y enfoque, animando al equipo de Scrum a trabajar juntos en lugar de en iniciativas separadas. El objetivo de Sprint se crea durante el evento Sprint Planning y, a continuación, se agrega el Trabajo pendiente de Sprint.
A medida que los desarrolladores trabajan durante el Sprint, tiene en cuenta el objetivo de Sprint. Si el trabajo resulta ser diferente de lo que esperaban, colaboran con el propietario del producto para negociar el alcance del Trabajo pendiente de Sprint dentro del Sprint sin afectar al objetivo de Sprint. Incremento (Increment)
Un incremento es un paso de hormigón hacia el Objetivo del Producto. Cada incremento es aditivo a todos los incrementos anteriores y verificando a fondo, asegurando que todos los incrementos funcionen juntos. Para proporcionar el valor, el incremento debe ser utilizable. Se pueden crear varios incrementos dentro de un Sprint.
La suma de los incrementos se presenta en la REvisión Sprint apoyando así el empirismo. Sin embargo, un incremento puede ser entregado a las partes interesadas antes del final del Sprint.
La revisión de Sprint nunca debe considerarse una puerta para liberar valor. El trabajo no se puede considerar parte de un incremento a menos que cumpla con la Definción de Hecho.
La Definición de Hecho (DoD)
La Definición de Hecho es un descripcción formal del estado del incremento cuando cumple con las medidas de calidad requeridas para el producto,
En el momento en que un elemento de trabajo pendiente de producto cumple con la definición de hecho, se crea un incremento. La definición de hecho crea transparencia al proporcionar a todos una comprensión compartida de qué trabajo se completó como parte del incremento. Si un elemento de trabajo pendiente de producto no cumple con la definición de hecho, no se puede liberar, ni siquiera presentar en la revisión de Sprint.
En su lugar, vuelve al trabajo pendiente del producto para su consideración futura. Si la definición de hecho para in incremento forma parte de los estándares de la organización, todos los equipos de Scrum deben seguirla como mínimo. Si no es un estándar organizativo, el equipo de Scrum debe crear una definición de hecho adecuada para el producto. Los desarrolladores deben ajustarse a la definición de hecho.
Si hay varios equipos de Scrum trabajando juntos en un producto, deben definir y cumplir mutuamente con la misma definición de hecho.