como-dividir-historias-de-usuario-en-tareas

Cómo dividir historias de usuario en tareas


Las historias de usuario son los elementos en los que dividimos todo el trabajo que hay que hacer en un proyecto o producto en Scrum. Esencialmente contienen el qué hay que construir. En la planificación el equipo Scrum elige cuales de las historias de usuario más importantes va a desarrollar en las semanas que dure el sprint. Además de decidir hasta dónde puede llegar, el equipo debe salir con un plan detallado. Será el cómo lo va a lograr. Para ello normalmente lo que hace el equipo es dividir historias de usuario en tareas.

Dividir historias de usuario en tareas

Gran parte del éxito del Sprint dependerá de la atención y dedicación que se le dé a este proceso. Sin embargo, el paso de dividir las historias de usuario en tareas es complicado para muchos equipos. Requiere experiencia, conocimiento y decisión.

dividir historias de usuario en tareas

Desgraciadamente no hay un procedimiento mágico infalible para dividir historias de usuario en tareas. Dependerá de muchos factores: cómo de grandes son estas historias de usuario, cómo de complejo es el proyecto o producto, experiencia del equipo Scrum, si el producto es interno o externo, etc. Tampoco hay una manera (o yo por lo menos no la conozco ni me la imagino) de enseñar a partir tareas. Es como una habilidad blanda. Se trata de habernos peleado con ello mil veces, y a base de golpes, aprendes a detectar tareas ocultas, identificar riesgos técnicos, anticipar problemas, y hacer las preguntas pertinentes para crear un buen plan.

Las tareas deberían ser pequeñas (entre medio día y 2 días como mucho). Así facilitaremos el seguimiento y la estimación por parte del equipo. En la medida de lo posible, las tareas además deberían poder probarse de forma individual. Esto es, no deben depender de que otra tarea esté terminada para poder probarse.

Primer análisis técnico

El proceso de partir en tareas comienza normalmente con un primer análisis y diseño técnico. Ayuda en este caso dibujar los diferentes componentes software (interfaces de usuario, piezas de lógica de negocio, servicios, orígenes y destinos de datos, etc.) y sus relaciones (cómo interactúan entre ellos). No hace falta que sea un diagrama de clases, estaría más cerca de un diagrama de flujo de datos. Un ejemplo podría ser éste:

Con el diagrama delante será muy sencillo identificar todas las tareas necesarias para crear los componentes que falten o modificar los existentes y así obtener una nueva funcionalidad.

Este diagrama además será de gran ayuda para detectar las posibles dependencias. Por ejemplo, en el caso de que algún componente de los identificados deba desarrollarlo otro equipo. También es de gran ayuda para los desarrolladores a la hora de repartirse el trabajo. Si están claros los límites, cada componente lo podría desarrollar una persona distinta.

Tareas adicionales

Pero no todas las tareas necesarias para terminar una historia de usuario son técnicas. Habitualmente hay muchas tareas adicionales. Los equipos suelen olvidan estas tareas sistemáticamente. Para identificar este tipo de tareas ocultas es muy útil que el equipo cuente con un checklist que les sirva de recordatorio. En los equipos cuento normalmente con 2 checklist.

Una de ellas es un acuerdo de trabajo fundamental en Scrum, la definición de hecho o definition of done (DoD). En esta lista están todas las condiciones necesarias que se deben dar para que una historia de usuario se dé por finalizada. Normalmente por cada criterio de la DoD surgirá una tarea.

La otra checklist que utilizo es una checklist genérica, que contiene tareas típicas dentro de todas o casi todas las historias de usuario de todos los equipos. Aunque sea una lista genérica, conviene adaptarla a cada equipo para eliminar lo que no aplica y añadir algún que otro punto que sea específico del equipo. Para que os hagáis una idea, os pondré un ejemplo:

  • Interfaces y métodos necesarios, incluir además los stubs temporales para trabajar entre back y front por ejemplo.
  • Unit testing, de integración, pruebas de aceptación (automáticas o no), pruebas exploratorias, tests de regresión.
  • Requisitos no funcionales: Rendimiento, escalabilidad, mantenibilidad, seguridad…
  • Revisiones de código.
  • Refactors/Rebuilds necesarios + pruebas asociadas necesarias.
  • Corrección de errores.
  • Reparación de incidencias del análisis de código estático.
  • Preparación de la demo (datos de prueba, scripts…).
  • Actualizar la documentación (técnica, javadoc, de usuario…).

Acabando

Así es como yo aconsejo a los equipos cómo deben dividir historias de usuario en tareas durante las sesiones de planificación. Como cada maestrillo tendrá su librillo, existirán mil maneras y herramientas para complementar o hacer diferente esta actividad fundamental en los equipos Scrum. Estaría encantado de que compartieras cómo lo haces tú, así que no te cortes y deja tu comentario.

dividir historias de usuario en tareas

Finalmente te dejo un artículo de Javier Garzás sobre cómo descomponer historias de usuario en tareas para que amplíes información si lo necesitas. Hay partes repetidas pues también yo lo tomé como inspiración, pero no deja de ser interesante como complemento.

También te puede interesar...

Crea ya tu lista de impedimentos en Scrum El rol del Scrum Master incluye eliminar impedimentos, pero ¿qué son los impedimentos en Scrum concretamente?¿Qué debe hacer el Scrum Master?¿cuáles d...
Resumen Scrum by Jeff Sutherland Tenía muchas ganas de leer este libro. Ya no solo porque era leer sobre el framework Scrum que utilizo a diario en mi trabajo, sino porque me lo había...
Los 7 desperdicios LEAN del software (y II) Este post es la continuación al post anterior Los 7 desperdicios del desarrollo de software donde describía los primeros 3 desperdicios del desarrollo...

Dejar un comentario

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

2 ideas sobre “Cómo dividir historias de usuario en tareas

  • Daniel Domingo

    Muy interesante el post, aquí van algunas preguntas:

    -Esas tareas tiene valor para el cliente y le deben enseñar?
    -Se deben cuantificar esas tareas en Puntos de Historia?
    -Todas las tareas deben ser generadas a partir de una HU, o bien pueden ser independientes? Por ejemplo: “Estudio de las herramientas a utilizar”.
    -Se deben sustituir las HU del backlog por als tareas que la componen?

    Un saludo!

    • samuelcasanova Autor

      Contesto según mi opinión:
      – Las tareas pueden tener o no valor para el cliente, no es un requisito que lo tengan como en las historias. Si lo tiene, por supuesto que se puede enseñar, cuanto antes el feedback mejor.
      – Depende, hay alternativas a estimar tareas, por ejemplo hacerlas tan pequeñas que no haga falta, o porque el equipo es maduro y tiene muy claro como hacer su seguimiento. A diferencia de las historias, no es imprescindible estimar para poder priorizar. Generalmente no priorizas tareas, sino historias. Mi recomendación es estimar si el equipo lo necesita.
      – No deberían haber muchas tareas que no fueran de historias de usuario, quizás alguna de deuda técnica si el proyecto es legado. La investigación para mí debería estar dentro de la historia.
      – El backlog se compone de historias. Las historias se descomponen en tareas normalmente para facilitar el desarrollo y el seguimiento del progreso de la historia. Las historias no deberían sustituirse nunca, ya que es el elemento que aporta valor.
      Muchas gracias por comentar, Daniel.