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...

Resumen del libro Coaching Agile Teams de Lyssa Ad... El libro Coaching Agile Teams de Lyssa Adkins es una referencia obligada dentro del mundillo Agile. Prácticamente todo el mundo que conozco y se lo ha...
Acuerdos de trabajo, ahorra energía mental en tu e... Los acuerdos de trabajo son uno de los pilares sobre los que se construye un equipo Agile/Scrum. En este artículo intentaré dar mi visión sobre los ac...
Resumen Agile Retrospectives de Esther Derby y Dia... El libro Agile Retrospectives de Esther Derby y Diana Larsen es un manual para Scrum Masters sobre cómo facilitar las retrospectivas en los equipos. ...

Dejar un comentario

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

5 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.

  • MargaritaCN

    No tengo mucha experiencia en la ingenieria de software usando Scrum, pero pienso q lo mas importante en cualquier variante, ya sea el enfoque tradicional o las metodologis agiles es la capacidad del analista en obtener las necesidades del cliente, idependientemente del nivel de detalle q este sea capaz de aportar desde el primer el encuentro. En mi experiencia personal y me ha dado resultado, siempre comienzo el levantamiento de requisitos a partir de los resultados esperados x el cliente. Este es el punto de partida para de comenzar a “desenrrollar la madeja” hasta encontrar la punta. En otras palabras, una vez identificado los objetivos finales se comienza a explorar cada uno. Cada objetivo principal puede desencadenandar objetivos auxiliares, q son necesario resolver hasta llegar al objetivo final. Este desglose puede ser tan profundo como complejo sea el objetivo inicial. El analista debe tener la capacidad de identificar los requisitos funcionales que garantizan el cumplimiento de un objetivo final, cuyos requisitos no se pueden desagregar mas (primitiva funcional). Una vez llegado a este nivel entonces nos dedicamos a entender el COMO, teniendo en cuenta los criterios de aceptacion. En el scrum, como yo lo veo, los criterios de aceptacion constituyen los puntos de entrada para desagregar la historia de usuario pudiendo llegar al COMO de cada criterio o derivando en nuevas historias de usuario. Pero la idea es comenza siempre por el final, por tanto considero q una historia de usurio requiere siempe de los criterios de aceptacion. Tambien pienso q generalmente llegamos a combinar scrum con elementos del enfoque tradicional para logar formalizar el conocimento del COMO (Casos de uso, prototipo de interfaz fisual, diagrama de flujo de datos, etc). Quisiera me corrigiera los errores q pudiera estar cometiendo en mi forma de proceder.

    • samuelcasanova Autor

      Hola Margarita, gracias por compartir en el blog.
      Lo que te diría es que me parece una excelente idea comenzar siempre con los objetivos en mente, los resultados esperados por el cliente. Me falta mucha información para entender realmente tu situación y si se pueden hacer mejor las cosas. Lo que puedo intuir por lo que comentas es que estáis separando la etapa de “levantamiento de requisitos” de la implementación. Aquí Scrum busca un enfoque empírico, es decir, construyo algo en 2 semanas, lo enseño y aprendo para continuar. El enfoque tradicional sin embargo es predictivo, hago un análisis completo e intento adivinar con anticipación tanto “qué” y “cómo”. Este último enfoque, entre otros inconvenientes, no contempla los casos de que el cliente no sabe lo que quiere, o lo sabe pero es complicado de explicar, o los requisitos cambian muy deprisa.