10 estrategias útiles para descomponer historias de usuario grandes (traducción al castellano)

Si en algún momento nos encontramos frente al reto de que nuestro equipo Scrum cuente siempre con un Backlog adecuado para atender los items especificados, es necesario que todos puedan contribuir en su mantenimiento y actualización. A continuación se encuentra la versión traducida al castellano del artículo “10 useful strategies for breaking down large User Stories (and a cheatsheet)” escrito por Christiaan Verwijs.


Los equipos que han llegado a dominar Scrum saben que la clave del éxito radica disponer de un Product Backlog que se encuentre siempre disponible para su uso, con un refinado incremental y en el cual el trabajo este desglosado. Los equipos prefieren Sprint Backlogs con varios ítems pequeños (funcionales) en lugar de solamente algunos ítems grandes. Los ítems pequeños mejoran el flujo y reducen el riesgo de que el Sprint falle. En este artículo, explicaré por qué es importante la descomposición del trabajo y por qué debería ser hecho de manera transversal a la funcionalidad, en lugar de considerar características técnicos. A continuación daré a conocer ofreceré 10 estrategias útiles que los equipos Scrum experimentados usan para descomponer el trabajo.

Para el resto de este artículo, usaré “Historias de Usuario” para indicar ítems funcionales en el Product Backlog. Hay que tener en cuenta que las “Historias de usuario” están destinadas a ayudar para que los equipos piensen en términos de funcionalidad, en lugar de técnicos. Los términos técnicos no son requeridos.

Por qué y cuándo descomponer los ítems

El desarrollo de software es ciertamente impredecible. Algunas “Historias de Usuario” del Backlog requerirán más esfuerzo de lo esperado, mientras que otros ítems requerirán menos. Por lo tanto, si el trabajo para un Sprint contiene solo algunos ítems grandes, el impacto de una inadecuada estimación del trabajo, o incluso de un solo item tendrá un impacto profundo en el Sprint. Y dado que los ítems más grandes tienden a ser más difíciles de estimar y comprender, la posibilidad de que el Sprint falle se aumenta.

Los equipos experimentados de Scrum dedican tiempo y esfuerzo a desglosar grandes Historias de Usuario en unas más pequeñas. Aunque a veces lo hacen durante la planificación de un nuevo Sprint, han aprendido que este proceso de “refinamiento” debe ser continuo para hacer que los Sprints, y en particular su planificación, sean más fluidas. Entonces, cuando un Sprint está en marcha, el equipo también pasa tiempo analizando Historias de Usuario para el próximo Sprint, y quizás incluso para el Sprint posterior. Pero esto se realiza de la manera “just-in-time”, de manera que el equipo pasa cada vez menos tiempo en los Sprints lejanos.

Este proceso de descomponer el trabajo mejora la comprensión compartida, aumenta la precisión de la estimación y facilita al Product Owner en la priorización del trabajo. Pero realizar esta tarea de buena manera no es fácil, y se necesita práctica para hacerlo “sobre la marcha”. Afortunadamente, la comunidad ágil ha ideado una serie de estrategias útiles para desglosar el trabajo en trozos más pequeños.

Por qué una descomposición vertical es superior a una horizontal

