.

¿Conoces la diferencia entre historias de usuario y tareas?

Tal vez te parezca una pregunta fácil, pero ¿cómo explicarías tú la diferencia entre una historia de usuario y una tarea?

historias y tareas de usuario

Es habitual utilizar los conceptos “historias de usuario” y “tarea” en el ámbito de scrum, y la distinción parece obvia. Las historias de usuarios forman en Backlog del Producto, mientras que las tareas forman parte del Backlog del Sprint. Estas últimas se identifican durante la reunión de planificación del sprint, al descomponer las historias de usuario en tareas. Así se convierten en parte del Backlog de sprint.

Bueno, eso parece obvio: las historias de usuario van en el backlog del producto y las tareas van en un backlog del sprint. Pero, ¿Qué nos dice eso acerca de la diferencia entre ambas? ¿Cuál es la diferencia esencial entre los dos?

Diferencias entre historias de usuario y tareas

Tratemos de aclarar un poco más ambos conceptos:

Una historia de usuario suele ser una funcionalidad, algo visible para los usuarios finales. Desarrollar una historia de usuario es algo complejo, y normalmente requerirá la colaboración de varios miembros del equipo: un programador, alguien que la pruebe e incluso puede que un diseñador o un analista.

Sería muy raro que una historia de usuario sea plenamente desarrollada por una sola persona. Si esto sucede casi seguro una misma persona  estará desempeñando varias funciones.

Una tarea, por otra parte, es típicamente algo como diseñar, codificar, testar, probar, automatizar, etc. Al respecto parece que las tareas tienden a ser cosas hechas por una persona. Ya sé en lo que estás pensando… la programación por pares, por ejemplo. Bueno, en este caso aunque se dediquen dos personas, dos cabezas pensantes, se refiere únicamente a un tipo de trabajo.

Así pues, una buena manera de distinguirlas podría ser en base a los tipos de trabajo que implican. Es decir, las historias de usuario contienen varios tipos de trabajo (por ejemplo, programación, pruebas, diseño de la base de datos, diseño de interfaz de usuario, análisis, etc.) mientras que las tareas se limitan a un solo tipo de trabajo.

Y tú que piensas, ¿te parece una buena manera para diferenciarlas?

Saludos,

JLVG

Post relacionados

Implementar scrum: síntomas de que “algo” no marcha bien Hay muchas razones por las que Scrum puede no estar funcionando. Realizar una declaración de intenciones indicando que somos Ágiles, no basta para ser...
Ágil y Scrum no son lo mismo A menudo escucho referencias a Ágil y Scrum como si fueran la cosa, y eso no es correcto. Ágil es ampliamente conocido como un enfoque para el desarro...
La clave de scrum: cinco principios de trabajo La esencia de scrum se resume en cinco principios básico. Dos hacen referencia a la forma en la que se desarrolla el producto o la solución, y los otr...

Deja un comentario

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

AUTOR:  Juan Luis Vila Grau

PRINCE2® practitioner, Scrum Master (PSMI), EXIN Agile Scrum Foundation, AgilePM® Foundation, Management_of_Risk (M_o_R®) Foundation. and an enthusiastic of Agile management. Especialistas en técnicas participativas para la gestión de proyectos, y en el Enfoque del Marco Lógico (EML). Faclilitador certificado en el método LEGO® Serious Play®

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR