Este es el workflow que usamos en Ombu Shop para seguir las stories con Pivotal Tracker.
Objetivo
Atender todas las tareas pendientes sin que se nos escape nada. En base a la velocidad del equipo, tener una idea de fechas de entrega de cada story.
Prioridades
Se dividen por columnas. Current es más importante que Backlog. Backlog más importante que Icebox. Mientras más arriba en la columna se encuentre una story más prioridad tiene.
1. Toda mejora, bug o tarea debe figurar como una story en Pivotal
Bug: Comportamiento inesperado del sistema. Un error según lo especificado por una story previo.
Requester: La persona que pide la story. El requester es el que finalmente deberá aceptar la story.
Owner: La persona indicada para resolver la story. El requester elige al owner.
2. Antes de empezar, el owner debe estimar la tarea
Para estimar se usan los palitos horizontales a la derecha de la story. Más palitos, más complicado. Los bugs no se estiman.
Ejemplo de una story:
3. Una vez que el owner empieza debe darle Start a la tarea
Esto sirve para calcular la velocidad de nuestro equipo.
4. Una vez que termina debe darle Finish
Esto pondrá a la story lista para darle Deliver.
5. Una vez que se sube a producción debe darle Deliver
Solo se le dá Deliver cuando está en producción.
8. Recién ahí el requester debe darle Accept o Reject
El requester va a ser siempre el responsable de aceptar la story. Si uno le dá Reject hay que ser lo más claro y específico posible para decir por qué no se acepta.
Si la story fue aceptada y estaba relacionada con un cliente, avisarle. Eso queda a cargo del requester
Si la story fue rechazada, el owner va a tener que darle Restart (Ver #3) una vez que vuelva a trabajar sobre la tarea.