En términos generales, existen dos enfoques para dividir grandes Historias de Usuarios. El primer enfoque se llama “descomposición horizontal” e implica desglosar las historias por el tipo de trabajo que se necesita hacer, o las capas o componentes que están involucrados. Es decir, el trabajo que se tiene que hacer para la UI, la base de datos, algunos componentes, el front-end y las pruebas se dividen en ítems técnicos en el Backlog. Esto no funciona bien en Scrum por varias razones:

  • Los ítems individuales no dan como resultado un software funcional ni demostrable: supongamos que un equipo trabaja en un proceso de pedido para una tienda en línea en un Sprint. Si dividieran horizontalmente la Historia del Usuario, terminarían trabajando en el diseño, la base de datos, el front-end y las pruebas. Aunque los artículos son ciertamente más pequeños, no entregan software que funcione por sí mismos. Después de todo, una pieza de funcionalidad no puede activarse cuando solo se termina la interfaz de usuario, o cuando solo se modificó la base de datos. También es una mala idea salir a producción sin suficientes pruebas. Por lo tanto, los ítems individuales no dan como resultado un software funcional ni demostrable y, en consecuencia con valor para el negocio. Solo la combinación de todo el trabajo genera valor para el negocio. Pero si se genera valor cuando todas las tareas están completas. Y esto a menudo es un problema, como explica a continuación;
  • Incrementa los cuellos de botella, en lugar de reducirlos: la descomposición horizontal a menudo va acompañada de un “pensamiento silo”. Cada uno de los miembros es tomado de uno de los silos necesarios para el desarrollo de software. El “diseñador” se encargará del diseño, el “administrador de base de datos” configurará la base de datos, el “desarrollador” escribirá el código y el de “QA” hará las pruebas. Si los miembros del equipo no son intercambiables (que a menudo es el caso cuando se utiliza este enfoque), existe una buena posibilidad de que se produzcan cuellos de botella. Si el “diseñador” no puede hacer su trabajo a tiempo, esto tendrá un impacto en las tareas que siguen al diseño. Debido a que los miembros del equipo no pueden ayudarse mutuamente, cada retraso, problema o interrupción afectará todo el Sprint;
  • Las divisiones horizontales no se pueden priorizar: ¿cómo puede un Product Owner priorizar un Backlog si este consta de sectores horizontales? Debido a que ninguno de los elementos entrega valor comercial o software que funcione por sí solo, el Product Owner no podrá priorizar el trabajo. También existe una buena posibilidad de que los cortes sean bastante técnicos, lo que crea distancia y malentendidos entre el Product Owner y el equipo;

Aunque un desglose horizontal de las historias de los usuarios dará como resultado elementos más pequeños, limita severamente la capacidad de un equipo para entregar software que funcione, evitar los cuellos de botella y priorizar el trabajo. Por lo tanto, aumenta el riesgo de fallar el Sprint. Es una mala idea.

En Scrum, una descomposición vertical es más útil, en el que las Historias de Usuarios se dividen en otras más pequeñas (en lugar de tareas técnicas). Si las historias de los usuarios se desglosan verticalmente, se dividen de tal manera que los ítems más pequeños aún resultan en software que funciona y son demostrables. La funcionalidad no se dividirá en capas técnicas o tareas, sino en capas funcionales. Entonces, si la historia del usuario es “Como cliente quiero pagar mi pedido, para obtener mis productos”, se puede dividir en historias de usuarios más pequeños como las siguientes “Como cliente quiero pagar por transferencia bancaria, para obtener mi productos “o” Como cliente quiero pagar con tarjeta de crédito, para que pueda obtener mis productos “.

Una metáfora nos permitirá aclarar aún más la diferencia. Imagina rebanar un pastel con capas de crema, fruta y pastel. Si cortara la torta horizontalmente, cada invitado solo obtendría una porción de pastel, crema o fruta. Estoy seguro de que sus invitados habrían esperado algo más. Obtener solo una capa del pastel no les permite probar todo el pastel. Un enfoque más amistoso es cortar el pastel en pedazos verticales, cada una con un poco de pastel, crema y fruta:

Hay muchas estrategias disponibles para desglosar Historias de Usuarios grandes. He recogido diez de los más útiles. Como podrás apreciar, estas estrategias no solo ayudan a desglosar las Historias de Usuarios, sino que también ayudan a decidir qué es importante y qué no. De esta forma, el Product Owner puede priorizar más fácilmente el trabajo y tomar mejores decisiones respecto a lo que el equipo Scrum se debería dedicar.

Estrategia 1: Descomponiendo el flujo de trabajo en pasos.

Si una historia de usuario involucra un flujo de trabajo de cualquier tipo, este usualmente puede ser descompuesto en pasos individuales.

Ejemplo: Historia de usuario de un proceso de compra en una tienda web:

Como cliente, 
quiero pagar los productos de mi carrito de compras, 
para recibir los productos en mi casa.

Se podría identificar los siguientes pasos:

  • Como cliente, quiero iniciar sesión con mi cuenta, de tal modo que no tengo que volver a ingresar mi información personal cada vez;
  • Como cliente, quiero revisar y confirmar mi pedido, para poder corregir los errores antes de pagar;
  • Como cliente, quiero pagar mi pedido con una transferencia bancaria, para poder confirmar mi pedido;
  • Como cliente quiero pagar mi pedido con tarjeta de crédito, para poder confirmar mi pedido;
  • Como cliente, quiero recibir un correo electrónico de confirmación de mi pedido, para tener un comprobante de mi compra;

Al desglosar una gran Historia de Usuario como esta, hemos mejorado nuestra comprensión de la funcionalidad y nuestra capacidad de estimación. También será más fácil para un Product Owner priorizar el trabajo. Es posible que algunos pasos en el flujo de trabajo no sean importantes en este momento y se puedan mover a futuros Sprints. Tal vez el correo electrónico de confirmación del pedido se pueda hacer a mano por el momento, o los clientes solo pueden pagar con tarjeta de crédito de manera inicial. También podría estar bien solicitar a los clientes que vuelvan a ingresar (temporalmente) su información personal para cada pedido. Sin duda, esto limitará la funcionalidad de la tienda web, pero permite que un equipo Scrum revise (y tal vez incluso implemente) la funcionalidad completa al final del Sprint, realiza pruebas y utiliza el feedback para realizar los cambios necesarios.

Estrategia 2: Desglose por reglas de negocio

Las historias de usuario a menudo involucran de manera explícita o implícita reglas de negocio.

Ejemplo: Proceso de pedido de una tienda online:

Como cliente, 
quiero comprar los productos de mi carrito de compras, 
para poder recibir mis productos en mí casa.

Se podría identificar las siguientes “reglas de negocio:

  • Como propietario de una tienda, quiero rechazar pedidos inferiores a 10 dólares porque no son rentables;
  • Como propietario de una tienda, quiero rechazar clientes fuera de los EE. UU. Porque los gastos de envío hacen que estas órdenes no sean rentables;
  • Como propietario de la tienda, quiero reservar productos en el stock durante 48 horas, para que otros clientes vean un stock realista;
  • Como propietario de la tienda, quiero cancelar automáticamente los pedidos para los cuales no he recibido el pago en 48 horas, de modo que puedo volver a venderlos a otros clientes;

Las reglas de negocio a menudo están implícitas, por lo que se necesitarán algunas habilidades y destrezas analíticas para identificarlas. Puede ser útil emplear otra estrategia (descrita en la estrategia Nro. 7); ¿cómo se probará la funcionalidad? A menudo, los casos de prueba implican reglas de negocio importantes. Una vez que se hayan identificado las reglas de negocio, de nuevo habrá mejorado nuestra comprensión y capacidad de estimación. El Product Owner puede decidir que algunas reglas comerciales no son importantes por el momento o pueden implementarse de forma simplificada. Tal vez está bien por ahora devolver manualmente los productos no pagados al inventario cuando no se ha recibido un pago dentro de las 48 horas, o los pedidos se pueden cancelar manualmente. Aún más pragmáticamente, un mensaje en el sitio explicando que “los pedidos no se envían fuera de los EE. UU.” O que “el precio mínimo del pedido debe ser de al menos 10 dólares” puede ser suficiente por ahora. Ahorrará tiempo y dinero necesarios para hacer cumplir esta regla comercial.

Estrategia 3: Desglose por un flujo feliz / infeliz

La funcionalidad a menudo implica un flujo feliz y uno o más flujos infelices. El flujo feliz describe cómo se comporta la funcionalidad cuando todo va bien. Si hay desviaciones, excepciones u otros problemas, se invocan flujos infelices.

Ejemplo: Iniciar sesión en un sitio web seguro:

Como cliente, 
quiero iniciar sesión con mi cuenta, 
para poder acceder a páginas seguras.

Podemos identificar un flujo feliz y varios flujos infelices potenciales:

  • Como usuario, quiero iniciar sesión con mi cuenta, de modo que pueda acceder a páginas seguras (feliz);
  • Como usuario, quiero restablecer mi contraseña cuando falla mi inicio de sesión, por lo que puedo intentar iniciar sesión de nuevo (infeliz);
  • Como usuario, quiero la opción de registrar una nueva cuenta si no se conoce mi nombre de usuario, de modo que puedo obtener acceso a páginas seguras (infeliz);
  • Como propietario del sitio, quiero bloquear a los usuarios que inician sesión incorrectamente tres veces seguidas, para poder proteger el sitio contra los piratas informáticos (infelices);

Los flujos infelices describen excepciones. Al identificar los distintos flujos, comprendemos más claramente la funcionalidad requerida. Un Product Owner puede decidir más fácilmente lo que es importante en este momento. Tal vez bloquear usuarios después de tres fallas no es importante en este momento, porque de todos modos solo hay un puñado de usuarios en la primera versión. O tal vez se pueda restablecer una contraseña enviando un correo electrónico a un empleado de atención al cliente por el momento. De nuevo, al dividir la funcionalidad, podemos hacer preguntas con mayor precisión sobre el valor del negocio y tomar decisiones en consecuencia.

Estrategia 4: Desglose por opciones de entrada/plataforma

La mayoría de las aplicaciones web tienen que soportar varias opciones de entrada y/o plataformas, como computadoras de escritorio, tabletas, teléfonos móviles o pantallas táctiles. Puede ser beneficioso descomponer elementos grandes según sus opciones de entrada.

Ejemplo: Tablero Scrum (Scrum board) digital para un equipo:

Como miembro del equipo,
quiero ver el tablero Scrum
para conocer como estamos en el equipo.

Podemos identificar las siguientes opciones de entrada:

  • Como miembro del equipo, quiero ver el tablero Scrum en mi escritorio, así sé el estado del Sprint;
  • Como miembro del equipo, quiero ver el tablero Scrum en mi teléfono móvil, así sé el estado del Sprint;
  • Como miembro del equipo, quiero ver el tablero Scrum en una pantalla táctil, así sé el estado del Sprint;
  • Como miembro del equipo, quiero ver el tablero Scrum en una impresión, así sé el estado del Sprint;

Al desglosar los ítems grandes de esta manera, el Product Owner puede priorizar más fácilmente qué opciones de entrada o plataformas son más importantes. Es probable que una versión de escritorio sea suficiente por ahora, mientras que una versión móvil puede ser empujada a un Sprint futuro. O tal vez la impresión se puede implementar con una simple captura de PDF por el momento, sin tener que crear una versión adecuada para la impresión.

Estrategia 5: Desglose por tipo de dato o parámetros

Algunas historias de usuarios se pueden dividir en función de los tipos de datos que devuelven o los parámetros que deben manejar.

Ejemplo: Función de búsqueda para una tienda en línea:

Como cliente 
quiero buscar productos
para poder verlos y pedirlos.

Existen muchas formas de buscar un producto. Todos estos parámetros potenciales se pueden considerar y dividir en historias de usuarios más pequeños:

  • Como cliente quiero buscar un producto por su número de producto, así puedo encontrar rápidamente un producto que ya conozco;
  • Como cliente, quiero buscar productos en un rango de precios, para que los resultados de búsqueda sean más relevantes;
  • Como cliente quiero buscar productos por su color, para que los resultados de búsqueda sean más relevantes;
  • Como cliente, quiero buscar productos en un grupo de productos, para que los resultados de búsqueda sean más relevantes;

Al desglosar la funcionalidad de búsqueda de esta manera, comprendemos más claramente qué tipo de parámetros de búsqueda se utilizarán. Esto nos permite estimar con mayor precisión la funcionalidad, pero también permite que el Product Owner tome decisiones sobre la prioridad. Quizás la búsqueda no sea relevante debido a la pequeña cantidad de productos. Podría ser relevante cuando crezca la cantidad de productos. O tal vez parte de la funcionalidad de búsqueda se puede implementar de manera simplificada por ahora. Otro ejemplo de esta estrategia es cuando se rompe la funcionalidad que involucra información de gestión basada en los tipos de datos que regresan. Parte de la información se puede presentar visualmente en cuadros o gráficos (data types), pero también se puede mostrar en un formato tabular (datatypes) por ahora. Tal vez el Product Owner está de acuerdo con exportar los datos a Excel y crear manualmente todos los gráficos y tablas por el momento.

Estrategia 6: Desglosado por operaciones

Las historias de usuario a menudo implican una serie de operaciones predeterminadas, como Crear, Leer, Actualizar o Suprimir (comúnmente abreviado como CRUD). Las operaciones de CRUD son muy frecuentes cuando la funcionalidad implica la gestión de entidades, como productos, usuarios u órdenes:

Como propietario de la tienda, 
quiero administrar los productos en mi tienda web,
para actualizar el precio y la información de los productos si estos cambian.

Al identificar las operaciones individuales requeridas para esta funcionalidad, se puede dividir en pequeñas funcionalidades:

  • Como propietario de la tienda, quiero agregar nuevos productos para que los clientes puedan comprarlos;
  • Como propietario de la tienda, quiero actualizar la información de los productos existentes, así puedo ajustar los cambios en los precios o la información del producto;
  • Como propietario de tienda, quiero eliminar productos, así puedo eliminar productos que ya no tengo en existencia;
  • Como propietario de tienda, quiero ocultar productos, por lo que no pueden venderse por el momento;

Cuando se presenta esta estrategia, muchos equipos se preguntan si los ítems más pequeños realmente brindan valor de negocio. Después de todo, ¿de qué sirve crear entidades solo cuando no puedes actualizarlas o eliminarlas después? Pero tal vez el Product Owner tiene una cantidad limitada de productos, que la edición o eliminación se puede hacer en la base de datos directamente. A veces, una operación se puede implementar fácilmente en una forma simplificada. Eliminar un producto se puede hacer de dos maneras; puede eliminar completamente el registro y todos los registros asociados, o puede “eliminar logicamente” un producto. En ese caso, el producto aún está en la base de datos, pero está marcado como “eliminado”. A veces, uno de estos enfoques es más fácil de implementar y, por ahora, puede ser “lo suficientemente bueno”.

Estrategia 7: Desglosado por “escenario de prueba”/”caso de prueba”

Esta estrategia es útil cuando es difícil desglosar historias de usuarios grandes basadas en la funcionalidad sola. En ese caso, ayuda preguntar cómo se probará una pieza de funcionalidad. ¿Qué escenarios deben verificarse para saber si la funcionalidad funciona?

Ejemplo: Planificación de tareas:

Como gerente, 
quiero asignar tareas a los empleados, 
para que puedan trabajar en tareas.

Si consideramos esta funcionalidad en función de los posibles escenarios, podemos desglosar el elemento en:

  • Caso de prueba 1: si un empleado ya está asignado, no puede asignarse a otra tarea;
  • Caso de prueba 2: si un empleado ha informado que está enfermo, debe estar marcado visualmente;
  • Caso de prueba 3: si un empleado se ha reportado enfermo, no se lo puede asignar a una tarea;
  • Caso de prueba 4: si un empleado aún no está asignado, se lo puede asignar a una tarea;
  • Caso de prueba 5: los empleados pueden ser asignados con un monitor de pantalla táctil;

