.

¿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

6 respuestas a “¿Conoces la diferencia entre historias de usuario y tareas?”

  1. Daniela Arango dice:

    pregunta estas tareas se estiman y la suma es el peso de la historia de usuario o solo se estima la historia de usuario?

    • Juan Luis Vila Grau dice:

      Hola Daniela,

      Lo que se estima son las historias de usuario; el esfuerzo y la prioridad. Esta actividad se lleva a cabo principalmente durante las sesiones de refinamiento del Backlog de Producto.

      Habitualmente las tareas en las que se descomponen las historias de usuario se estiman en horas, para una mejora planificación a nivel de trabajo del equipo. Tambien podemos hacerlo en puntos de historias en cuyo caso, lo que hacemos es dividir los puntos de historia entre el total de tareas.

      Por ejemplo, si hemos estimado que la historia de usuario vale 8 puntos de historia, y requiere de 4 tareas, cada tarea tendrá un valor de 2 puntos de historia. De esta manera podemos llevar un seguimiento diario de las tareas en base a los puntos de historia.

      Saludos,

      JLVG

  2. Cesar Lopez dice:

    Hola buenos dias,

    Tengo unas dudas que ojala me logren aclarar aca:

    1. Las historias de usuarios deberian ser finalizadas en un sprint siempre? o es posible que duren mas de un sprint?

    2. Hay historias de tipo investigativo, como las debo de definir (como tareas o como historias)? por ejemplo, si necesito revisar algun modulo que es nuevo para mi, etc.

    3. Si una historia de usuario es muy grande, por ejemplo, aceptar depositos bancarios, e internamente hay muchas tareas tecnicas (crear una tabla por ejemplo). Como las puedo descomponer? es licito terminar la historia en multiples sprint? que se debe de entender como producto entregable al final del sprint?
    3.

    • Juan Luis Vila Grau dice:

      Hola Cesar,

      Muchas gracias por escribir, y por leer nuestro blog.

      Veamos si puedo ayudarte con tus dudas. Junto a cada una de mis respuestas te sugiero un post que puede ayudarte a aclarar tus dudas.

      1. Las historias de usuario siempre deberían poder terminarse en un sprint. En caso contario pueden suceder dos cosas: 1) pueden dividirse en otras más pequeñas, o 2) el tamaño del sprint no es el adecuado al tipo de desarrollo que se está llevando a cabo.
      Dicho esto, tampoco resultaría de ninguna utilidad que un sprint este dedicado a una única historia de usuario (debido a su tamaño o complejidad). Imagina que sucedería si no fuésemos capaces de terminarla… ¡No entregaríamos nada al finalizar el sprint! (Saber más)

      2. Las “historias de usuario” que dedicamos a investigar, se conocen en los entornos Ágiles cómo spikes. Además de las historias de usuario y los spikes hay otros elementos que deberíamos considerar al montar el Backlog. (Saber más)

      3. Recuerda; las historias de usuario nos permiten enfocarnos en el usuario, su finalidad es desarrollar una funcionalidad, permitir hacer algo al usuario, y deben redactarse desde la perspectiva de los usuarios. “Hacer una tabla”, no es una historia de usuario, es una tarea que es necesario llevar a cabo para contribuir a solucionar una necesidad del usuario.

      Espero haber sido de ayuda.

      Saludos cordiales, y hasta la próxima.

  3. Ruben Nieto dice:

    He sido Administrador de Base de Datos y Gerente de Proyectos, actualmente certificado PMP. Tengo una pregunta , cómo y cuando se hace el diseño o modelo de la base de datos en la metodología SCRUM? Porque si lo voy haciendo a medida que voy desarrollando o programando los sprints la base de datos sería una versión parcial, y en cada sprint la iría refinando, pero para mi eso no sería práctico y no me conduciría a tener una estructura de base de datos íntegra, relacionada que me sirva para dar soporte a todo un proyecto. Debe entonces hacerse un diseño inicial de la base de datos a partir de las historias de usuario desarrolladas en el levantamiento de requerimientos?

    • Juan Luis Vila Grau dice:

      Hola Ruben,

      Gracias por escribir, y por favor disculpa la demora en mi respuesta.

      El Backlog de Producto no esta formado únicamente por Historias de Usuario, aparecen otro tipo de elementos: bugs, spikes, etc. Uno de los elementos que pueden aparecer son de carácter técnico y estos pueden incluir dicha base de datos.

      Cuando desarrollarla es una decisión del Product Owner (PO). Si bien es cierto que scrum establece que el PO sea un rol con perfil de negocio, en ocasiones por la complejidad de la solución es conveniente desdoblarlo en dos: 1 con un perfil de negocio, y otro con un perfil más técnico, tipo un arquitecto.

      Dicho lo anterior, es recomendable contar un Road Map a partir del cual desarrollar el Bcklog de Producto (permite una visión a medio plazo de la Releases y las Features). En mi opinión uno de los puntos débiles de scrum, es que arranca de un Backlog de Producto, pero dice poco sobre cómo se compone el mismo.

      En este línea de argumentación estoy de acuerdo contigo en la necesidad de mantener desde el inicio una estructura integral de la base de datos. Eso sí, para prepararla no hay que recurrir a ningún Sprint 0, ni tampoco debemos olvidar que el propósito de todo sprint es entregar valor al cliente.

      Espero haber contribuido a resolver tu duda.

      Saludos cordiales, y hasta pronto.

      JLVG

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

SAFe® 4 Certified Agilist, PRINCE2® Practitioner, Scrum Product Owner (PSPO I), 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