Cuando estamos descubriendo el Backlog a trabajar en un incitativa surgen diferentes dudas sobre el tamaño adecuado que debería tener el ítem para poder estar listo y ser desarrollado en una iteración, por ello es importante aplicar tecnicas de slicing que ayuden a limitar el alcance de los items de trabajo.
Existen varias definiciones de como podemos agrupar el alcance por medio de ítems de trabajo que pueden tomar varios tipos, la mas popular es la siguiente:
Para lograr descomponer los ítems se aplican técnicas de Slicing que permiten descomponer el trabajo en ítems mas pequeños.
¿Por qué hacer “Slicing”?
La incertidumbre de los ítems de trabajo es proporcional a su tamaño, a mayor tamaño mayor incertidumbre, ya que agrupa demasiadas definiciones que entenderlas, detallarlas, estimarlas y planificarlas, se vuelve una tarea difícil, por ello se recomienda descomponer el trabajo en ítems mas pequeños que ayuden al negocio y al equipo a tener una mejor priorización y estimación al momento de planificar.
Cuando aplicamos Slicing tenemos las siguientes ventajas:
- Entrega de valor con más frecuencia.
- Planificación más fácil.
- Feedback frecuente del negocio.
- Mejor sincronizacion entre personas y equipos.
- Mejores prioridades.
- Menos riesgo.
- Integraciones menos complicadas.
- Entendimiento compartido
Patrones de División de Historias de Usuario
Desglosando por pasos del flujo de trabajo
Si los PBI implican un flujo de trabajo de algún tipo, el elemento generalmente se puede dividir en pasos individuales.
Como cliente, quiero pagar los productos
en mi carrito de compra para recibir mis
productos en casa.
- Como cliente puedo iniciar sesión con mi cuenta.
- Como cliente puedo revisar y confirmar mi pedido.
- Como cliente, puedo pagar mi pedido con una transferencia bancaria.
- Como cliente, puedo pagar mi pedido con tarjeta de crédito.
- Como cliente recibo un correo electrónico de confirmación con mi pedido.
Desglosando por reglas de negocio
Los PBI a menudo implican una serie de reglas comerciales explícitas o implícitas.
Como cliente, quiero pagar los productos en mi carrito de compra para recibir mis productos en casa.
- Como propietario de una tienda, puedo rechazar pedidos de menos de 10 dólares, porque no son rentables.
- Como propietario de la tienda, puedo rechazar clientes fuera X region. Porque los gastos de envío hacen que estos pedidos no sean rentables.
- Como propietario de la tienda, puedo reservar productos en stock por 48 horas, para que otros clientes vean un stock realista.
- Como propietario de la tienda, puedo cancelar automáticamente los pedidos por los que no he recibido el pago dentro de las 48 horas, por lo que puedo venderlos nuevamente a otros clientes.
Desglosando por flujo feliz / infeliz
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.
Como cliente, deseo iniciar sesión con mi cuenta para
poder acceder a las páginas seguras
- Como usuario puedo iniciar sesión con mi cuenta, de modo que pueda acceder a páginas seguras (feliz).
- Como usuario, puedo restablecer mi contraseña cuando falla mi inicio de sesión, así que puedo intentar iniciar sesión nuevamente (infeliz).
- Como usuario, se me da la opción de registrar una nueva cuenta si no se conoce mi inicio de sesión, por lo que puedo acceder a páginas seguras (infeliz).
- Como propietario del sitio, puedo bloquear a los usuarios que inician sesión incorrectamente tres veces seguidas, por lo que puedo proteger el sitio contra piratas informáticos (infeliz).
Desglosando por opciones de entrada / plataforma
La mayoría de las aplicaciones tienen que ser compatibles con varias opciones de entrada y / o web, plataformas, como computadoras de escritorio, tabletas, teléfonos móviles o pantallas táctiles.
Como miembro del equipo deseo ver el Scrum Board, así que
sé cómo lo estamos haciendo como equipo.
- Como miembro del equipo, puedo ver el Scrum Board en mi escritorio, así que sé el estado del sprint.
- Como miembro del equipo puedo ver el Scrum Board en mi teléfono móvil, así que sé el estado del sprint.
- Como miembro del equipo, puedo ver el Scrum Board en una pantalla táctil, así que sé el estado del sprint.
- Como miembro del equipo puedo ver el Scrum Board en una impresión, así que sé el estado del sprint.
Desglosando por tipos de datos o parámetros
Algunos PBI se pueden dividir según los tipos de datos que devuelven o los parámetros que deben manejar.
Como cliente deseo buscar productos para poder verlos
y ordenarlos
- Como cliente, puedo buscar un producto por su número de producto, por lo que puedo encontrar rápidamente un producto que ya conozco.
- Como cliente, puedo buscar productos en un rango de precios, para que los resultados de búsqueda sean más relevantes.
- Como cliente puedo buscar productos por su color, para que los resultados de búsqueda sean más relevantes.
- Como cliente, puedo buscar productos en un grupo de productos, de modo que los resultados de búsqueda sean más relevantes.
Desglosando por operaciones
Los PBI a menudo involucran una serie de operaciones predeterminadas, como Crear, Leer, Actualizar o Borrado (comúnmente abreviadas como CRUD).
Como propietario de la tienda, deseo administrar los
productos en mi tienda web, por lo que puedo actualizar
el precio y la información del producto si se modifica
- Como propietario de la tienda puedo agregar nuevos productos, para que los clientes puedan comprarlos.
- Como propietario de la tienda, puedo actualizar los productos existentes, por lo que puedo ajustar los cambios en los precios o la información del producto.
- Como propietario de la tienda puedo eliminar productos, así que puedo eliminar productos que ya no tengo en stock.
- Como propietario de una tienda puedo ocultar productos, por lo que no se pueden vender por el momento.
Desglose por escenarios de prueba / caso de prueba
Como gerente puedo asignar tareas a los empleados,
para que puedan trabajar en tareas
Esta estrategia es útil cuando es difícil desglosar los PBI grandes basados únicamente en la funcionalidad. En ese caso, es útil preguntar cómo se probará una parte de la funcionalidad. ¿Qué escenarios deben verificarse para saber si la funcionalidad funciona?
- Caso de prueba 1: si un empleado ya está asignado, no puede ser asignado a otra tarea.
- Caso de prueba 2: si un empleado se ha reportado enfermo, debe estar marcado visualmente.
- Caso de prueba 3: si un empleado se ha reportado enfermo, no se le puede asignar una tarea.
- Caso de prueba 4: si un empleado aún no está asignado, se le puede asignar una tarea.
- Caso de prueba 5: los empleados pueden ser asignados con un monitor de pantalla táctil.
Desglosando por roles
Los PBI a menudo involucran una cantidad de roles (o grupos) que realizan partes de esa funcionalidad.
Como organización de noticias deseo publicar nuevos
artículos en nuestra página de inicio, para que los
clientes tengan una razón para regresar periódicamente
- Como cliente puedo leer un nuevo artículo, así puedo informarme de eventos importantes.
- Como periodista puedo escribir un artículo, para que lo puedan leer nuestros clientes.
- Como editor, puedo revisar el artículo antes de ponerlo en el sitio, para que podamos evitar errores tipográficos.
- Como administrador puedo eliminar artículos del sitio, de modo que podamos extraer artículos ofensivos.
- Como cliente puedo revisar y confirmar mi pedido, por lo que puedo corregir errores antes de pagar.
Desglosando por ‘optimizar ahora’ vs ‘optimizar más tarde
A menudo, los PBI pueden implementarse en diversos grados de perfección y optimización de la funcionalidad descrita.
Como visitante deseo buscar hoteles en un vecindario,
así puedo restringir mi búsqueda
- Como visitante, puedo buscar hoteles basados en un radio desde una dirección, por lo que puedo limitar mi búsqueda.
- Como visitante, puedo ingresar el código postal para completar automáticamente la dirección, por lo que no tengo que ingresar la dirección completa manualmente.
- Como visitante, puedo usar mi ubicación (GPS) para buscar en el vecindario, por lo que no tengo que ingresar la dirección manualmente.
- Como visitante, obtengo los hoteles más buscados en el vecindario de inmediato, mientras que otros hoteles se están cargando en el fondo, así que obtengo resultados más rápidamente.
Desglosa por criterios de aceptación identificados
Esto puede parecer muy obvio, pero a menudo es la forma más fácil y natural de desglosar una historia
Como operador de hotel, quiero establecer la tarifa
óptima para las habitaciones de mi hotel.
- Como
operador de hotel, puedo definir un ‘Conjunto comparable’ de hoteles.
- 1b2: Como operador de hotel, puedo agregar un hotel a un conjunto comparable.
- 1b3: Como operador de hotel, puedo eliminar un hotel de un conjunto comparable.
- 1b4: Como operador de hotel, puedo eliminar un conjunto comparable que ya no deseo utilizar.
- 1c: Como operador de hotel, quiero establecer la tarifa óptima para las habitaciones según la ocupación proyectada actual.
- 1d: Como operador de un hotel, puedo establecer parámetros relacionados con las tasas óptimas, como la ocupación objetivo, la ocupación mínima aceptable y la ocupación máxima aceptable.
Desglose los elementos en función de los requisitos de usabilidad
Desglose los elementos en función de los requisitos de usabilidad y experiencia del usuario.
- Rendimiento : Velocidad de ejecución, errores
- Facilidad de Aprendizaje : Tiempo y esfuerzo requerido para alcanzar un nivel de uso
- Flexibilidad : Acomodarse a cambios
- Actitud : Generar actitud positiva en los usuarios
División de Historias de Usuario – SPIDR
División de Historias de Usuario – División que construyen calidad
Es importante buscar espacio para realizar workshops para que el equipo aprenda cómo dividir historias y buscar entregar artículos de mayor valor más rápido, estas sesiones se suelen utilizar patrones de división y puede ser punto de partida para iniciar a aprender las técnicas.
En las sesiones de refinamiento imprime los patrones de división y deja que las personas se experimenten aprendiendo el uso de las mismas, al principio con ejercicios lúdicos, pero luego aplicarlo con historias de usuario que el equipo tenga en el radar para trabajar en sus próximas iteraciones.
Guias:
Fuentes :
- https://dzone.com/articles/how-to-teach-a-scrum-team-to-split-stories
- https://blogs.itemis.com/en/spidr-five-simple-techniques-for-a-perfectly-split-user-story
- https://www.mountaingoatsoftware.com/exclusive/spidr-poster-download
- https://ideas.riverglide.com/apples-oranges-user-stories-fb7e3aa6dbb4
- https://medium.com/the-liberators/10-powerful-strategies-for-breaking-down-user-stories-in-scrum-with-cheatsheet-2cd9aae7d0eb
¡Muy buen artículo! Me llama la atención en el «Desglose por escenarios de prueba» que uno de los casos de prueba sea «los empleados pueden ser asignados con un monitor de pantalla táctil.». ¿Tienen algún sentido los otros 4 casos de prueba si no estamos hablando de la interacción con el usuario, hablando justamente de dividir historias de usuario en otras mas pequeñas?
Hola Mauro gracias por comentar, el criterio utilizado para la realizacion del slicing para hacerlo de forma vertical es importante, sin embargo hay varias estrategias de hacerlo, por ello lo importante esta en encontar la forma en que podamos dividir el alcance en entregas pequeñas, que solucionen una necesidad y que se puedan desplegar rapidamente. No hay una receta magica, solo queda experimentar y hacer el mejor slicing posible.
Saludos !