Cuáles son los artefactos de Scrum para organizar las tareas

By | 03/10/2016

Los artefactos de Scrum (prefiero llamarlos herramientas) que nos permiten organizar y visualizar nuestro plan de trabajo son muchos, pero aqui comentaré tres.  La lista de trabajos pendientes, la lista de trabajos que estamos ejecutando en un Sprint y la gráfica Burndown que nos muestra cómo vamos dentro del Sprint.

Backlog de Producto

Esto es la lista de todas las tareas que son necesarias realizar sobre el producto. El detalle de esta lista es a un nivel más bien elevado para comprenderlo y lograr el arranque del trabajo.

El dueño del producto o  Product Owner es el responsable de recopilar las nuevas funcionales que son requeridas y esperadas sobre el software manteniendo un continuo contacto con el usuario para priorizarlas.  Cumplir las expectativas del usuario es de suma importancia y la calidad de vínculo entre el Product Owner y el usuario permitirá el correcto ordenamiento de estas prioridades.

En la lista del backlog debe, además de ubicarse el orden, declararse posibles dependencias y los objetivos funcionales que se desean cumplir.

Debemos recordar que trabajamos con scrum para cubrir la incertidumbre del proyecto y su complejidad por lo que no es conveniente un detalle minucioso, este será completado cuando este por ingresar al sprint. Seguramente muchas de estas tareas serán descartadas o modificadas, por lo que no es útil dedicarle a la especificación mayor tiempo del necesario.

Backlog del Sprint

Definidos los objetivos deseados para un sprint, se incluyen en él las tareas que otorgan la funcionalidad que se pretende lograr. Para esto, a través de la reunión de planeamiento que se realiza antes de comenzar con el sprint, se establecen las tareas que deberán cumplimentarse y en las que el equipo se compromete. En esta reunión de planeamiento participa el ‘dueño del producto’ y el resto del team; en ella se discuten las tareas con mayor detalle a fin de establecer si, acorde a la capacidad del team, este puede comprometerse a realizarlas.

Un sprint es un periodo bastante corto, por ejemplo dos a tres semanas. Los periodos cortos permiten visualizar mejor el avance del proyecto y que el equipo se comprometa en ellas. Diferente es correr una gran maratón a correr en pequeños tramos. Lograremos entregas continuar evitando dejar todo para el último.

Volviendo a la lista del backlog, esta deberá indicar el requisito, el puntaje final otorgado en la planing y el desglose que ha realizado el mismo equipo sobre cada historia. El puntaje utiliza la serie de Fibonacci  1,2,3,5,8,13. A mi me gusta decir que en realidad se trata de un grado de dificultad estimado por el conocimiento colectivo, es un valor que nos da una idea de la carga de trabajo y nos dice además que si el puntaje es alto seguramente la historia debería desglosarse en varias.

Cada una de las tareas (stories) dentro del sprint debe ser pequeña de modo tal que ante un bloqueo no obstaculice (demasiado) la ejecución de otras y mantener un seguimiento más simple de cada una.

Durante el transcurso del sprint debe mantenerse cuidado en actualizar el estado y manifestar en las reuniones de stand up los problemas que puedan retrasar o bloquear la tarea. En estas reuiones se menciona lo que se hizo ayer, lo que se hará luego y lo que está impidiendo avanzar. Lo mas importante aquí es detectar posibles bloqueos sobre el trabajo para que el scrum master apoyado por el team intente resolver estos problemas.

Al finalizar el sprint se deberían entregar todas las historias y pasar a la reunión de la demo con el dueño del producto, quién dará su visto bueno. Una vez pasada la historia por la demo esta podrá cambiar su estado para un siguiente paso.

Para el backlog se utiliza un tablero (Scrum Taskboard).

Este tablero debe reflejar de forma rápida el estado de todas las stories dentro del spring. En una sola mirada deberíamos poder saber cómo vamos con el proyecto. Existen numerosas herramientas para tal fin, pero aquí lo que importa es el propósito, podríamos usar cualquier tablero en el que coloquemos en columnas cada una de las tareas según su estado cumplirá. Claro que usar herramientas nos ayudará mucho con las estadísticas.

jira-scrum-board

 

Grafica Burndown (Burndown charts)

diagrama-burn-down

Al ir presentando las stories comprometidas al usuario, estas se van marcando como completadas por lo que nos van quedando menos tareas pendientes por cumplimentar. Es por ello el nombre de esta gráfica, una vez que que se han completado todos los compromisos la línea de pendientes de esta gráfica llega a cero.

Son muchas otras las herramientas que utiliza Scrum, aquí solo me detuve en algunas que nos permiten llevar nuestra lista de trabajos. Estas deben ir acompañadas con el resto de elementos del proceso, reuniones, definicion de roles, etc.

 

Compartir esto:

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *