Preparación de historias de user stories

Una user story (historia de usuario) describe de qué manera un usuario final utiliza una aplicación para lograr un resultado específico. Es una manera de documentar un requerimiento del negocio que está centrada en la persona y tiene un formato simple y conciso. Una user story (historia de usuario) representa la unidad de trabajo más pequeña que se desarrolla dentro de la aplicación.  

La finalidad principal de las user stories (historias de usuario) como artefactos del proyecto consiste en ayudar al equipo de desarrollo a llevar un registro (dentro del backlog del proyecto) de todas las funciones que tienen que desarrollar e implementar para el cliente. Las users stories describen lo que se requiere, de modo que las funciones se diseñen para satisfacer al Product Owner y, en última instancia, al usuario final del negocio. Un equipo crea una user story con el conocimiento y la experiencia colectivos del equipo. 

Características clave de una user story:

• Centrada en la persona
• Fácil de entender
• Refleja de forma clara el valor de negocio que recibe el cliente
• Puede someterse a prueba

Lo primero que usted hace es documentar dos elementos importantes en una user story. Los elementos proporcionan claridad sobre lo que se debe desarrollar y qué criterios se deben cumplir para considerar que la user story está completa.   

Estos dos elementos son:

• Descripción de la user story
• Criterios de aceptación 

Además, agrega elementos opcionales a cada user story para aclarar los detalles del requerimiento con archivos adjuntos y notas técnicas. 

Todas las user stories tienen una estimación y un estado para colaborar con su gestión. Usted actualiza estos parámetros a medida que la user story avanza en su ciclo de vida, desde la forma inicial hasta su compleción.

El objetivo de la descripción de la user story es resumir los requerimientos del negocio del cliente. La descripción de la user story sirve para asegurarse de que usted capture quién necesita la función o característica, para qué se necesita y por qué es necesaria. Tiene que ser breve, estar redactada en un lenguaje de negocio que sea fácil de entender e identificar claramente el valor de negocio.  

La redacción típica de una user story sigue un formato de oración simple:

• En calidad de... [¿Quién? Insertar el usuario]  
• quiero… [¿Qué? Insertar qué quieren hacer]    
• para que… [¿Por qué? Insertar el valor de negocio]

La preparación y los debates relativos a las user stories son sumamente importantes.   Solo puede obtener esta comprensión colectiva mediante el diálogo. Resista la tentación de traducir el entendimiento colectivo en documentación compleja. Céntrese en la esencia de la user story y suplemente los detalles mediante archivos adjuntos.

En el siguiente ejemplo, la descripción está escrita con términos empresariales que explican claramente el usuario, la necesidad y el valor de negocio de implementar la user story. También verá que la descripción es breve.

Los criterios de aceptación refinan la historia de usuario de modo que los desarrolladores entiendan lo que la aplicación debe hacer, y los evaluadores tengan en claro lo que se tiene que probar. El Product Owner debe definir la experiencia de negocio que se espera de la historia de usuario y aprobar los criterios de aceptación. Los criterios de aceptación de la historia de usuario deben redactarse en términos inequívocos que sean fáciles de entender para el negocio (y los miembros del equipo no técnicos). 

Los criterios de aceptación se redactan con términos que reflejen el resultado, y no como instrucciones técnicas para el equipo de desarrollo. Son deliberadamente negociables, lo que le da al equipo de desarrollo la posibilidad de trabajar con el negocio para alcanzar una solución. Si bien los criterios de aceptación son negociables, también deben ser lo suficientemente específicos para ser probados. 

En el siguiente ejemplo, los criterios de aceptación están redactados como resultados que son específicos y comprobables.

El ejemplo de user story ilustra una estrategia para redactar los criterios de aceptación. Hay otros estilos diferentes para documentar los criterios de aceptación, como capturar criterios en función de los escenarios. Por ejemplo, su equipo puede optar por usar el enfoque "Dado que-Cuando-Entonces" con el siguiente formato:

• Dada (Given)...{precondición}: Ejemplo: "Un miembro premium puede optar a promociones de ofertas gratuitas..."
• Cuando (When)...{something is done}: Ejemplo: "...han seleccionado sus categorías de ofertas preferidas y completado el proceso de registro..."
• Entonces (Then)...{resultado esperado} Ejemplo: "...el sistema añadirá automáticamente al socio a las próximas promociones seleccionadas".

