Introducción al Product Backlog

Tanto el Product Backlog como los Sprint Backlog (1 diferente por cada sprint) los tenemos documentados en detalle en el apartado de Projects, con formato de tabla Kanban.

Este Kanban se organiza de la siguiente manera.

---

Organización del Kanban

Nos hemos organizado por columnas en el Kanban, donde clasificamos las tareas/historias de usuario dependiendo del estado en el que cada una de ellas se encuentre dentro del ciclo de trabajo en cada momento.:

1. Columna de Backlog: aquí mostramos qué historias de usuario del Product Backlog vamos a desempeñar.
2. Columna de To Do: aquí están desglosadas todas las tareas atómicas a completar para llegar a los objetivos.
   • Las tareas están numeradas de manera que la tarea X.2 depende de la tarea X.1.
   • Es esencial completar las tareas X.1 lo antes posible.
   • Las tareas de distintas historias de usuario son independientes en la medida de lo posible; es decir, se procurará que X.1 y Y.1 sean tareas independientes. Así, se facilita el trabajo en paralelo.
3. Columna de In progress: cuando alguien comienza una tarea, se la asigna, la mueve a esta columna y comienza a desarrollarla.
   • Cualquier persona que quiera ayudar en una tarea en proceso, hablará con el equipo asignado en ese momento y se incorporará al desarrollo cuando proceda.
   • Cualquier tarea que se pase del tiempo estimado en la columna de In Progress, se notificará al resto del equipo.
4. Columna In Review: aquí se colocan las tareas pendientes de revisión (preferiblemente, el revisor será alguien del equipo que no haya trabajado en el desarrollo de la tarea).
   • Si el revisor considera que la tarea está terminada, lo pasa a Completed.
   • Si no, se añade un comentario con lo que falta, falla o no cumple los requisitos y se mueve a In Progress.
5. Columna Completed: aquí están las tareas completadas. A no ser que cambie la especificación de una mecánica o funcionalidad, estas tareas están cerradas y son inmutables.
   • El programador añadirá comentarios en las tareas completadas (complementarios a los comentarios de los commits) para aclarar detalles de implementación cuando lo encuentre conveniente.

---

Técnicas de estimación

Véase el documento de estimación.

Prioridades de las historias de usuario

Para cada tarea e historia de usuario, usamos el criterio "MoSCoW" para clasificar su prioridad:

• Must Have: prioridad máxima, tarea esencial el desarrollo del proyecto. O historia de usuario clave en el MVP.
• Should Have: prioridad alta, tarea que debería completarse en ese Sprint. O historia de usuario secundaria en el MVP.
• Could Have: prioridad menos alta.
• Would Have: prioridad baja (por ejemplo, aspecto gráfico o ajustes de diseño).

De esta manera, los desarrolladores de Feudalia buscarán terminar primero todas las tareas de prioridad "Must Have" y luego seguir completando por orden de prioridad el resto de tareas.

Tamaño de las tareas

Usamos el método de estimación por clasificación en tallas de camiseta.

Las tallas de camisetas que usamos son:

• S y XS para tareas simples de creación de nodos, animaciones sencillas...
• M para tareas más elaboradas.
• L y XL para tareas elaboradas que implementan funcionalidades nuevas (programar mecánicas, diseñar elementos de juego...).

Tiempo estimado por tarea

En el apartado de Estimated añadimos el número de días de trabajo continuo que esperaríamos dedicar a una tarea. No hay problema en que el estimado no se cumpla estrictamente, pero sí que son una referencia para que el equipo identifique si una tarea está estancada y excede considerablemente el estimado.

Para estimar esta medida usamos lo siguiente:

• Usamos la escala de Fibonacci (1, 2, 3, 5, 8...) para estimar el tiempo de cada tarea.
• Procuramos que las tareas sean cortas y sean abarcables en menos de una semana.