Scrum – Historias de Usuario IV

Scrum – Historias de Usuario IV

Clasificación de las Historias de Usuario

Las Historias de Usuario se pueden dividir en:

• Requeridas
• Importantes
• Opcionales
• No se construirán

Método MoSCoW

El método MoSCoW es una técnica de priorización de requisitos basada en el hecho de que aunque todos los requisitos se consideren importantes es fundamental destacar aquellos que permiten darle un mayor valor al sistema, lo que permite enfocar los trabajos de manera más eficiente.

• M (Must): Requisito que tiene que estar implementado en la versión final del producto para que la misma pueda ser considerada un éxito.
• S (Should): Requisito de alta prioridad que en la medida de lo posible debería ser incluido en la solución final, pero que llegado el momento y si fuera necesario, podría ser prescindible si hubiera alguna causa que lo justificara.
• C (Could): Requisito deseable pero no necesario, se implementaría si hubiera posibilidades presupuestarias y temporales.
• W (Won’t): Hace referencia a requisitos que están descartados de momento pero que en un futuro podrían ser tenidos de nuevo en cuenta y ser reclasificados en una de las categorías anteriores.

Estrategias para separar las Historias de Usuario

Estrategia 1: Dividir por los pasos de flujo de trabajo

Si las historias de usuario implican un flujo de trabajo de algún tipo, el item generalmente se puede dividir en pasos individuales

• Como cliente Quiero comprar los productos en mi cesta de la compra para poder recibir mis productos en el hogar
  • ” Como cliente Quiero iniciar sesión con mi cuenta, para no tener que volver a introducir la información personal cada vez”
  • ” Como cliente Quiero revisar y confirmar el pedido, para corregir los errores antes de pagar”
  • ” Como cliente Quiero pagar mi orden con una transferencia bancaria, para confirmar mi orden”
  • ” Como cliente Quiero pagar mi pedido con tarjeta de crédito, para confirmar mi orden”
  • ” Como cliente que desea recibir un correo electrónico de confirmación con mi pedido, para tener un comprobante de compra de mi pedido”

Al romper las HU de esta manera se mejora el entendimiento de la funcionalidad y la capacidad para estimar

Estrategia 2: Dividir por las reglas de negocio

Muchas historias de usuario implican una serie de reglas de negocio explícitas o implícitas.

• Como cliente Quiero comprar los productos en mi cesta de la compra para poder recibir mis productos en el hogar
  • ” Como dueño de la tienda, quiero rechazar pedidos por debajo de 10 dólares, porque no obtiene ningún beneficio de ellos”
  • ” Como dueño de la tienda, quiero rechazar clientes de fuera de México, debido a que los gastos de envío hacen de estas órdenes no rentables”
  • ” Como dueño de la tienda quiero reservar productos solicitados desde almacén durante 48 horas, para que otros clientes vean un inventario real”
  • ” Como dueño de la tienda quiero cancelar automáticamente los pedidos de los que no he recibido el pago dentro de las 48 horas, para venderlos de nuevo a otros clientes”

Estrategia 3: Dividir por flujo feliz / infeliz

La funcionalidad a menudo implica un flujo feliz y uno o más flujos infeliz.

El flujo feliz se describe cómo se comporta la funcionalidad cuando todo va bien. Si hay una desviación, excepciones u otros problemas, los flujos de descontentos se invocan.

• Como cliente Quiero iniciar sesión con mi cuenta de modo que pueda acceder a las páginas protegidas
  • ” Como usuario Quiero iniciar sesión con mi cuenta, de modo que pueda acceder a las páginas seguras (feliz)”
  • ” Como usuario quiero poder restablecer mi contraseña cuando el inicio de sesión falla, para intentar conectarme de nuevo (infeliz)”
  • ” Como usuario Quiero tener la opción de registrar una nueva cuenta si mi ingreso no es conocido, para acceder a páginas seguras (infeliz)”
  • ” Como propietario del sitio quiero bloquear a los usuarios que inician sesión en forma incorrecta tres veces seguidas, para proteger el sitio contra los piratas informáticos (infeliz)”

Los flujos infeliz describen excepciones. Mediante la identificación de los diversos flujos, comprendemos con mayor claridad la funcionalidad requerida

Estrategia 4: Dividir por opciones/plataforma de entrada

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

• Como miembro del equipo Quiero ver la Junta Scrum, para saber el estado del sprint
  • ” Como miembro del equipo Quiero ver la Junta Scrum en mi escritorio, para saber el estado del sprint”
  • ” Como miembro del equipo Quiero ver la Junta Scrum en mi teléfono móvil, para saber el estado del sprint”
  • ” Como miembro del equipo Quiero ver la Junta Scrum en una tableta, para saber el estado del sprint”
  • ” Como miembro del equipo Quiero ver la Junta Scrum en una impresión, para saber el estado del sprint”

Es probable que una versión de escritorio sea suficiente por ahora, mientras que una versión móvil es empujado a un sprint futuro

Estrategia 5: El desglose por tipos de datos o parámetros

Algunos HU se pueden dividir en base a los tipos de datos que se devuelven o los parámetros que se supone deben manejar

