Archivo de la categoría: Taiga

Q: “Me gustaría controlar el avance del sprint con las tareas cerradas”

Taskboard

Post publicado también en el blog de Kaleidos

Entre los usuarios de Taiga y soporte, suelen surgir debates y preguntas muy interesantes sobre cómo usar la herramienta y si encaja o no con la filosofía y objetivos del producto.

Os traigo hoy uno sobre control del avance del sprint:

“La gráfica actual del sprint (Sprint Burndown Chart en Taiga) no nos vale porque solo aparecen los puntos quemados cuando se cierran todas las tareas de una User Story con lo cual durante la primera semana del sprint da la impresión de que no se ha avanzado nada, aunque se vayan cerrando tareas de las diferentes User stories.

Los requerimientos que tenemos del scrum master es trabajar con la filosofía de tarea como medida de lo que hace el equipo y avance real (incluso trabajan con horas)”

Este Scrum Master, sigue el libro. La guía oficial de Scrum en su sección de Sprint Backlog habla de:

Monitoring Sprint Progress

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Un desarrollo más en profundidad muy conocido es como lo cuenta Henrik Kniberg en su libro “Scrum desde las trincheras” (aquí original) y también habla de contabilizar el trabajo pendiente del sprint.

En los dos casos hablan de preguntar al equipo cuánto trabajo cree que les queda pendiente de cada historia, sea en puntos, sea en horas, sumarlo y ver lo que queda.

Lo que es propio de la implementación que hace este equipo, es contabilizar el avance sumando las horas de las tareas que se han terminado.

El avance de las tareas en una historia no te da información real del avance del sprint, porque si somos fieles a Scrum, en la demo solo se pueden mostrar historias terminadas, no ‘casi’ terminadas.
Una gráfica de tareas pendientes en el sprint que muestra que estamos al 90% de sprint terminado, pero realmente solo tenemos 2 de 8 historias terminadas (25%), puede dar una falsa sensación de tranquilidad. Y evita algo muy importante, que es centrarse en terminar historias.

Además de esto, llevar el control por tareas, y además en horas, hace que haya que estimarlas al inicio del sprint con el correspondiente esfuerzo.
Y el problema de calcular el ‘quemado’ del sprint a partir de una estimación inicial, es que no contempla los cambios y problemas que nos vayamos encontrando. Y si la solución es reestimar las tareas si ‘explotan’, solo hace aumentar la burocracia.

Cuando allá por el 2010 intentamos una aproximación fiel contando las horas pendientes en el sprint, enseguida nos dimos cuenta que era una microgestión que aportaba poca información que no nos diera ya el panel. Los bloqueos que puedas tener en una historia se pueden detectar igual en el daily: “Llevas tres días con esta historia de 2 puntos. Hay algún problema?” , es mucho más efectivo.

En mi opinión, si se quiere tener una gráfica de “Sprint Burndown” con más detalle que la actual de Taiga, haría como recomienda la literatura, preguntando al equipo en el daily “¿Cuántas horas calculas que te quedan de tu historia?”. Es mucho más realista y no depende de tareas terminadas. Y con esa información haría una gráfica para colgar en el tablón o en un doc compartido.

Si se quiere automatizar, en la versión liberada esta semana de Taiga, se puede crear un custom field para ir poniendo esa cantidad de horas pendientes en ese campo y se podrá sacar una gráfica de manera fácil.

Tema muy interesante, sin duda. Volveremos sobre el control detallado de los tiempos, internamente llamado “El dilema del Time-Tracking”, en otras preguntas que nos hacen.

Etiquetado , , ,

¿Qué es una historia épica?

Epic User Story

La semana pasada se lanzó una pregunta dentro del equipo muy interesante:

¿Qué es una historia épica?

La pregunta venía motivada, porque es una petición muy recurrente entre los usuarios de Taiga.

Mi respuesta en un correo fue esta:

Una épica, según los que lo inventaron, es una historia grande y muy indefinida que se va a dividir.
La Epic, tiene que desaparecer, en sus historias más pequeñas.

Historias de usuario que recuerdo deben seguir el patrón: INVEST
​remarcando la I de “​Independent” y la V “Valuable”

En mi opinión la EPIC puede tener sentido y ser visible, incluso con otro color, pero más reflejando ese estado de proto-historia, de idea sin madurar, de historia ‘gorda’… que como algo que vaya a ser parte de la estructura de la aplicación.

Preguntas que pueden surgir:

“Realmente todas las pequeñas historias no subirían solas a producción, están relacionadas”
Aquí puede ser útil el concepto de Epic, como agregador de us. Es decir, tenemos el concepto de módulo. Pero cuidado, esto generalmente es muy confuso de gestionar en cualquier plataforma, incluso en papel.
Hace al cliente muy difícil prioririzar, hay muchas dependencias.
Los tags aquí harían un buen trabajo, creo.

“Los prototipos de UX son para la historia grande, la epic”:
Eso es un problema de documentación, o de que el UX hace los prototipos antes de dividir, o que las divide back, con el sesgo que tiene, o todo a la vez.
Si las historias son independientes deberían tener su prototipo clarito. No rebuscar en el prototipo 17.0.3 y ver qué botón es la us que estamos mirando ahora.

“Pero las EPICs no son formas de agrupar los grandes bloques de un proyecto, por ejemplo API, Front Web, Front Movil, …”
No, eso se podrían llamar módulos o similar, pero esos módulos no tiene valor ‘per se’.

La palabra epic, la usa Mike Cohn en su libro, así que es ‘oficial’ 🙂

Busco en google y me encuentro este precioso artículo de Mike Cohn de este año hablando de todo esto!
http://kcy.me/1cu9f

que es una copia de éste del 2011
http://kcy.me/1cu9p

Espero que ayude. 🙂

Después de este correo tuvimos una reunión para definir:

“Qué sería una historia épica en Taiga”

Una de las máximas necesidades que tiene el usuario de una épica, es servir de base para el primer análisis y puede estar acompañada de un buen hilo de conversaciones, diagramas, wireframes e incluso prototipos. Y esa información no la queremos perder.
Si dividimos la épica en historias más pequeñas, ¿dónde metemos toda esa información previa?

Por lo que el formato final en Taiga, será una historia de usuario, que se marcará como ‘épica’ en sus propiedades, y se distinguirá de las demás en el backlog por el color.
La épica y sus historias derivadas estarán relacionadas y así podremos acceder a toda la información del análisis previo si fuera necesario.

Como bonus, esa agregación de historias en la épica, nos da la posibilidad de hacer un seguimiento de ver cuántas historias están hechas, y así tenemos algo parecido a un módulo o conjunto de historias que tenemos agrupadas.

Como bonus++, esas historias que salen de la épica, puede que no estén en el mismo proyecto, puede que estén en un subproyecto.
Esto abre la posibilidad de tener un proyecto ‘base’ que se llama ‘Dirección General’ una épica que se llama ‘Campaña de Navidad’ e historias de esta épica en el subproyecto de ‘Dpto. de Marketing’ como ‘Anuncios en Televisión’. Pudiendo seguir el avance de todas estas historias desde la épica.

¿Qué os parece? 🙂

Foto gracias a Kulawat Wongsaroj de su post Visualizing the Big Picture of your Agile Project

Etiquetado , , ,