Esta estrategia realmente te ayuda a aplicar implícitamente las otras estrategias. Al pensar en las pruebas, automáticamente se obtiene una serie de reglas de negocio (Nro. 1, Nro. 2, Nro. 3 y Nro. 4), flujos infelices (Nro. 1, Nro. 2 y Nro. 3) e incluso opciones de entrada (Nro. 5). Algunas veces, los escenarios de prueba pueden ser muy complicados debido al trabajo involucrado para configurar las pruebas y trabajar a través de ellas. Si un escenario de prueba no es muy común para comenzar o no presenta un riesgo lo suficientemente alto, un Product Owner puede decidir omitir la funcionalidad por el momento y enfocarse en escenarios de prueba que entreguen más valor. En otros casos, los escenarios de prueba se pueden simplificar para cubrir los problemas más urgentes. De cualquier forma, los escenarios de prueba relevantes pueden traducirse fácilmente en elementos atrasados y agregarse al Sprint o al Backlog.

Estrategia 8: Desglosando por roles

Las historias de los usuarios a menudo implican una cantidad de roles (o grupos) que realizan partes de esa funcionalidad. Tome una historia de usuario para publicar nuevos artículos en un sitio web de un periódico público:

Como organización de noticias,
quiero publicar nuevos artículos en nuestra página de inicio,
para que los clientes tengan una razón para regresar periódicamente.

Al considerar los diversos roles que están involucrados, podemos dividir la funcionalidad en los siguientes bits:

  • Como cliente, puedo leer un nuevo artículo, para poder informarme de eventos importantes;
  • Como periodista, puedo escribir un artículo para que nuestros clientes lo puedan leer;
  • Como editor, puedo revisar el artículo antes de ponerlo en el sitio, de modo que podamos evitar errores tipográficos;
  • Como administrador puedo eliminar artículos del sitio, de modo que podamos retirar artículos ofensivos;
  • Como cliente, puedo revisar y confirmar mi pedido, para poder corregir los errores antes de pagar;

Al desglosar la funcionalidad en roles que tienen que realizar partes de esa funcionalidad, comprendemos mejor qué funcionalidad se necesita y podemos estimar con mayor precisión en el trabajo involucrado. Escribir Historias de Usuario es una gran manera de aplicar esta estrategia. También ayuda al Product Owner a priorizar. Algunos roles pueden ser menos relevantes en este momento y pueden implementarse más adelante. Tal vez no sea necesario en ese momento para un editor. O el editor puede ser llamado por un periodista para verificar el artículo manualmente.

Estrategia 9: Desglosando por “optimizar ahora” vs “optimizar más tarde”

Frecuentemente, las historias de los usuarios se pueden implementar en diversos grados de perfección y optimización de la funcionalidad descrita.

Ejemplo:

Como visitante, 
quiero buscar hoteles en un vecindario, 
para así restringir mi búsqueda.

Una historia como esta se puede dividir en diversos grados de optimización:

  • Como visitante, quiero buscar hoteles basados ​​en un radio desde una dirección, de modo que pueda restringir mi búsqueda;
  • Como visitante, quiero ingresar el código postal para completar automáticamente la dirección, así no tengo que ingresar la dirección completa manualmente;
  • Como visitante, quiero usar mi ubicación (GPS) para buscar en el vecindario, así no tengo que ingresar la dirección manualmente;
  • Como visitante quiero obtener de inmediato los hoteles más buscados en el vecindario, mientras que otros hoteles se cargan en segundo plano, por lo que obtengo resultados más rápidamente;

Permítanme ser claro en una cosa: se supone que esta estrategia no debe usarse como una excusa para escribir “código malo” ahora y “código mejor” en el futuro. Los equipos Scrum siempre deben esforzarse por ofrecer un código que se pueda mantener, (automáticamente) probado y bien escrito. Esta estrategia se refiere a la optimización funcional. En cualquier caso, un Product Owner puede priorizar más fácilmente estos ítems. Quizás sea suficiente por ahora permitir que los visitantes busquen por dirección (y un radio), mientras que en el futuro se implementa una funcionalidad más compleja (autocompletado, GPS).

Estrategia 10: Desglosando por compatibilidad con el navegador