Al inicio del proyecto, su equipo determina lo que significa la Definition of Ready (DoR). El equipo se pone de acuerdo en la DoR durante la fase de preparación para establecer los valores de referencia de los controles de calidad de la historia de usuario. Cada proyecto llega a este acuerdo con las partes interesadas comerciales y técnicas relevantes del equipo. La DoR enumera los criterios que debe cumplir para que una user story esté lista para desarrollarse. Una vez que la user story está lista según la DoR, puede marcarla como elegible para la planificación del sprint. 

En general, la DoR es una lista de verificación de criterios. Los criterios definen el contenido que debe estar presente en la user story, cualquier proceso de revisión o las aprobaciones que deben ocurrir, así como también los artefactos que se deben recopilar o adjuntar. La siguiente hoja de cálculo muestra una user story con doce ejemplos de criterios a cumplir.

Una DoR predefinida garantiza que todos los miembros del equipo tengan en claro los requerimientos mínimos de una user story. Confirma que cualquier user story que se colocó en un sprint haya pasado por un control de calidad y se pueda entregar correctamente dentro del sprint.

El objetivo de refinar una user story consiste en garantizar que su equipo tenga una comprensión completa de la intención y el alcance. El refinamiento de la user story es un proceso iterativo que pule el contenido de la historia para alcanzar la DoR. El enfoque de entrega de Pega Express^™ promueve una Direct Capture of Objectives (DCO) para garantizar la colaboración con todas las partes interesadas pertinentes. Se utiliza DCO durante todo el proceso de refinamiento para asegurarse de que cada user story cuente con toda la información, desde todos los puntos de vista. 

El refinamiento de la user story comienza con un borrador de la historia que puede incluir un poco más que una breve descripción. El refinamiento termina cuando le entrega la historia de usuario al equipo técnico para que la estime. 

Borradores de user stories

El Business Architect, el Product Owner y cualquier otra parte interesada pertinente analizan la user story para dejar en claro los objetivos de negocio y los requerimientos del usuario. Una vez que se termina esto, las partes interesadas comparten la user story con el equipo técnico para seguir refinándola.

Refinamiento

Los equipos técnico y de negocio trabajan juntos. Esta colaboración incluye al Product Owner, los Subject Matter Experts (SME), los especialistas en diseño de UX, los especialistas de evaluación, los Business Architects, los System Architects y los especialistas de TI. Los equipos revisan la user story y aclaran los detalles. Pueden ser necesarias varias sesiones de DCO para refinar la user story y que el equipo esté satisfecho con que se ha analizado en detalle y documentado adecuadamente. 

Según la naturaleza de la user story, es posible que tenga que agregar artefactos tales como los siguientes: 

• Correos electrónicos de aprobación de la user story
• Wireframes de UI
• Mapas del proceso y reglas de negocio
• Diagramas de la lógica de la toma de decisiones

Como parte de las sesiones de refinamiento, el equipo técnico interpreta los criterios de aceptación y traduce los resultados a componentes que se tienen que configurar dentro de la aplicación. El equipo técnico también identifica cualquier dependencia que la historia pueda tener con otras user stories, así como el impacto que pueda tener en la funcionalidad existente y en áreas particularmente complejas.

Es posible que el equipo técnico deba tener en cuenta requerimientos no funcionales, tales como los específicos de accesibilidad del usuario. Estos requerimientos pueden perderse si no se documentan dentro de la user story. Durante el refinamiento, el equipo documenta esos detalles en la user story mediante archivos adjuntos adicionales o criterios de aceptación específicos. 

A medida que refina la user story, es posible que note que es demasiado extensa o compleja. En ese caso, divídala en más de una user story.  Por otro lado, su trabajo durante el refinamiento puede exponer una carencia en los requerimientos y generar la necesidad de agregar user stories adicionales a su backlog.

Una vez que se refinan las user stories

El proceso de refinamiento termina cuando:

• El equipo coincide en que entienden la user story.
• Toda la información adicional de respaldo se agregó a la user story.
• El Product Owner aprueba los criterios de aceptación.  

Una vez que se refina, el equipo técnico está en condiciones de estimar la user story.Esta estimación da por finalizada la etapa de refinamiento.

Como parte del proceso de refinamiento, el equipo técnico identifica las tareas técnicas a completar para cumplir con los criterios de aceptación de una historia de usuario. Algunas configuraciones técnicas ameritan especial atención. El equipo puede separar estas tareas del esfuerzo de configuración. Para facilitar la asignación de trabajo dentro de Scrum y garantizar que los componentes reutilizables se construyan con los criterios de aceptación adecuados, el equipo Scrum puede decidir crear una historia técnica que incluya sólo elementos técnicos.  

