Historias vs Tareas… una sutil e importante diferencia

Supongo que con poco que estés metido en agilidad, en Scrum, etc., tendrás claras las principales diferencias entre Historias de Usuario y Tareas. Típicamente, vamos con el resumen, las Historias son un «qué» queremos, las Tareas un «cómo», las Historias son funcionalidad que aporta valor al usuario, las Tareas suelen ser aspectos técnicos, las Historias están en el Product Backlog, son responsabilidad del Product Owner, las Tareas están en el Sprint Backlog, y son responsabilidad del equipo, etc.
Bueno, y resumido lo anterior, voy con una diferencia entre historias y Tareas, que no he nombrado y que más que una diferencia es una buena práctica poco conocida: una Historia es algo en lo que por lo general… trabajan más de una persona. Y una Tarea es algo en lo que por lo general… trabaja una sola persona.
Una Historia de usuario implicará a varios perfiles, a varias personas: desarrolladores, Tester, diseñadores, etc. Y para organizar ese «cómo» hacer la Historia aparecen las Tareas. Y en las Tareas, lo normal, es que haya una relación 1 a 1 entre tarea y persona que la hace.

Una buena práctica visual para potenciar esta buena práctica

Lo que hacen algunos equipos, por desgracia no tantos como debiera, es usar avatares en pegatinas, ya sabes, cada persona tiene un dibujo, en una pegatina o similar, que le representa, con la idea de potenciar el buen uso de las tareas, te cuento. La buena práctica es que: a) sólo tienes una pegatina, que pegas en aquella tarea en la que estás trabajando y b) no puede haber más de una pegatina por tarea.
Con la parte a) de la anterior buena práctica potencias el importante y desconocido Swarming, evitar estar en más de una tarea (no lo resuelves del todo porque además deberías no abrir ninguna tarea hasta cerrar aquella en la trabajas ahora). Con la parte b) aseguras la regla de una persona una tarea.

Excepciones a la regla…

Las hay, pero que la excepción no sea la norma. Por ejemplo, una tarea que conlleve un pair programing… involucra a más de una persona. Así que, sí, habrá algunas tareas en las que hay dos cabezas y sólo dos manos, por lo que involucran a más de una persona.
Otras tareas que son excepción a esta regla: revisiones en grupo, reuniones, etc. Pero lo dicho, controla la granularidad de las tareas para llegar la la mayoría de las veces a «una persona una tarea».
Lecturas recomendadas, este post de Cohn, que no está mal.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

2 comentarios en “Historias vs Tareas… una sutil e importante diferencia”

  1. En nuestro caso empezamos poniendo imanes personalizados por cada miembro en el panel y así tenemos perspectiva de quien hace qué. El pair programming nos viene más infundado por el «terminar tareas» a modo de ayuda que por decidirlo de entrada, pero ya es una excusa para practicarlo… Lo que respecta a 1 tarea = 1 persona, tenemos una regla de «WIP personal en DOING» = 2. Espero que no sea lo que se conoce como SCRUM con peros…

Dejar un comentario

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