En una variante de la estrategia Nro. 4, las historias de usuarios para aplicaciones web a menudo necesitan trabajar en una amplia variedad de plataformas de navegación. Los navegadores modernos tienden a ser más compatibles con los estándares y más fáciles de desarrollar, mientras que los navegadores más antiguos a menudo requieren hacks y personalizaciones para que todo funcione correctamente.

Ejemplo:

Como cliente 
quiero ver los detalles del producto, 
para saber si quiero comprarlo.

Al considerar las versiones de navegador, podemos dividir el trabajo en elementos más pequeños:

  • Como cliente, quiero ver los detalles del producto en un navegador moderno y compatible con los estándares, así sé si quiero comprarlo;
  • Como cliente, quiero ver los detalles del producto en IE7, así sé si quiero comprarlo;
  • Como cliente, quiero ver los detalles del producto en un navegador de texto, por lo que sé si deseo comprarlo;

Aunque sin duda sería preferible ofrecer esta funcionalidad con soporte completo para todas las versiones de navegador, existen escenarios donde este desglose es factible. Tal vez la gran mayoría de los visitantes utilizan navegadores modernos, que requieren menos esfuerzo para soportar navegadores antiguos (que no sean un warning). O tal vez la aplicación se ejecuta en una red interna donde todos los usuarios usan Internet Explorer 7. De nuevo, esto permite que el Product Owner priorice, y ayuda al equipo a dedicar primero tiempo y esfuerzo a la funcionalidad más importante.

Otras estrategias

Existen otras estrategias que son útiles al desglosar historias de usuarios grandes:

  • Desglosar los ítems basándose en los criterios de aceptación identificados.Esto puede parecer muy obvio, pero a menudo es la manera más fácil y natural de desglosar una historia. El trazado de los criterios de aceptación para las historias de un usuario requiere estrategias similares a las descritas previamente;
  • Desglosar los ítems según las partes que son difíciles de implementar y las partes que son más fáciles.Puede ser difícil configurar una pieza de funcionalidad en una interfaz de usuario muy diseñada, pero hacer que funcione con una interfaz de usuario simple puede ser fácil y suficiente por ahora. Nuevamente, se trata de ser pragmático y proporcionar valor comercial;
  • Desglosar los ítems basándose ​​en dependencias externas.En ocasiones, la funcionalidad depende de factores externos, como la implementación de un consumidor para un servicio web remoto (por ejemplo, para el pago electrónico o para conectarse a Twitter). Esto puede ser difícil, pero puede no tener la más alta prioridad. O las dependencias pueden ser burladas por el momento;
  • Desglosar los ítems según los requisitos de usabilidad.Esto incluye la funcionalidad para buscar a través de una lista de registros, hacer que un sitio web sea legible para personas ciegas o personas con daltonismo o que implementen migas de pan;
  • Desglosar los ítems según los requisitos de SEO, como la configuración de páginas de destino específicas para palabras clave específicas, la creación de objetivos para Google Analytics o la configuración de mapas de sitio XML;

¿Cuándo una Historia de Usuario es lo suficientemente pequeña?

No existe una regla clara sobre cuán pequeña debería ser la Historia de Usuario. Esto depende en gran medida de la duración de los Sprints, la naturaleza de la aplicación y el tamaño y la experiencia del equipo. A menudo se necesita varios Sprints para que un equipo Scrum pueda descubrir el punto óptimo.

Mi experiencia me dice que los equipos deben esforzarse por agregar al menos entre 5 historias en un Sprint de una semana (una por día). No tienen que ser del mismo tamaño, pero no deberían ser demasiado grandes por sí mismos. Cuando los equipos usan la estimación de Story Point, a menudo acuerdan el tamaño máximo para que una historia llegue al Sprint. De modo que una historia solo se tomará en el Sprint si es menor a (digamos) 8 puntos. Esto también le da un objetivo claro al proceso de refinamiento del próximo trabajo.

1 thought on “10 estrategias útiles para descomponer historias de usuario grandes (traducción al castellano)”

Leave a Reply

Your email address will not be published. Required fields are marked *