Logotipo de Shackleton


Siguiendo con el esquema de metodologías ágiles, el próximo paso se basa en ir completando el tablero con épicas, historias y tareas (en ese orden).

- Épicas: Requieren más tiempo de ejecución que la duración de un sprint (valor)
- Historias: Su ejecución es posible en el tiempo de duración de un sprint (valor)
- Tareas: Posible en el tiempo de duración de un sprint (no-valor directo) Después de entender estas tres variables, procederemos a explicar el funcionamiento de la pila de proyecto y sprints.

Pila de proyecto y sprints:
La pila de Proyecto (project backlog) es el corazón de shapeAgile. Es donde empieza todo. La Pila de Proyecto es, básicamente, una lista priorizada de requisitos, o historias, o funcionalidades, o lo que sea. Cosas que el cliente quiere, descritas usando la terminología del cliente, y por supuesto siempre pensando en “cosas que el cliente quiere” las llamamos historias, o a veces simplemente elementos de la Pila.

La pila de sprint es una herramienta que nos ayudará a validar prioridades (nuevas historias), subdividir historias muy grandes (épicas) en historias. Más tarde, podremos verificar si esas historias están listas (dependencias). Toda historia contiene una serie de elementos sin los cuales carecería de orden y estructura:

- ID: Un identificador único, simplemente un número auto-incremental. Esto nos permite no perder la pista a las historias cuando cambiamos su nombre.
- Prioridad: el ratio de prioridad que el Project Owner y/o el cliente da a esta historia. Por ejemplo, 10 o 150. Más alto = menos importante. Utilizamos una escala de 1 a 200, siendo: 1: máxima prioridad. 200: mínima prioridad. Usamos esta escala y no de 1 a 5, por ejemplo, porque si le das a una historia prioridad 1, es muy incómodo si posteriormente decides que algo es más importante ¿Qué prioridad le daríamos a ese nuevo elemento? ¿Prioridad 0? ¿Prioridad -1?
- Estimación inicial: la valoración inicial del AgileTeam acerca de cuánto trabajo es necesario para implementar la historia, comparada con otras historias. La unidad son “puntos de historia” y usualmente corresponde a “días-persona ideales”.
- Nombre:Una descripción corta de la historia. Por ejemplo, “Ver tu historial de compras” o “Poder obtener información sobre X en tiempo real sin tener que preguntar a nadie”. Suficientemente claro como para que el Project Owner (y el AgileTeam, claro) comprenda con claridad de qué estamos hablando, y para distinguirla de las otras historias. Normalmente, 2 a 10 palabras.
- Cómo probarlo:Una descripción clara de cómo se demostrará esta historia en la Demo al final del Sprint. Se trata, esencialmente, de una simple especificación de un test: “Haz esto, entonces haz lo otro, y entonces debería ocurrir aquello”. O simplemente demostrar que has conseguido que “eso” funcione. Además, existen dos diagramas que nos serán de gran utilidad para calcular el progreso de nuestro proyecto.
- Burn Down:Gracias al diagrama Burn Down podemos ver gráficamente si el progreso que llevamos es el adecuado. Este diagrama relaciona el número de tareas con la duración del proyecto.
- Release Plan: es un grafico que pone en contraste el número de horas de un sprint con el tiempo de duración de ese sprint, normalmente en días.