Curso Scrum: Artefactos y/o documentos Scrum - backlog - Parte 5
Artefactos y documentos Scrum
Sigue de cerca las siguientes partes del Curso Scrum:
Los artefactos y/o documentos Scrum - resultados/productos de nuestras actividades de gestión - están diseñados para aumentar la transparencia de la información relacionada con la entrega del proyecto y proporcionar oportunidades de inspección y adaptación.
Hay seis artefactos de Scrum:
- Cartera de productos: Una lista ordenada de todo (también conocido como historias) que podría ser necesario en el producto final
- Cartera de pedidos de Sprint: Artículos seleccionados (historias) de la cartera de productos que se entregarán a través de un Sprint, junto con la Meta Sprint y los planes para la entrega de los artículos y la realización de la Meta Sprint.
- Incremento: El conjunto de todos los artículos de la Cartera de Productos completados hasta el final de un determinado Sprint
- Definición de "Hecho": La comprensión compartida de lo que significa para una obra ser considerada completa
- Monitoreo del progreso hacia una meta: La medición del desempeño y el pronóstico para todo el proyecto.
- Monitoreando el progreso de Sprint: La medición del rendimiento y las previsiones para un solo Sprint
Los puntos 5 y 6 pueden parecer más bien actividades, pero se consideran artefactos en la Guía Scrum, y por lo tanto los explicaremos como tales. Puedes imaginarte su salida (información de seguimiento, tablas de quemado, etc.) como los artefactos reales y estos dos ítems como actividades continuas (como la preparación de la cartera de productos) o parte de los eventos Scrum (parte de Sprint Review y Daily Scrum).
Artefacto 1: Cartera de productos
El Product Backlog es una lista ordenada de todo lo que puede ser necesario en el producto final del proyecto, es decir, partes del producto final esperado (una lista de deseos). Todos los elementos se describen en un lenguaje comercial sencillo (no técnico) y todos ellos son presentables a todas las partes interesadas. Cada requerimiento y cada cambio en el proyecto se reflejará en la cartera de productos.
La cartera de productos está cambiando y mejorando dinámicamente; nunca está completa. No esperamos hasta que la Cartera de Productos esté completa para comenzar a entregar los artículos; el primer Sprint puede iniciarse tan pronto como la Cartera de Productos se muestre en un futuro cercano.
El Propietario del Producto establece una serie de factores para determinar el valor de cada artículo para el negocio; el retorno de la inversión es generalmente uno de los factores. Todos estos factores se resumirán en un valor (importancia) y esto se muestra con cada posición.
Los artículos de la cartera de pedidos se ordenarán en función de su valor, de forma que cuanto más alto sea un artículo, antes será entregado por el equipo de desarrollo. Como los artículos situados en la parte superior de la cartera de pedidos se entregarán antes, también serán más detallados y claros en comparación con los artículos inferiores.
La siguiente figura muestra un ejemplo de los artículos de la cartera de productos presentados en varias tarjetas.
Cada artículo de la cartera de pedidos también tiene un presupuesto de trabajo. Estos estimados son hechos únicamente por el Equipo de Desarrollo, y se usan en comparación con la capacidad del Equipo de Desarrollo en un solo Sprint, para determinar el número de elementos que serán seleccionados para ese Sprint en particular. Se puede añadir mucha información adicional a cada elemento para ayudar al equipo de Scrum a tomar el control.
Esta figura muestra el tipo de información disponible para un único ítem de la Cartera de Productos en una herramienta Scrum típica. Este es también un buen ejemplo de una herramienta Scrum.
Tómese su tiempo para estudiar este diagrama ya que contiene mucha información. Estas son las diferentes partes de esta caja de diálogo:
- Nombre de la historia - "El Cuarto Ejemplo de la Historia" en esta figura.
- Descripción de la historia - Criterios de calidad, explicación del alcance, etc. Es útil almacenar toda la información relevante aquí, para que todo el equipo de Scrum pueda tener acceso a ella.
- Alertas - Alertas opcionales personalizadas se pueden establecer aquí.
- Fecha de vencimiento: también puede agregar fechas de vencimiento personalizadas opcionales y utilizarlas para realizar un seguimiento de las historias. Por ejemplo, ha decidido a mitad de la Sprint (parte de la planificación detallada) terminar una historia determinada en una fecha determinada, y ha fijado esa fecha aquí.
- Complejidad - Es un campo usado para definir la naturaleza de la historia y puede ser usado para la Planificación Sprint. Por lo general, cuanto más compleja sea una historia, más incierta será su estimación.
- Estimación - Este es el volumen estimado de la historia determinado por el Equipo de Desarrollo.
- Categorías - Cuando hay muchas historias atrasadas, es una buena idea categorizarlas para facilitar el acceso y el mantenimiento. Esto puede actuar como un PEP normal (plan de la estructura del proyecto) en proyectos tradicionales en los que se agrupan los entregables.
- Asignaciones - La historia puede ser asignada a cualquier persona del equipo. Sin embargo, todo el equipo de Scrum seguiría siendo responsable de ello.
- Rastreador - Usted puede registrar el tiempo que gasta en cada historia para análisis adicionales, refinamiento de estimaciones, facturación, etc.
- Colores - Puede establecer diferentes colores para cada historia para diferenciarlos visualmente en el tablero Scrum. Esta es una forma de agrupar/categorizar elementos.
- Tareas - Puede dividir la historia en tareas (planificación detallada) y hacer un seguimiento por separado. Se calcularía un progreso simple para cada historia basado en el número de tareas completadas. Las tareas son creadas por el Equipo de Desarrollo.
- Registro de cambios - El historial de los cambios realizados en esta historia (como la creación de tareas) se almacenaría para su uso posterior.
- Archivos adjuntos - Puede adjuntar documentos relevantes y utilizar el software también como herramienta de gestión de documentos scrum.
- Comentarios - Cada miembro del equipo Scrum puede dejar comentarios y colaborar con otros. Este campo es muy útil y siempre pedimos a los miembros del equipo que lo utilicen.
- Campos adicionales: si no le bastan todos los campos anteriores, puede definir sus propios campos personalizados y utilizarlos para otras necesidades de planificación y control.
Un uso importante de las herramientas Scrum es la colaboración. Las características de colaboración son más importantes cuando el equipo de Scrum no está ubicado en un mismo lugar y las formas tradicionales de colaboración no son posibles.
La siguiente figura muestra un ejemplo de la cartera de productos creada en una herramienta Scrum en línea. El Propietario del Producto ha identificado las historias, pero las estimaciones aún no están hechas (signos de interrogación en el lado derecho de las filas).
Situación actual de la muestra:
- Historias identificadas - sí
- Estimaciones - no
- Plan Sprint - no
- Tareas - no
- Tareas y relatos realizados - no
El equipo de Scrum debe añadir detalles, estimaciones y pedidos a los artículos de la cartera de productos a lo largo de todo el proyecto, lo que se denomina preparación de la cartera de productos. No debe consumir más del 10% del tiempo del Equipo de Desarrollo.
La cartera de productos se crea más sobre la base de la discusión que de la documentación. Los artículos de la cartera de productos (también conocidos como historias) deben ser fáciles de entender para las partes interesadas no técnicas.
La siguiente figura muestra la muestra de la herramienta Scrum después de la adición de las estimaciones.
Situación actual de la muestra:
- Historias identificadas - sí
- Estimaciones - sí
- Plan Sprint - no
- Tareas - no
- Tareas y relatos realizados - no
La cantidad total de trabajo en esta muestra es de 234 puntos. Es común dividir las historias grandes (como la décima historia de la muestra, que se estima en 100 puntos) en dos o más historias más tarde.
A veces varios equipos de Scrum trabajan en el mismo proyecto. La cartera de productos es una representación del alcance del producto final y, por lo tanto, sólo debería haber una cartera de productos, sin importar cuántos equipos de Scrum estén trabajando en el proyecto.
Artefacto 2: Cartera Sprint
El Sprint Backlog se crea durante el evento de Planificación Sprint que es el primer evento en un sprint. Durante el evento de planificación Sprint, el equipo de Scrum colabora en la creación del Backlog Sprint, que consiste en lo siguiente:
- Una serie de elementos seleccionados de la parte superior de la cartera de productos, en función de su trabajo estimado y de la capacidad estimada del equipo de desarrollo.
- El Objetivo Sprint, que ayudará a describir el significado real de los elementos y dirigirá los esfuerzos del Equipo de Desarrollo.
- Un plan detallado para la entrega de los artículos y la realización de la Meta Sprint durante el Sprint
El retraso de Sprint se congela después de que la Planificación Sprint y el Equipo de Desarrollo se concentren en entregar un Incremento de "Hecho" basado en este plan. La declaración "el Sprint Backlog está congelado" significa que los artículos (historias) en el Sprint Backlog no pueden ser agregados o removidos durante el Sprint. Sin embargo, puede ser necesario renegociar, justificar o borrar algunos de los artículos durante el Sprint, lo cual debe hacerse en presencia del Propietario del Producto. El plan detallado que normalmente no está completo al final de la Planificación Sprint se irá completando a medida que continúe el Sprint.
La siguiente figura muestra el proyecto de muestra en el tiempo de planificación de Sprint: un nuevo Sprint, llamado "El primer Sprint" está definido con fechas de inicio y fin, y el equipo de Scrum está ahora listo para seleccionar los elementos de la parte superior de la cartera de productos que se asignarán a este Sprint.
Situación actual de la muestra:
- Historias identificadas - sí
- Estimaciones - sí
- Plan Sprint en curso
- Tareas - no
- Tareas y relatos realizados - no
Suponga que la capacidad estimada de los Sprints es de 50 puntos. En este caso, todo lo que podemos elegir para el Sprint se muestra en la siguiente figura
Situación actual de la muestra:
- Historias identificadas - sí
- Estimaciones - sí
- El plan Sprint está casi terminado
- Tareas - no
- Tareas y relatos realizados - no
Ahora tenemos cuatro ítems con un estimado de 44 puntos. No podemos añadir el siguiente artículo de la Cartera de Productos, porque tiene 40 puntos y sólo tenemos alrededor de 6 puntos libres en nuestra capacidad Sprint. Es común que el Propietario de Producto en tales casos reordene la cartera de pedidos; por ejemplo, para llevar la Sexta Historia de Muestra por encima de la Quinta Historia de Muestra, y así podemos agregarla a la Cartera de pedidos de Sprint (siguiente figura).
Situación actual de la muestra:
- Historias identificadas - sí
- Estimaciones - sí
- Plan Sprint - sí
- Tareas - no
- Tareas y relatos realizados - no
La siguiente figura muestra los elementos de Sprint, junto con un resumen y una tabla de quemado.
Situación actual de la muestra:
Historias identificadas sí
- Estimaciones - sí
- Plan Sprint - sí
- Tareas - no
- Tareas y relatos realizados - no
Esta pantalla actúa como un tablero de control y podemos usarlo para planificar y hacer un seguimiento de los elementos. En la siguiente figura, por ejemplo, algunas de las posiciones de la parte superior de la lista se desglosan en tareas. La mayoría de las herramientas Scrum están equipadas con características de colaboración que son especialmente útiles para los equipos remotos (comentarios por ejemplo).
Situación actual de la muestra:
- Historias identificadas - sí
- Estimaciones - sí
- Plan Sprint - sí
- Tareas - sí (sólo para algunas historias)
- Tareas y relatos realizados - no
A medida que avanzamos por el Sprint, algunas tareas y elementos se hacen y más elementos se detallan.
Situación actual de la muestra:
- Historias identificadas - sí
- Estimaciones - sí
- Plan Sprint - sí
- Tareas - sí
- Tareas y relatos completados - sí (algunos de ellos)
Las herramientas de Scrum usualmente actualizan la tabla de quemado a medida que avanzamos por el Sprint.
Es común visualizar los elementos Sprint en una tabla de estilo Kanban y la mayoría de las herramientas Scrum soportan esta vista; la siguiente figura muestra un ejemplo.
Las columnas de la tabla Kanban son personalizables y podemos añadir tantos pasos como sea necesario, como diseño, desarrollo, pruebas e integración. Cada carta se movería de izquierda a derecha para indicar visualmente su estado actual. También podemos incorporar la buena práctica de Kanban, limitando el trabajo en curso, limitando el número de cartas permitidas en cada columna. Al aceptar esta limitación, aceptamos centrarnos en un número reducido de historias en cada momento y terminarlas en lugar de empezar nuevas historias.
Las columnas mínimas en una tabla Kanban son:
- Qué hacer - Cosas que esperan ser iniciadas
- Hacer - Cosas que estamos haciendo ahora mismo (normalmente limitadas en número)
- Hecho - Cosas que se han completado
Artefacto 3: Incremento
Un Incremento es la suma de todos los artículos completados de la Cartera de Productos al final de un Sprint. Cada Incremento debe ser "Hecho", y debe ser liberable. El Propietario del Producto puede o no liberar un cierto Incremento, pero debe ser liberable (enviable).
La siguiente figura muestra cómo el número de historias en la cartera de productos disminuye Sprint por Sprint, a medida que aumenta el número de características en los incrementos.
Tenga en cuenta que el concepto de Incremento es acumulativo: cada Incremento también contiene las características de los anteriores.
Artefacto 4: Definición de "Hecho"
Debe haber una comprensión compartida de lo que significa para un trabajo ser "Hecho". Esta definición de "Hecho" debe ser discutida y acordada por el equipo de Scrum al principio del proyecto para que los futuros incrementos sean liberables.
Cuando varios equipos de Scrum trabajan en un mismo proyecto, puede que no sea posible utilizar la misma definición de "Hecho" para todos los equipos, ya que pueden estar trabajando en elementos de distinta naturaleza. En tal caso, cada equipo Scrum definirá su propia definición de "Hecho" y entregará sus artículos basándose en esa definición. Sin embargo, la integración de esas definiciones de "Hecho" debería ser capaz de crear un incremento potencialmente liberable a nivel de proyecto.
Artefacto 5: Monitoreo del progreso hacia una meta
Hasta ahora, hemos utilizado la tabla de quemado para visualizar el progreso del desarrollo durante un Sprint. También puede utilizar un gráfico de quemado para visualizar el progreso de todo el proyecto y esto se denomina gráfico de quemado del proyecto.
El Propietario del Producto es responsable de monitorear el progreso de todo el proyecto hacia su meta. Esto debe hacerse al menos una vez por cada revisión de Sprint. El Propietario del Producto determina la cantidad de trabajo restante y lo compara con el trabajo restante de los sprints anteriores, y pronostica la fecha de finalización del proyecto. Todas las partes interesadas deberían tener acceso a esta información.
La tabla de quema del proyecto muestra la cantidad de trabajo restante, en lugar de la cantidad de trabajo completado; por lo tanto, la línea para el rendimiento real disminuye a medida que avanzamos, y cuanto más rápido baja, ¡más felices seremos!
El eje vertical muestra la cantidad de trabajo (que es una suma de todos los estimados para cada ítem en la Cartera de Productos), y el eje horizontal muestra la cantidad de tiempo transcurrido desde el inicio del proyecto o el número de carreras pasadas.
Normalmente añadimos otra línea para presentar la distribución uniforme del volumen de trabajo a través del número estimado inicialmente de sprints. Esta línea actúa como nuestro progreso planificado y se utilizará para comparar con nuestros valores reales.
En el cuadro anterior, podemos esperar que el proyecto se complete antes de lo previsto inicialmente.
Artefacto 6: Monitorizando el progreso de Sprint
Además del monitoreo realizado para todo el proyecto, también debemos monitorear el progreso de cada Sprint a lo largo de su vida. Esto es responsabilidad del Equipo de Desarrollo y debe hacerse al menos una vez por día.
Esta información se utiliza para calcular la probabilidad de alcanzar la Meta Sprint y completar todos los ítems de la Cartera Sprint.
La información de progreso de Sprint puede ser representada por una tabla de quemado, y esta tabla puede ser parte del tablero Sprint, donde todos pueden ver.
Deja una respuesta