Algunos ejemplos típicos de historias técnicas:

• Configuración de los conectores de interfaz.
• Bancos de pruebas.
• Repositorio de DevOps.
• Entornos nuevos.
• Otros elementos técnicos requeridos para apoyar múltiples user stories.

Durante el refinamiento, la historia técnica se registra como una dependencia para otras user stories que requieren estos componentes técnicos genéricos. Las historias técnicas permiten que los miembros del equipo trabajen en paralelo para entregar user stories relacionadas en el mismo sprint. El equipo también separa el esfuerzo asociado a crear activos técnicos del esfuerzo asociado a crear soluciones de negocio.

Las historias técnicas están sujetas a las mismas reglas que las user stories en la medida en que:

• Deban cumplir la Definition of Ready para que se las asigne a un sprint.
• Sean estimadas de la misma manera que las user stories no técnicas.

Existen diferentes maneras de reflejar la estimación de una historia. La puntuación de la historia (darle puntos a cada historia) es una actividad que se realiza al final del debate de refinamiento. El objetivo de esta actividad es estimar la complejidad de la historia. Cuanto más alto sea el número, mayores son la complejidad de la historia y el esfuerzo para configurar, probar e implementar la historia. Un enfoque común consiste en usar la secuencia de números de Fibonacci. Esta secuencia permite que el equipo clasifique las historias en términos de complejidad relativa.

La siguiente escala de Fibonacci determina los puntos de la historia:

• 1 punto = Historia muy pequeña
• 2 puntos = Historia pequeña
• 3 puntos = Historia mediana
• 5 puntos = Historia mediana a grande
• 8 puntos = Historia grande
• 13 puntos = Historia muy grande
• 21 puntos o más = La historia debe considerarse una ÉPICA y dividirse en partes más pequeñas.

Cálculo con cubos de complejidad

Lograr una evaluación uniforme de la complejidad de la historia puede ser un desafío, ya que cada miembro del equipo puede ver la complejidad de diferente manera. Puede calcular la complejidad de una historia usando cubos de complejidad (complexity buckets) para darle a su equipo una manera uniforme de estimar las historias analizando cada historia en términos de cubos de complejidad predefinidos antes de elegir los puntos finales.   

Durante la fase de preparación, el equipo debe acordar los criterios más apropiados para evaluar la complejidad de la historia. Cada criterio se convierte en un cubo de complejidad. Dentro de cada cubo, el equipo debe acordar una clasificación de complejidad, que pasa por leve, intermedio y alto o complejo. Por ejemplo, los desarrolladores deben considerar las implicancias de la UI de la historia de usuario, la cantidad de pruebas, la configuración, la cantidad de reglas de negocio y las integraciones de datos a la hora de decidir su número de estimación. Se asigna un valor numérico a cada nivel de complejidad. 

Los cubos de complejidad típicos pueden incluir:

• Interfaz de usuario
• Lógica del negocio 
• Datos
• Aspectos de integración
• Evaluaciones   

Durante la sesión de estimación, el equipo analiza cada historia a la luz de todos los criterios y calcula los puntos totales de la historia en función de la puntuación de complejidad de cada categoría. Al valor total luego se le asigna el número de Fibonacci correspondiente. Cuando los números no coinciden y caen dentro de la secuencia de números de Fibonacci, el equipo acuerda cuál de los números de Fibonacci a cada lado del total representa mejor la complejidad y le asigna ese valor a la historia.

Una vez que se calcula la estimación de la historia de usuario, ya está lista para que la considere el propietario del proyecto en la siguiente sesión de planificación del sprint. 

Una de las preguntas más comunes de un proyecto Agile es "¿Cómo se ve una buena user story?". No existe un modelo único para las user stories; el modelo es diferente para cada equipo. Una variedad de experiencias y trasfondos del sector influyen en los requerimientos colectivos de la user story.   

Los siguientes ejemplos reflejan cómo se vería una buena historia después de ser totalmente elaborada, refinada con el equipo técnico, analizada en función de la DoR y declarada lista para desarrollar. En el ejemplo, busque los siguientes elementos:

• Nombre de la historia
• Descripción 
• Criterios de aceptación
• Estimación de la historia  
• Estado de la historia
• Información adicional 

Compruebe sus conocimientos con la siguiente actividad.