• Como cliente, Quiero buscar productos para verlos y ordenarlos
  • ” Como cliente Quiero buscar un producto por el número de producto, para encontrar rápidamente un producto que ya conozco”
  • ” Como cliente Quiero buscar productos por nivel de precio, para que los resultados de la búsqueda sean más relevantes”
  • ” Como cliente Quiero buscar productos por su color, para que los resultados de la búsqueda sean más relevantes”
  • ” Como cliente Quiero buscar productos en una categoría de productos, para que los resultados de la búsqueda sean más relevantes”

Al romper la funcionalidad de búsqueda, ahora entendemos con mayor claridad el tipo de parámetros de búsqueda que se utilizará

Estrategia 6: Dividir por operaciones

Las HU a menudo implican una serie de operaciones predeterminadas, tales como crear, leer, actualizar o eliminar (comúnmente abreviado como ABC). Las operaciones ABC son muy frecuentes cuando la funcionalidad implica la gestión de las entidades, tales como productos, usuarios u órdenes

• Como dueño de la tienda, quiero gestionar los productos en mi tienda en línea, para actualizar la información de precios y productos
  • ” Como dueño de la tienda, Quiero añadir nuevos productos, para que los clientes pueden comprarlos”
  • ” Como dueño de la tienda, Quiero actualizar los productos existentes, para que pueda adaptarse a los cambios en la información de precios o producto”
  • ” Como dueño de la tienda, Quiero borrar productos, para eliminar los productos que ya no cuentan con stock”
  • ” Como dueño de la tienda, quiero esconder productos, para que no se puedan vender por el momento”

Estrategia 7: Dividir por pruebas de escenarios/casos de prueba

Esta estrategia ayuda a preguntar cómo va a ser probado un pedazo de funcionalidad. ¿Qué escenarios tienen que ser controlados con el fin de saber si la funcionalidad trabaja?

• Como gerente, quiero asignar tareas a los empleados, para que puedan trabajar en tareas
  Si tenemos en cuenta esta funcionalidad en base a los escenarios posibles, podemos descomponer la HU en:
  • Caso de prueba 1: Si un empleado ya está asignado, él o ella no puede ser asignado a otra tarea
  • Caso de prueba 2: Si un empleado ha informado de que esta enfermo, él o ella debe estar marcada visualmente para que puedan ser ignorados
  • Caso de prueba 3: Si un empleado todavía no se ha asignado, puede ser asignado a una tarea
  • Caso de prueba 4: Los empleados pueden ser asignados con un monitor de pantalla táctil

Esta estrategia ayuda a las otras estrategias de forma implícita. Al pensar acerca de las pruebas, se termina automáticamente con una serie de reglas de negocio (#1, #2, #3 y #4), Flujo (in)feliz (#1, #2 y #3), e incluso opciones de entrada (#5)

Estrategia 8: Dividir por roles

Las HU a menudo implican una serie de roles (o grupos) que realizan partes de esa funcionalidad.

• Como organización de noticias, quiero publicar nuevos artículos en nuestra página web, para que los clientes vuelvan periódicamente
  • ” Como cliente, quiero leer un artículo nuevo, para mantenerme informado de los eventos importantes”
  • ” Como periodista, quiero escribir un artículo, para que sea leído por nuestros clientes”
  • ” Como editor, quiero revisar el artículo antes de ponerlo en el sitio, para evitar errores tipográficos”
  • ” Como administrador, quiero ser capaz de eliminar los artículos del sitio, para retirar artículos ofensivos”
  • ” Como cliente, quiero revisar y confirmar un pedido, para corregir los errores antes de pagar”

Historias de usuario con conjunciones y conectores

Reconocimiento previo de conjunciones y conectores del tipo: y, o, si, cuándo, pero, entonces, como, bueno, como, “comas“, etc.

EJEMPLO:

• EPICA: Como usuario anónimo quiero poder encontrar tutoriales y artículos para poder aplicarlos a mi crecimiento tecnológico“.
  • “Como usuario anónimo quiero poder encontrar tutoriales para poder resolver dudas tecnológicas“
  • “Como usuario anónimo quiero poder encontrar artículos para poder ampliar mi conocimiento tecnológico“.

¿Qué tan pequeña debe ser una HU?

No hay regla clara sobre qué tan pequeña debe ser una historia de usuario. Esto depende en gran medida de la longitud del Sprint, la naturaleza de la aplicación y el tamaño del equipo. En general, es una buena idea tener por lo menos 5 a 10 historias de usuario en un sprint. Algunos de los que puede ser un poco más grande, con un mayor número de artículos más pequeños. Esto le da al equipo la flexibilidad suficiente.

Trabaja con nosotros

Tanto si estás buscando trabajar full time, como suplementar tus actuales ingresos con desarrollos adicionales a los que estás haciendo en tu actual trabajo, o quieres implicarte en el desarrollo de proyectos opensource y apoyar a la comunidad, rellena el formulario que hay a continuación y nos pondremos en contacto contigo para ver los proyectos en los que podemos colaborar.

Trabaja con Nosotros