User Stories in Detail Español

Machine Translated by Google
Un documento técnico ágil

por Tirrell Payton.
Historias de usuarios en detalle

Todo lo que quería saber sobre las historias de los
usuarios (pero no se atrevía a
preguntar) por Tir
Versión: 2015-03-15
Copyright © 2014-2015, AgileLeanHouse A/S. Reservados todos los derechos
El contenido de este documento está sujeto a cambios sin previo aviso y no representa un compromiso
por parte de AgileLeanHouse A/S.
AgileLeanHouse A/S no ofrece garantía de ningún tipo con respecto a este material.
AgileLeanHouse A/S no será responsable de los errores contenidos en este documento ni de los daños, incluida la pérdida de
ganancias u otros daños incidentales o consecuentes que surjan del uso de este material escrito.
Ninguna parte de este documento puede ser reproducida o transmitida de ninguna forma o por ningún medio, electrónico o
mecánicos, incluidos los sistemas de fotocopiado, registro o registro y recuperación de información, para cualquier
propósito, sin el permiso expreso por escrito de AgileLeanHouse A/S.
Todas las marcas registradas y no registradas utilizadas en este documento son propiedad exclusiva de sus respectivos
dueños.
ID del documento WP-??-001 Nombre de archivo Todo lo que quería saber sobre las historias de usuarios
150116Denendelige.odt
Autor Revisado 2015-03-15
2 de 33
Tabla de contenidos
1. Creación de historias de usuario ............................................. .................................................... .......5 1.1. Cómo escribir una
historia de usuario ............................................. .............................................5 1.2. Cómo escribir buenas historias de
usuario ............................................... .....................................7 1.3. Cómo desarrollar historias de
usuario ............................................... ..........................................8 1.3.1. Técnica 1: Entrevistas a
usuarios .................................................. .............................9 1.3.2. Técnica 2:
Cuestionarios.................................................... .............................9 1.3.3. Técnica 3:
Observación ............................................... ..........................................9 1.3.4. Técnica 4:
Talleres ............................................... ..........................................10 1.3.5. Los procesos ágiles lo ayudan a integrar requisitos
nuevos y emergentes a lo largo del proceso. 10 1.4. Cómo escribir historias de usuario para
errores .................................. .............................10 1.4.1. Sobre la gestión de
defectos .................................................. ..................................10 1.4.2. Errores como historias de
usuario ........................................... .......................................11 1.4.3. Una mirada desde el
campo .................................................. .......................................11 1.5. Cómo escribir criterios de aceptación de historias de
usuario.................................... .....................16 1.5.1. ¿Qué son los criterios de
aceptación? ............................................... .............................16 1.5.2. Ventajas de los criterios de
aceptación: ............................................... ..........................16 1.5.3. Ejemplo de una Historia de Usuario con Criterios de
Aceptación:.................................... .........16 1.5.4. Creación de criterios de
aceptación ............................................... .............................17 2. Mapeo y gestión de historias de
usuario .................. .................................................... ..........17 2.1. Cómo crear un mapa de historias de
usuario ............................................... ..................................17 2.1.1. En la parte superior de la jerarquía está el
Épico ........................................... ..........................17 2.1.2. A continuación, tienes el flujo de trabajo propiamente dicho, que
se divide en temas..........................17 2.2. Cómo arreglar, agrupar, administrar y organizar historias de
usuario.................................... .........19 2.2.1. 1. Preparar las historias.................................................... .......................................19
2.2.2. 2. Agrupar las historias.................................................... ..........................................20 2.2.3. 3. Administrar las
Historias.................................................... ..........................................20 2.2.4. Siga el modelo DEEP, como lo llama Mike
Cohn. DEEP significa .................................20 2.2.5. Organizar las historias................................................... ..........................................21
2.3. Cómo priorizar las historias de usuario ............................................... .....................................21 2.3.1. Opción 1: Priorizar
por valor del conocimiento........................................... ....................21 2.3.2. Opción 2: Priorizar por aumento de
ingresos ........................................... ..........21 2.3.3. Opción 3: Priorizar por Costo Reducido ........................................... ..........................21
2.3.4. Opción 4: Priorizar por Riesgo Reducido........................................... .........................22 2.3.5. Siempre es un juego de
adivinanzas ............................................. ..........................22 3. División, tamaño y descomposición de historias de
usuario ..... .................................................... .............22 3.1. Cómo descomponer historias de usuario en
tareas.................................... ..........................22 3.1.1. 1. Crear tareas significativas ............................................... .............................23
3.1.2. 2. Use la Definición de Listo como una lista de verificación .................................. ...................23 3.1.3. 3. Cree tareas
que tengan el tamaño adecuado .................................. ..........................23 3.1.4. 4. Evite delinear explícitamente una tarea de prueba
unitaria .................................. ..............23 3.1.5. 5. Mantenga sus tareas pequeñas ............................................... ..........................................23
3.2. Cómo estimar historias de usuario.................................................... ..........................................24 3.2.1. Días
ideales ................................................. .................................................... .24 3.2.2. Puntos de historia/Tamaños de
camisetas.................................... .....................................24 3.2.3. Dimensionamiento basado en el
umbral ........................................... ..........................................24 3.2.4. Prefiero usar una combinación de tallas de camiseta
y estimación de umbral .................25 3.3. Cómo escribir criterios de aceptación de historias de
usuario.................................... .....................25 3.3.1. ¿Qué son los criterios de
aceptación? ............................................... .............................25 3.3.2. Ventajas de los criterios de
aceptación: ............................................... ..........................25 3.3.3. Ejemplo de una Historia de Usuario con Criterios de
Aceptación:.................................... .........25 3.3.4. Creación de criterios de aceptación ............................................... ..........................26
4. Historias de usuarios frente a requisitos .................. .................................................... .........................27 4.1. En qué se
diferencian las historias de usuario de los requisitos .................................. ..............27 4.1.1. Las historias de usuario están
orientadas a objetivos .................................. .............................27 4.1.2. Las historias de usuarios permiten estimaciones
rápidas del nivel de esfuerzo .................................. ......28 4.1.3. Las historias de usuarios permiten un alcance
negociable.................................... ...................28 4.1.4. El estándar IEEE 830 se actualizó por última vez en
1998.................................... ..........28
3 de 33
4.2. Cómo crear historias de usuario a partir de requisitos tradicionales.................................... .....28 5.

Recopilación y comunicación de historias de usuario.................................. .....................................31 5.1.
Cómo ejecutar un taller de historias de usuario.................................... .............................31 5.1.1. 7 pasos
para un taller de historias de usuario exitoso .................................. ..........31 5.2. Cómo explicar y
presentar historias de usuarios.................................................. ..........................32 5.2.1. Paso 1: Presentar
los antecedentes y el caso de negocio.................................... ..........32 5.2.2. Paso 2: Presentar el
problema y el área característica.................................... ...............33 5.2.3. Paso 3: Presentar la historia
de usuario y los criterios de aceptación......................................... ......33 5.2.4. Paso 4: Pregunte al
equipo si tienen suficiente información sobre esta historia de usuario para dimensionarla.........33 5.2.5.
El panorama............................................... .............................................33
4 de 33
1. Creación de historias de usuario
1.1. Cómo escribir una historia de usuario
Para aquellos de nosotros que hemos sido profesionales ágiles durante algún tiempo, a veces olvidamos que no todos están familiarizados con
los términos y la jerga asociada con ágil y scrum. Las historias de usuarios, desafortunadamente, caen en la misma trampa. Todo el mundo
habla de ellos, pero no todo el mundo sabe lo que son. En este artículo te mostraré cómo escribir una historia de usuario.
…
»Me senté en mi cubículo improvisado en un rincón lejano del segundo piso donde pusieron-
a los consultores. Un analista de negocios llega corriendo a mi área: "¡Tengo que escribir
…
historias de usuarios!" Miré fijamente "¿y?" "¡¡Y no tengo idea de cómo escribir uno o incluso qué es!!"
Paso 1: Describe quién quiere la característica El

propósito de una historia de usuario es ayudar a todos a entender QUIÉN quiere QUÉ y POR QUÉ. Cuando hablamos de la OMS, no se trata
solo de quién es el usuario, sino también de cosas como
• ¿Qué hacen día a día?
• ¿Cuál es su nivel de comodidad con la tecnología?
• ¿Qué metas están tratando de lograr?
• ¿Cuáles son los dolores diarios con los que se enfrentan?
Antes de sumergirse en las historias de los usuarios, asegúrese de comprender quiénes son sus usuarios y pueda responder a las preguntas:
5 de 33
ciones anteriores para cada usuario. Ser capaz de describir a sus usuarios de esta manera brinda contexto a la historia del usuario y una base para la
conversación.
Ejemplo de usuario:
Comprador de vacaciones en línea, rara vez compra en línea, excepto durante la temporada de vacaciones.
Comodidad promedio con las computadoras e Internet, pero rechaza la jerga técnica y los mensajes de error de JavaScript. Quieren comprar en línea y
evitar las filas y el tráfico de la experiencia tradicional.
encia
Principales problemas de comercio electrónico: tener que realizar envíos dobles, envíos lentos, procesamiento de pedidos poco claro, tener que llamar al
servicio de atención al cliente para averiguar el estado de un pedido.
Paso 2: Describir lo que quieren La principal

diferencia entre las historias de usuario y otros tipos de requisitos es que las historias de usuario describen la funcionalidad en términos de resultado,
mientras que otros requisitos describen la funcionalidad en términos de resultado , mientras que otros requisitos describen la funcionalidad en la actividad
del sistema. Esto es parte de lo que hace que la historia del usuario sea tan poderosa.
Describa el resultado deseado del usuario en la historia de usuario.
Resultado de ejemplo: El comprador navideño en línea desea poder enviar regalos a una dirección que no es la dirección de facturación de su
tarjeta de crédito.
Paso 3: Describa por qué lo quieren Otra gran

diferencia entre los requisitos tradicionales y las historias de usuario es el contexto, también conocido como el POR QUÉ. El contexto es importante
porque
• Nos ayuda a comprender el valor asociado con la funcionalidad.
• Nos da la oportunidad de explorar otras formas de alcanzar ese objetivo.
Ejemplo de por qué: Online Holiday Shopper quiere poder enviar regalos a una dirección que no es la dirección de facturación de su tarjeta de crédito para
no tener que enviar dos veces su compra
Paso 4: Cree criterios de aceptación en torno a la nueva característica Una historia

de usuario no está completa sin criterios de aceptación. Los criterios de aceptación representan una forma de validar la intención de la funcionalidad al
tener criterios de prueba definidos por adelantado.
6 de 33
Criterios de aceptación de ejemplo: El comprador navideño en línea quiere poder enviar regalos a una dirección que no es la dirección
de facturación de su tarjeta de crédito para no tener que enviar dos veces su compra.
• El usuario puede agregar hasta 10 direcciones en sus 'libretas de direcciones'
• Direcciones internacionales no admitidas
• El usuario puede agregar direcciones en la "configuración de la cuenta" o durante el pago.
• Las tarifas de envío deben volver a calcularse en función de la dirección de envío elegida.
Paso 5: participe en una conversación para completar los

detalles Recuerde, una historia de usuario es la promesa de una conversación futura y no pretende ser un sustituto de que los
miembros del equipo hablen entre sí. Después de tener la conversación, complete los detalles adicionales acordados y discutidos.
Hay algunos puntos clave:
• La historia de usuario no es independiente.
• La conversación es la parte más importante de la historia del usuario.
• Las historias de usuario se elaboran progresivamente.
¿Qué otros desafíos tiene para comprender y crear historias de usuario?
1.2. Cómo escribir buenas historias de usuario
» Una pregunta que surge

mucho es cómo escribir
buenas historias de usuario.
Solo puedo suponer que la
gente ha visto muchos
ejemplos de malas historias de usuarios.
“No podemos usar 'historias de usuario'
para nuestro tipo de trabajo. Es

demasiado complejo y las historias de
los usuarios no contienen suficientes detalles”
"¿Por qué no puedes usar historias
de usuario?"
"¡Porque no podemos construir un
sistema a partir de 50 frases ingeniosas!"
UH oh. Tal vez haya visto esta situación antes, tal vez haya estado en esta situación antes, ya sea como ingeniero o como propietario
de un producto. De cualquier manera, es un lugar difícil para estar. Aquí hay algunos momentos sobre cómo escribir buenas historias
de usuarios.
Consejo 1. No hay historia sin objetivo. Comience por delinear los objetivos de los usuarios en el sistema.
Recuerde, las historias de usuario describen la funcionalidad en términos del resultado o el objetivo del usuario. Una vez que
comprenda lo que el usuario está tratando de lograr, será mucho más fácil crear una buena historia de usuario.
7 de 33
Consejo 2. Incluya metadatos u otros artefactos con la historia de usuario.
» Existe la idea equivocada de que una historia de usuario SOLO puede incluir la historia de usuario, y
no artefactos adicionales según sea necesario.
De manera realista, aún puede usar cualquier cosa valiosa a su disposición para ayudar con el proceso de comunicación. Las
historias de usuario son el comienzo de la conversación, pero no TODA la comunicación.
Consejo 3. Asegúrese de tener un conjunto de tarjetas con las diferentes personas descritas. Si no los tienes, haz
algunos.
Una de las razones por las que las historias de usuario comunican mal es porque todos los usuarios reciben el mismo trato.
¿Cuántas veces has visto “como usuario…” en una historia de usuario? Sin embargo, no existe un sistema de un tamaño no trivial
que no tenga múltiples tipos de usuarios. Comprender quiénes son esos usuarios, cuáles son sus puntos débiles y cómo podemos
abordar esos puntos débiles contribuye en gran medida a poder escribir buenas historias de usuario para esos usuarios.
Consejo 4. Involucrar al cliente en la escritura de las historias.

Cuando nos sentamos para averiguar qué se debe hacer por el usuario (también conocido como el cliente), a menudo evitamos
involucrar al cliente en esas conversaciones. Esto se debe a que creemos que debemos saberlo todo.
Si bien debemos ser conscientes de las necesidades y objetivos de los clientes, la mejor manera de obtener esa información
directamente es hablar directamente con los clientes sobre sus deseos y necesidades. Aún mejor, si puede involucrar al cliente en la
escritura de las historias de usuario (al menos la descripción de alto nivel), tiene muchas más posibilidades de deleitar al cliente con
el producto.
Consejo 5. Mantenga las historias cortas, recuerde, son solo recordatorios para tener la conversación.
Las historias de usuario tienen 3 partes, la tarjeta, la conversación y la confirmación. La conversación es la parte más importante.
Esto podría significar conversaciones con las partes interesadas y los clientes para describir lo que quieren, E incluye conversaciones
con el equipo para articular la necesidad comercial. No hay sustituto para hablar, y uno de los aspectos positivos de Scrum es que
cambia el enfoque de documentar las necesidades del cliente a hablar sobre ellas. Como propietario de un producto, parte de su
"salsa secreta" es poder comunicar una visión, tanto en el sentido amplio como en el sentido pequeño.
Mantenga una mente

abierta Algunos de los desafíos que enfrentan los equipos al escribir y consumir historias de usuario se pueden evitar al no tener una
idea rígida de lo que es una historia de usuario. La historia del usuario es solo un punto de partida para la conversación más importante.
Luego puede desarrollar y agregar detalles para reflejar el entendimiento compartido. ¿Qué tipo de problemas tienes para escribir
buenas historias de usuario?
1.3. Cómo desarrollar historias de usuario
»Me senté en la oficina de Doug. Estaba jadeando. Estaba sudando. Como director de producto
La gerencia, parte de su trabajo, era asegurarse de que sus gerentes de producto supieran lo que
estaban haciendo. La transición a Agile le estaba dando dolor de cabeza, porque ahora todos sus
gerentes de producto tenían que aprender a convertirse en propietarios de productos. Esto
significaba aprender a escribir historias, pero ese no era el único problema.
El problema mucho mayor fue que se presentó una iniciativa importante para cambiar la empresa, y
8 de 33
todos, incluido el director ejecutivo, dependían de que esta iniciativa fuera un éxito. El proyecto ya había
comenzó, y los propietarios de productos luchaban por descubrir cómo desarrollar historias de usuarios. Intentaron sentarse en una
habitación con los analistas de negocios creando requisitos, pero no eran muy buenos ni muy prácticos.
En este artículo, presentaré 4 técnicas sobre cómo desarrollar historias de usuario.
1.3.1. Técnica 1: Entrevistas a usuarios

La mayoría de los usuarios no tienen idea de lo que necesitan.
Si presionas a los usuarios, obtendrás respuestas,
pero lo más probable es que solo den una idea
superficial de lo que se necesita.
Los usuarios son muy buenos para identificar sus
problema, pero no muy bueno para identificar una
solución.
Realice entrevistas 1 a 1 y en grupos pequeños para

hablar sobre los dolores de los usuarios. Pagar
presta mucha atención a los problemas, pero toma las soluciones propuestas con pinzas. Use el juicio y la comprensión para tomar esos
problemas y convertirlos en historias de usuarios.
1.3.2. Técnica 2: Cuestionarios

Los cuestionarios son buenos si tiene un
población de usuarios considerable. yo he tenido
gran éxito en el uso de cuestionarios para
recopilar información para grandes ERP y
Implementaciones PLM. Sin embargo, ser
cuidadoso en el uso de cuestionarios como
principal medio de comunicación con
usuarios para recoger sus problemas. En
comparación con una entrevista 1 a 1, hay pocas
oportunidades de seguir pistas y contexto. Su única
herramienta es la respuesta en
El cuestionario.
Asegúrese de que sus cuestionarios estén bien escritos, con preguntas específicas que puedan ayudarlo a identificar mejor
tendencias entre su base de usuarios.
1.3.3. Técnica 3: Observación

La observación directa es genial, y cuando
emparejado con entrevistas a usuarios, crea un
1-2 golpes que te ayudan a desarrollar tu
historias de usuario de una manera más directa.
Esto es más fácil cuando está desarrollando
soluciones internas, como observación en el sitio
para clientes remotos.
podría tener un costo prohibitivo.
Ir al lugar donde el usuario suele trabajar,

y observar sus hábitos. Preste atención a los
pasos que toman en el sistema y compárelos
con lo que realmente buscan lograr en el día a día. Observar
qué tan cómodos se sienten con la tecnología en general, y busque formas en que pueda hacerlos más exitosos en su trabajo diario.
9 de 33
1.3.4. Técnica 4: Talleres

Un taller para desarrollar historias de usuario es un
reunión que tiene el equipo completo más
partes interesadas del usuario final. Durante esta
reunión, los usuarios escriben tantas historias como
pueden pensar. Realización de talleres
es una manera muy eficaz de reunir una gran
número de historias rápidamente.
Después de que haya una gran cantidad de historias,

querrá mapearlos en el usuario
fluye Mientras camina a través del usuario
flujos, haga preguntas como:
• ¿Qué querrá hacer el usuario a continuación?
• ¿Qué errores podría cometer el usuario aquí?
• ¿Qué podría confundir al usuario en este punto?
• ¿Qué información adicional podría necesitar el usuario?
1.3.5. Los procesos ágiles lo ayudan a integrar requisitos nuevos y emergentes

a lo largo del proceso
Al comienzo de su liberación, usted
todavía debe tomar algún tiempo para llevar a cabo
algún tipo de ejercicio para desarrollar tu
conjunto inicial de historias. En lugar de confiar en
una forma de desarrollar su usuario
historias, debes usar una combinación
de todos los enumerados aquí, más cualquier
otros que se te ocurran.
¿Cuáles son otras formas de desarrollar historias de usuario?
1.4. Cómo escribir historias de usuario para errores
»Estaba terminando una semana de capacitación con uno de mis clientes y, según todos los informes, fue
una semana estelar. La gente estaba emocionada y motivada para saltar de cabeza a Scrum, y los
propietarios de productos estaban emocionados de comenzar a escribir historias. Uno de los
líderes tecnológicos se me acercó y me dijo: "¿Qué pasa con los errores?" "¿Qué quieres decir?"
"Quiero decir, ¿escribimos historias de usuarios para errores?" "Si quieres. No es absolutamente
necesario, pero si tienes 10 minutos podemos charlar al respecto”.
¿Debería un equipo escribir historias de usuarios para errores? Debe hacer esto solo si expresa los errores en forma de historia de usuario
tiene valor Las historias de usuario son útiles pero no siempre necesarias.
1.4.1. Sobre la gestión de defectos

La gestión de defectos es una de las áreas en las que las empresas tienden a tropezarse tratando de descubrir
“Qué ágil dice que deberíamos hacerlo”. Da un paso atrás en el proceso y mira la meta. La meta es
Entregar software funcional que satisfaga las necesidades del cliente. En muchos casos, la administración no es un valor agregado
pero componente necesario de la entrega. Queremos minimizar esto donde podamos y cuando no podamos
10 de 33
mízalo, asegúrate de que tenga valor.
» Entonces, en lugar de preguntar: "¿Deberíamos escribir errores como historias de usuarios?", pregúntese:
"¿Escribir errores como historias de usuarios agregaría algún valor a la entrega de software a nuestros clientes?".
Cuando formula esta pregunta y muchas otras preguntas de esta manera, la respuesta se vuelve obvia.
Incluso si elige la respuesta incorrecta, siempre puede retrospeccionar y cambiarla.
1.4.2. Errores como historias de

usuarios Entonces, en este artículo, le mostraré cómo escribir historias de usuarios para errores, en caso de que decida seguir esa ruta.
Cada informe de error debe considerarse su propia historia, especialmente si es probable que solucionar el error lleve tanto tiempo como una
historia típica (2 días más o menos). Para los errores que son menores y se pueden solucionar rápidamente, estos se pueden combinar en una
sola historia de errores.
Paso 1. Use "Sin" en la descripción de su historia de usuario Ejemplo:

El administrador desea iniciar sesión desde un dispositivo móvil sin tener el panel de administración aplastado e ilegible. Lo que esto
hace es delinear el comportamiento que NO desea (el error) desde la perspectiva de su impacto en el usuario.
Paso 2. Describa los "Pasos para reproducir" en los detalles de su historia.

Esto reitera las condiciones que ayudarán al desarrollador a comprender cómo crear el error y ayuda con las pruebas.
Ejemplo: al administrador le gustaría iniciar sesión desde un dispositivo móvil sin tener el panel de administración aplastado e ilegible. Lo que esto
hace es delinear el comportamiento que NO desea (el error) desde la perspectiva de su impacto en el usuario.
• Con Android o iPhone, inicie sesión en el panel de administración
• Resultado esperado: panel receptivo
• Resultado real: panel aplastado (inutilizable)
Paso 3. Invierta la descripción de la historia en sus criterios de aceptación.

Ejemplo: el administrador desea iniciar sesión desde un dispositivo móvil sin tener el panel de administración aplastado e ilegible.
• Con Android o iPhone, inicie sesión en el panel de administración
• Resultado esperado: panel receptivo
• Resultado real: panel aplastado (inutilizable)
Criterios de aceptación
• El usuario puede iniciar sesión en el panel de administración en un dispositivo móvil y se podrá utilizar
• El panel de administración se adaptará a varios tamaños de pantalla.
• La visualización de informes se desactivará en dispositivos móviles, pero el usuario tiene la opción de enviar un pdf a su correo electrónico.
1.4.3. Una vista desde el campo A algunos

equipos les gusta escribir sus errores como historias de usuarios, ya otros no. Como casi todo, depende del contexto, el entorno, la
industria, el tamaño de la empresa y muchas otras variables. ¿Qué pasa con sus equipos? ¿Escribes historias para bichos?
11 de 33
12 de 33
13 de 33
14 de 33
15 de 33
1.5. Cómo escribir criterios de aceptación de historias de usuario

Cuando trabajo con mis clientes que ya han comenzado a adoptar Agile, uno de los primeros elementos que observo
es su cartera de pedidos. ¿Por qué? Debido a que la calidad de la cartera de pedidos es un indicador principal de qué tan bien el equipo
llevar a cabo. Desafortunadamente, la mayoría de los retrasos creados por los propietarios de productos principiantes no están en condiciones de ser estafados.
asumido por un equipo, y la razón número uno de esto suele ser la falta de criterios de aceptación en el usuario
cuentos. En este artículo hablaré de:
• ¿Qué son los criterios de aceptación?
• Por qué son importantes
• Suero funcionan bien
• Cómo crearlos
1.5.1. ¿Qué son los criterios de aceptación?

Los criterios de aceptación son declaraciones de requisitos que se describen desde el punto de vista del usuario.
para determinar cuándo una historia está "terminada" y funciona como se esperaba.
Esto ayuda al equipo a reducir el riesgo al realizar pruebas con los mismos criterios que se acordaron cuando el equipo
aceptó el trabajo. Los criterios de aceptación están surgiendo y evolucionando y se supone que son lo suficientemente flexibles para
cambiar hasta que el equipo comience a trabajar en la historia.
» Cualquier miembro del equipo, como analistas comerciales, control de calidad y desarrolladores, puede ayudar al PO en ambos
crear y revisar los criterios de aceptación.
1.5.2. Ventajas de los criterios de aceptación:
• Activa el proceso de pensamiento para que el equipo piense en cómo funcionará una característica del usuario final.
perspectiva
• Ayuda al equipo a escribir los casos de prueba precisos sin ninguna ambigüedad para comprender el negocio.
valor.
• Elimina el alcance innecesario que no agregará valor a la historia, en otras palabras, mantendrá la
contenido correcto.
1.5.3. Ejemplo de una Historia de Usuario con Criterios de Aceptación:

Al cliente le gustaría que le enviemos un correo electrónico a mi dirección de correo electrónico normal cuando su cuenta entre en sobregiro para que sepa que
necesito depositar dinero en mi cuenta.
Al cliente le gustaría que le enviemos un correo electrónico a mi dirección de correo electrónico normal cuando su cuenta entre en sobregiro para que sepa que
necesito depositar dinero en mi cuenta.
Criterios de aceptación:
EntradaProcesoSalida
Dirección de email válida Mensaje de validación de correo electrónico enviado a la dirección de correo electrónico
Dirección de correo electrónico no válida Validación de correo electrónico Marque el perfil en línea como incompleto, envíe un mensaje de correo postal.
Dirección de correo Mensajería de mercadeo La copia del mensaje de marketing coincide con la copia proporcionada por mar
electrónico válida
Dirección de correo electrónico Mensajería de mercadeo El diseño del mensaje de marketing coincide con las especificaciones proporcionadas
válida por marketing
Puerta de entrada de dirección de Mensajería de mercadeo El mensaje contiene un enlace de correo electrónico que permite al usuario navegar
correo electrónico válida a la banca en línea
En el ejemplo anterior, los criterios de aceptación son un conjunto de declaraciones que representan las "condiciones de satisfacción" de los requisitos. También
contiene límites y parámetros que determinan cuándo se escribe una historia.
16 de 33
completo y listo para su aceptación. Se expresó claramente en un lenguaje sencillo para el cliente sin ninguna ambigüedad sobre lo que se espera
como resultado. Debe ser fácilmente accionable y traducirse en uno o más casos de prueba manuales/automáticos.
Cuando el equipo de desarrollo ha terminado de trabajar en la historia de usuario, le muestran la funcionalidad al propietario del producto, mostrando
cómo se satisface cada criterio.
1.5.4. Creación de criterios de aceptación

Los criterios de aceptación constan de 3 partes: entrada, proceso y resultado. Una forma útil de pensar en los criterios de aceptación es: “Cuando
<ingreso> X y <proceso>Y, comprobaré el <resultado>Z como resultado”.
Las entradas de los criterios de aceptación son cosas como "ingresar un valor y presionar un botón" o "ingresar un comando y verificar los resultados".
El proceso de criterios de aceptación es el cálculo real que se está comprobando. Por lo general, cuando creamos una historia de usuario, queremos
que suceda algo para un conjunto determinado de entradas de un usuario. Ese proceso, aunque generalmente no es directamente observable, es
verificable para un conjunto dado de entradas y salidas esperadas.
El resultado (resultados) de los criterios de aceptación siempre debe ser comprobable con una ambigüedad mínima.
Cuando las personas piensan en historias de usuarios, generalmente piensan en términos de la descripción de la historia de usuario. Sin embargo, la
historia de usuario no está completa hasta que tenga criterios de aceptación verificables. Los criterios de aceptación también ayudan al equipo a
dimensionar rápidamente una historia de usuario, porque una vez que saben cómo se verificará la historia, entienden el esfuerzo necesario para que
suceda. Utilice criterios de aceptación con cada historia de usuario.
2. Mapeo y gestión de historias de usuario
2.1. Cómo crear un mapa de historias de usuario
» Me detuvo en el pasillo, los labios apretados, el ceño fruncido, las

manos en un torbellino de locura gesticulante. No tuvo que abrir la
boca para que yo comenzara la conversación, "Hola Anita, ¿cómo
estás?" “No es bueno, tengo todas estas historias de usuarios que
crearon los analistas de negocios, pero no tenemos idea de cómo
organizarlas”. ” En este artículo, hablaré sobre cómo escribir un story map.
Un User Story Map es una representación de un conjunto de historias de usuarios en 2 dimensiones:
• Secuencia
• Prioridad
2.1.1. En la parte superior de la jerarquía está la Épica.

Un Epic es una actividad grande que tiene valor para el usuario, como "Comprar un boleto de avión". Algunos prefieren usar el formato de historia de
usuario para crear epopeyas, pero a mí realmente no me importa. Solo queremos usar una frase u oración que capte el espíritu de lo que queremos
lograr.
2.1.2. A continuación, tiene el flujo de trabajo en sí, que se divide en temas.

Un tema es una colección de historias relacionadas, y los temas corresponden aproximadamente a los pasos del flujo de trabajo necesarios para
cumplir con los esquemas de valor en Epic. Aquí hay un ejemplo, usando compras de boletos de avión:
Compra un boleto de avión
17 de 33
• búsqueda de vuelos
• Opciones del carrito de compras
• Opciones de pago/pago
• Opciones de cumplimiento
• Opciones de posventa
“Compre un boleto de avión” es la epopeya, y la epopeya se divide en una serie de temas, como “búsqueda de vuelos” y “opciones de carrito
de compras”.
Luego, cada tema se divide en un conjunto de historias que se organizan en orden de prioridad. Es más probable que los elementos que se
encuentran cerca de la parte superior de la prioridad se implementen primero. Es más probable que los otros se implementen más tarde. La
capa superior de las historias representa las características comercializables mínimas.
» Un story map no es un plan de lanzamiento. Nos ayuda a ver la amplitud y profundidad de las historias a ser
implementado y simplemente influye en el plan de liberación.
Un buen mapa de la historia:
• Nos muestra el flujo de actividades desde la perspectiva de los usuarios.
• Informa sobre las necesidades de arquitectura/infraestructura
• Describe la relación entre las historias de los usuarios.
Paso 1: Resuma los objetivos principales (epopeyas).

Estos son su nivel más alto de valor de usuario. Para llegar a estos objetivos principales, piense como un usuario no técnico. Los usuarios
tienden a describir las aplicaciones en términos amplios, no técnicos y fáciles de entender que representan valor.
• Facebook me permite estar en contacto con mi familia
• Mint me ayuda con el presupuesto
• Evernote me permite tomar notas en cualquier lugar
Estas epopeyas son el mismo lenguaje que usaría para describir la funcionalidad a su madre oa un amigo que no trabaja en la industria de la
tecnología.
18 de 33
Paso 2: para cada épica, describa el flujo de usuarios de principio a fin.

Comience por delinear los pasos. A veces esto es difícil. Después de crear un paso, pregúntese: “Entonces, ¿qué
sucede? Esto te llevará al siguiente paso. Haz el flujo primero antes de sumergirte en las historias.
Paso 3: para cada tema, describa y priorice las historias de usuario asociadas con ese tema.
Después de haber delineado los pasos, comience a pensar en las diferentes formas de lograr ese paso. Aquellas
serán tus historias. Para cada historia, considere escenarios de "qué sucede si...", que profundizarán al usuario
lista de historias Habrá algunas historias que obviamente son de alta prioridad y otras que no. A menudo durante
mapeo de historias aparecen nuevas historias al mirar el problema desde un ángulo diferente (horizontal y ver tical).
Trata el mapa como un artefacto vivo

¡Felicitaciones, ahora tiene un story map! Los story maps son muy útiles para crear al principio de un
proyecto y útil para la planificación del lanzamiento. Como todos los artefactos ágiles, los story maps son artefactos vivos. Hacer
asegúrese de volver a visitar el mapa de la historia cada pocos sprints para agregar/actualizar historias y reflejar nuevas historias y nuevos
lecciones de la ejecución del proyecto.
2.2. Cómo preparar, agrupar, administrar y organizar historias

de usuarios
» Muy a menudo, observo a los miembros del equipo conversando en retrospectivas,

“tenemos que esperar a que el Product Owner aclare los requisitos, y está consumiendo
mucho tiempo y retrasando nuestro trabajo en el Sprint. En los "buenos viejos tiempos"
teníamos un documento de especificación de requisitos que eraque
Es imperativo fácilmente
los equiposmanejable.
se enfrenten a” una
tarea cuesta arriba para administrar cientos de historias en su cartera de pedidos.
Estuve reflexionando sobre este problema por un tiempo y entendí que a los equipos les falta algo muy importante.
ceremonia en el sprint llamado "Preparación de la cartera de productos" que ayudaría a preparar, agrupar, administrar y organizar las
historias de usuario.
En resumen, la cartera de productos es la única fuente de requisitos en Agile, es una lista ordenada de requisitos y la mayoría de los
elementos de esta lista son las historias de los usuarios. Necesita ser arreglado continuamente
cada vez que veas la necesidad de hacerlo.
Aquí hay algunas técnicas para un equipo que pueden facilitarles la vida cuando se trata de las historias de los usuarios.
2.2.1. 1. Prepara las historias
» Los equipos tendrán que pasar al menos el diez por ciento del tiempo durante su iteración, con
el propietario del producto para comprender las historias existentes en términos de claridad, viabilidad y
adecuación en la iteración. Si la historia es grande, entonces necesitan trabajar con el propietario del producto
para dividirla en partes más pequeñas, manejables en la iteración. Marca las historias
19 de 33
como listo para el sprint después de esta reunión, de modo que no haya ida y vuelta durante
la iteración.
Elimine las historias de la cartera de pedidos que ya no se necesitan.
Aclarar las historias elaborando las condiciones de satisfacción según se requiera.

Estimar las historias con los hechos más conocidos en ese momento.
Ajuste la prioridad de la historia con el permiso del propietario del producto. La actividad de preparación es muy esencial para mantener
la acumulación de productos, de lo contrario, se volvería inmanejable.
2.2.2. 2. Agrupa las historias

Podemos agrupar lo relacionado bajo un mismo paraguas que nos ayude a visualizar el progreso de las historias. Por ejemplo, tenga
todas las historias relacionadas con las plantillas de informes en el grupo "informes", todas las historias relacionadas con la administración
de usuarios en el grupo "administración de usuarios", etc. Esta agrupación de historias se denomina "Temas" en Agile.
Cree grupos de alto nivel cuando comience a obtener los requisitos e intente agrupar las historias en consecuencia a medida que agregue
nuevas historias a la cartera de pedidos. Algunas herramientas como Rally admiten una relación padre-hijo y una relación sucesor-
procesador que admite la agrupación de historias de usuario.
2.2.3. 3. Administrar las Historias

La gestión de las historias es muy sencilla. Para cada historia en la cartera de pedidos, los siguientes atributos que ayudarían a obtener
los detalles completos de los orígenes de la historia, lo que hará que sea muy fácil de rastrear.
• Descripción de la historia de usuario
• Criterios de aceptación
• Historia de usuario principal
• Prioridad
• Suposiciones
• Dependencias
• Asignado a
• Estimar
• Equipo asignado a
• Grupo (si esta historia está agrupada)

• Tareas asociadas
• Pruebas asociadas
• Estado: Listo, En progreso, completado, bloques, etc. Impedimentos, etc.
2.2.4. Siga el modelo DEEP, como lo llama Mike Cohn. PROFUNDO significa
Detallado
Apropiadamente Máxima prioridad, más detalles; menor prioridad, menos, que se dividen en historias más pequeñas para sprints/
lanzamiento.
Emergente
Creciendo y evolucionando con el tiempo; Se vuelve a priorizar cuando se agregan/eliminan elementos.
Estimado
Los elementos de la cartera de productos son estimados. Las estimaciones son de grano grueso y, a menudo, se expresan en puntos de
la historia.
priorizado
Elementos que están programados para los próximos sprints
20 de 33
2.2.5. Organice las historias Organizar

las historias es fácil, tenga trabajos pendientes específicos del equipo. Tenga las historias que están relacionadas con
su equipo solo en su cartera de pedidos. Los temas también se utilizan para organizar historias para lanzamientos.
Vincule las historias de su equipo de las que depende con otro equipo, de esa manera, conocerá el estado de otras
historias vinculadas. Tenga conversaciones frecuentes con el propietario del producto para priorizar y volver a priorizar
las historias. Ayuda a tu Product Owner a eliminar las historias que no pertenecen a tu equipo.
Imagine su césped en el patio trasero, ¿cómo lo mantiene? Tiene que ser mantenido regularmente? Si no, en algún momento se vuelve inmanejable, crece al
azar en todas las direcciones, lo que dificulta su mantenimiento. Del mismo modo, la limpieza del trabajo pendiente no es un esfuerzo de una sola vez.
¿Cree que necesita regar conscientemente su césped, podarlo y abonarlo para que luzca saludable? Si no lo hicieras, ¡imagínate lo que podría pasar!
2.3. Cómo priorizar historias de usuarios
» Su rostro era severo, y su

La voz tenía un aire de seriedad:
“No creo que lo entiendas del
todo. En nuestro negocio, todo
es prioridad”.
yo
Si tuviera un dólar por cada vez que escucho esto, sería un hombre muy rico. Sí, todo es prioridad. Todo es siempre prioridad porque tiene un gran grupo de
partes interesadas y todos quieren sus cosas primero, por lo tanto, todo es prioridad.
Siendo realistas, no se puede hacer todo al mismo tiempo, por lo que aunque “todo sea prioritario”, algunas cosas vendrán primero y otras vendrán al final.
Una palabra más suave para prioridad es "orden", pero en este artículo le mostraré cómo priorizar las historias de los usuarios.
2.3.1. Opción 1: Priorizar por valor de conocimiento

Al comienzo de un proyecto, lo que no sabes te puede hacer daño. Eliminar las incógnitas es una gran oportunidad para impactar positivamente en la salud
del proyecto a lo largo del tiempo. Para priorizar el valor del conocimiento, debemos estar dispuestos a admitir que no tenemos todas las respuestas a las
incógnitas. Después de hacer eso, podemos priorizar algunos de los elementos de "valor de conocimiento" en la cartera de pedidos, como picos y prototipos.
2.3.2. Opción 2: Priorizar por aumento de ingresos Esta siempre es

una clara ganadora, pero depende en gran medida de la sofisticación del propietario del producto para poder articular
el ROI asociado con una característica o historia de usuario. Por lo tanto, este debe ser uno de los elementos en los
que se piense al priorizar. Un ejemplo de esto serían las opciones de pago.
»“El 15 % de nuestros ingresos provino de Paypal en la última versión de este producto, por
lo que es lógico que el 15 % de nuestros ingresos continúe proviniendo de Paypal. Por
otro lado, solo el 5% de nuestros ingresos provinieron del débito ACH, por lo que la
funcionalidad de Paypal tendrá una prioridad mayor que la funcionalidad ACH”.
2.3.3. Opción 3: Priorizar por Costo Reducido

Este es otro que es fácil de articular y fácil de defender, pero requiere un poco de investigación y procesamiento de números para tener una base sólida. La
reducción de costes o la reducción del “Costo total de propiedad” suele ser uno de los motores de los nuevos proyectos. Un ejemplo de reducción de costes
sería cambiar de plataforma:
21 de 33
» La plataforma antigua cuesta 10 céntimos por transacción y la nueva plataforma cuesta 7 céntimos por transacción.
Trasladar la funcionalidad a la nueva plataforma nos ahorrará un 30 % por transacción y
hacer más de 1 millón de transacciones por mes.
2.3.4. Opción 4: Priorizar por Riesgo Reducido

Hay todo tipo de riesgos del proyecto a tener en cuenta: Riesgo técnico (¿esto se puede hacer?), Riesgo social (¿se puede
estas personas lo hacen) y Riesgo de Ejecución (¿aceptará esto el mercado?). Elementos en su backlog que pueden
apuntar a un riesgo reducido se puede priorizar de acuerdo con la magnitud y la probabilidad del riesgo en sí.
Aquí hay un ejemplo:
» El estado nos multa con un recargo dependiendo de cuán preciso sea nuestro procesamiento de pagos
de reclamos. Esta funcionalidad reducirá los errores de reclamos en un 30%, reduciendo el riesgo de
incumplimiento.
2.3.5. Siempre es un juego de adivinanzas.

La priorización es siempre un juego de adivinanzas, y debe encontrar el equilibrio entre obtener una prioridad perfecta y ser lo suficientemente flexible como
para dejar que el trabajo surja. Nunca esperes obtener una prioridad perfecta. Algunos
las partes interesadas siempre estarán insatisfechas con la forma en que se hizo. Siempre que tenga un marco para guiar
su forma de pensar, puede defender las opciones cuando se le pregunte.
3. División, tamaño y descomposición de

la historia del usuario
3.1. Cómo descomponer historias de usuario en tareas

• Recientemente estuve mirando la acumulación de sprint de un equipo, que acababa de comenzar su viaje ágil. Cuando yo
miré el desglose de tareas de las historias de usuario, noté algo como esto.
Historia del usuario:
Codificación
Pruebas
Registrarse
Construir
Manifestación
Al observar este desglose de tareas, se sintió como un proceso secuencial con pasos definidos como tareas para una historia. También noté que cada
historia tenía el mismo desglose de tareas con diferentes estimaciones de esfuerzo. Estaba mirando sus criterios de hecho de una historia. Realmente
no pude relacionar su Definición de Listo (DoD) y su desglose de tareas. Inmediatamente, le pregunté a uno de los miembros del equipo: “¿Cómo se
asegura de completar todas las tareas enumeradas en el Departamento de Defensa?
“
Me miró con una sonrisa confusa y dijo: “¡Simplemente lo hacemos! ¡A veces había tareas, olvidamos algunas
de ellas y las completaremos en el próximo sprint!”
¡Ay! Aquí está la trampa…
Veo que el desglose de tareas del equipo solo refleja un proceso secuencial y no transmite ninguna
22 de 33
algo significativo acerca de lo que está sucediendo con esa historia! Además, la tarea “Codificación” no indica qué parte de la codificación se
completó para una historia específica.
¡También encontré un patrón similar de división de tareas con la acumulación de sprints de otros equipos!
De alguna manera, encuentro que muchos equipos están luchando para hacer una tarea efectiva a partir de una historia de usuario.
Una tarea es una parte de la actividad que se requiere para terminar una historia.
Estos son algunos consejos efectivos para desglosar una historia de usuario en tareas.
3.1.1. 1. Crea tareas significativas

Describa las tareas de tal manera que transmitan la intención real. Por ejemplo, en lugar de decir Codificación, describa las tareas como "Desarrollar la
clase de inicio de sesión", "Desarrollar la parte de secuencias de comandos para la funcionalidad de inicio de sesión", "Desarrollar el cifrado de contraseña
para la funcionalidad de inicio de sesión", "Crear una tabla de usuarios y guardar los datos de inicio de sesión".
a DB”, etc. Tales tareas son más significativas que simplemente codificar y probar.
3.1.2. 2. Use la Definición de Listo como una lista de verificación

Veamos qué es un DOD muy rápidamente. El DOD define los criterios de integridad de una historia. Incluye todos los elementos que deben completarse
para afirmar que la historia está hecha por el equipo de desarrollo. Un ejemplo sencillo:
• Los criterios de aceptación se verifican durante las pruebas.
• Tareas de codificación completadas.
• Pruebas Exploratorias completadas y firmadas.
• Prueba de regresión revisada y aprobada.
• Pruebas unitarias: escritas y aprobadas.
• Revisiones de código realizadas.
• Los defectos se encuentran en un estado "aceptable" para el propietario del producto.
• Historia de usuario aceptada por el propietario del producto.
• Pruebas de regresión ejecutadas y aprobadas
• Ejecución de pruebas de humo/automatización (si corresponde)
• Comprobar si hay fugas de memoria
• Las pruebas unitarias automatizadas están registradas.
» Ahora, ¿cómo se asegura de que el equipo realice todos los elementos del DOD? Una forma
es usar el DOD como una lista de verificación para crear tareas para la historia de usuario
para que el equipo pueda tomar cada una de ellas y completarlas sin olvidarlas.
3.1.3. 3. Cree tareas que tengan el tamaño adecuado

Otro síndrome que he visto son las tareas que son muy pequeñas, desglosadas en minutos, como tareas de 10 min, 30 min, 5 min, por ejemplo: escribir,
aceptar nombre de usuario, contraseña, validar inicio de sesión y dar mensajes de error. Romper las historias de los usuarios con demasiados detalles es
una sobrecarga. ¿Cuál es el tamaño ideal de las tareas?
Una pauta es tener tareas que abarquen menos de 8 horas para que cada una de ellas se pueda completar en al menos un día.
3.1.4. 4. Evite delinear explícitamente una tarea de prueba unitaria

Si es posible, haga que las pruebas unitarias no sean una tarea separada, sino parte de la tarea de implementación en sí. Esto anima a las personas a
practicar el desarrollo dirigido por pruebas como enfoque. Sin embargo, esta práctica puede no ser ideal para los nuevos equipos Scrum.
3.1.5. 5. Mantén tus tareas pequeñas

No tenga tareas que abarquen varios días juntos. Hace que sea difícil saber el progreso real.
23 de 33
En algunos equipos maduros, he visto, no hacen el desglose de tareas en absoluto. Simplemente extraen las historias de los usuarios y las
completan, pero es un viaje para los nuevos equipos de Scrum llegar allí, y requiere un equipo fuerte y cohesionado y muchos sprints de trabajo en
conjunto.
Entonces, ¿con qué frecuencia cree que, como equipo, debe volver a visitar el Departamento de Defensa, para que su desglose de tareas
pueda cambiar?
3.2. Cómo estimar historias de usuario

3.2.1. Días ideales
Los días ideales son la forma más común de estimar en la
gestión de proyectos tradicional.
Al estimar en días ideales, la suposición es “Este es el
tiempo que tomaría si tuviera
nada más en lo que trabajar”.
Los días ideales generalmente se usan en conjunto

con algún tipo de “coeficiente de eficiencia”
mediante el cual alguien toma los días ideales y
los multiplica por el número de reales
Días ideales que puedes conseguir en una semana. Por
ejemplo, en 5 días hábiles obtengo 3 días ideales de
trabajo realizado, por lo que el coeficiente es 3/5. Por lo tanto,
si estimo este trabajo en días ideales y
llámalo un 3, me llevará una semana.
»No soy muy partidario de usar los días ideales como método de estimación por varias razones:
» Cada vez que usa el tiempo del calendario para estimar, sin importar la advertencia, tiende a usarse como un
compromiso. Estimaciones != compromisos, especialmente en trabajos complejos-creativos.
»Crea una métrica de vanidad que distrae: obtener días ideales para que coincidan con los días del calendario (dis
disfrazado como una búsqueda de “eficiencia”). Con esto, en lugar de centrarse en entregar valor, el
los equipos se enfocan en “hacer que los números coincidan”
3.2.2. Puntos de historia/Tamaños de camiseta

Los puntos de la historia son una forma de desvincular la estimación del tamaño y el esfuerzo de la duración del tiempo. En lugar de tratar de
estimar cuánto tiempo tomará algo, usted estima qué tan grande es y deja que sus datos de velocidad le digan cuánto tiempo tomará.
Si no tiene datos de velocidad, haga su mejor suposición en términos de cuánto trabajo puede hacer un equipo en un sprint, luego mida el
real cuando tenga datos reales.
Me gustan los puntos de la historia como una práctica de dimensionamiento porque una vez que los equipos se dan cuenta de cómo desacoplar
el tiempo y el esfuerzo, es fácil estimar grandes cantidades de trabajo rápidamente.
» Tenga cuidado: no es una buena práctica tratar de asignar puntos de la historia a días directamente. El objetivo
del desacoplamiento es comprender el cambio en la relación entre el tiempo y los puntos, que cambia a medida
que los equipos mejoran, agregan nuevos miembros, se reconfiguran, etc.
3.2.3. Dimensionamiento basado en umbral

Otra forma de dimensionamiento que me gusta usar es el "dimensionamiento basado en el umbral". Aquí es donde establecemos un umbral
(digamos 3 días) y cuando lo estimamos, solo nos interesa obtener historias por debajo del umbral. Esto elimina las distracciones relacionadas
con la precisión (2,3 días frente a 2,8 días) y mueve las historias hacia un tamaño estándar.
Para las historias que están por encima del umbral, las dividimos, disminuimos el alcance o recortamos la funcionalidad hasta que estén por debajo
del umbral.
24 de 33
3.2.4. Prefiero usar una combinación de tallas de camiseta y umbral

Estimacion
En el nivel de lanzamiento, me gusta usar tallas de camisetas gruesas: XL, XXL, XXXL
En el nivel de sprint, me gusta ver tallas de camiseta más pequeñas y granulares: S, M, L
Cuando entramos en la planificación del sprint, tomo las historias programadas para ese sprint y aplico el método de umbral,
como una doble verificación. Al aplicar el umbral, utilizo la regla de 1, 2, 3:
• 1 historia de usuario debe tomar
• 2 personas no más de
• 3 días
Tal vez sea un desarrollador y un probador, tal vez sea un desarrollador front-end y un desarrollador back-end, o tal vez sus 2
desarrolladores de pila completa. La composición de las 2 personas que trabajan en el entregable realmente no me importa. Lo que
me importa es que estamos difundiendo el conocimiento en el equipo para que no terminemos
en una situación en la que "Solo una persona sabe sobre esto..."
¿Cuáles son algunas otras formas de estimación que has visto?
3.3. Cómo escribir criterios de aceptación de historias de usuario

Cuando trabajo con mis clientes que ya han comenzado a adoptar Agile, uno de los primeros elementos que observo es su cartera
de pedidos. ¿Por qué? Porque la calidad de la cartera de pedidos es un indicador principal de qué tan bien se desempeñará el equipo.
Desafortunadamente, la mayoría de los trabajos pendientes creados por los propietarios de productos principiantes no están en
condiciones de ser consumidos por un equipo, y la razón principal de esto suele ser la falta de criterios de aceptación en las historias
de los usuarios. En este artículo hablaré de:
• ¿Qué son los criterios de aceptación?
• Por qué son importantes
• Suero funcionan bien

• Cómo crearlos
3.3.1. ¿Qué son los criterios de aceptación?

Los criterios de aceptación son declaraciones de requisitos que se describen desde el punto de vista del usuario.
para determinar cuándo una historia está "terminada" y funciona como se esperaba.
Esto ayuda al equipo a reducir el riesgo al realizar pruebas con los mismos criterios que se acordaron cuando el equipo aceptó
el trabajo. Los criterios de aceptación están surgiendo y evolucionando y se supone que son lo suficientemente flexibles para
cambiar hasta que el equipo comience a trabajar en la historia.
» Cualquier miembro del equipo, como analistas comerciales, control de calidad y desarrolladores, puede ayudar al PO en ambos
crear y revisar los criterios de aceptación.
3.3.2. Ventajas de los criterios de aceptación:
• Activa el proceso de pensamiento para que el equipo piense en cómo funcionará una característica del usuario final.
perspectiva
• Ayuda al equipo a escribir los casos de prueba precisos sin ninguna ambigüedad para comprender el negocio.
valor.
• Elimina el alcance innecesario que no agregará valor a la historia, en otras palabras, mantendrá la
contenido correcto.
3.3.3. Ejemplo de una Historia de Usuario con Criterios de Aceptación:

Al cliente le gustaría que le enviemos un correo electrónico a mi dirección de correo electrónico normal cuando su cuenta entre en
sobregiro para que sepa que necesito depositar dinero en mi cuenta.
Criterios de aceptación:
25 de 33
Dirección de correo electrónico no válida Validación de correo electrónico Marque el perfil en línea como incompleto, envíe un mensaje de correo postal.
Marketing de dirección de correo Mensajería de mercadeo La copia del mensaje de marketing coincide con la copia proporcionada por
electrónico válido
Dirección de correo electrónico Mensajería de mercadeo El diseño del mensaje de marketing coincide con las especificaciones proporcionadas
válida por marketing
Dirección de email válida Mensajería de marketing navegar El mensaje contiene un enlace de correo electrónico que permite al usuario
a la banca en línea
En el ejemplo anterior, los criterios de aceptación son un conjunto de declaraciones que representan las "condiciones de satisfacción" de los requisitos. También contiene
límites y parámetros que determinan cuándo una historia está completa y lista para ser aceptada. Se expresó claramente en un lenguaje sencillo para el cliente sin
ninguna ambigüedad.
en lo que se espera como resultado. Debe ser fácilmente accionable y traducirse en uno o más casos de prueba manuales/automatizados.
Cuando el equipo de desarrollo ha terminado de trabajar en la historia de usuario, le muestran la funcionalidad al propietario del producto, mostrando cómo se satisface
cada criterio.
3.3.4. Creación de criterios de aceptación

Los criterios de aceptación constan de 3 partes: entrada, proceso y resultado. Una forma útil de pensar en los criterios de aceptación es: “Cuando <ingreso> X y
<proceso>Y, comprobaré el <resultado>Z como resultado”.
Las entradas de los criterios de aceptación son cosas como "ingresar un valor y presionar un botón" o "ingresar un comando y verificar los resultados".
El proceso de criterios de aceptación es el cálculo real que se está comprobando. Por lo general, cuando creamos una historia de usuario, queremos que suceda algo
para un conjunto determinado de entradas de un usuario. Ese proceso, aunque normalmente no es directamente observable, es verificable para un conjunto dado de
entradas y salidas esperadas.
El resultado (resultados) de los criterios de aceptación siempre debe ser comprobable con una ambigüedad mínima.
Cuando las personas piensan en historias de usuarios, generalmente piensan en términos de la descripción de la historia de usuario. Sin embargo,
la historia de usuario no está completa hasta que tenga criterios de aceptación verificables. Los criterios de aceptación también ayudan al equipo a dimensionar
rápidamente una historia de usuario, porque una vez que saben cómo se verificará la historia, entienden el esfuerzo necesario para que suceda. Utilice criterios de
aceptación con cada historia de usuario.
26 de 33
4. Historias de usuarios frente a requisitos
4.1. En qué se diferencian las historias de usuario de los requisitos
Estaba empacando mis cosas, lista para partir después de una larga semana de entrenamiento. Susan, la principal analista de
negocios, había estado diligentemente atenta toda la semana. Tomaba notas excelentes, hacía preguntas de sondeo y parecía
estar integrando los nuevos conocimientos sin problemas.
”
»“Oye Tirrell, tengo una pregunta para …
ti “Dispara”
"Entonces, ¿exactamente en qué se diferencian las historias de usuario de los requisitos?"
» Cuando la gente dice "requisitos", especialmente en mi cuello de los bosques, se están refiriendo al estándar
IEEE 830 "El sistema debe" estilo de requisitos de escritura. Estos son algunos ejemplos: • 1.2) El sistema
permitirá que un usuario compre un pastel con una tarjeta de crédito
• 1.2.1) El sistema aceptará Visa, Mastercard y American Express
• 1.2.2) El sistema cargará la tarjeta de crédito antes de hacer el pastel
• 1.2.3) El sistema le dará al usuario un número de orden
Entiendes la idea. Un problema con la documentación de requisitos de esta manera es que es muy tedioso y requiere mucho
tiempo. Otro problema es que es aburrido de hacer, y aún más aburrido de leer, razón por la cual la documentación larga y
detallada de los requisitos rara vez se lee. Por último, debido a que los requisitos están escritos en un nivel tan granular, es difícil
comprender el panorama general.
4.1.1. Las historias de usuario están orientadas a

objetivos Los requisitos tradicionales se crean desde la perspectiva del sistema y sus actividades asociadas.
Los problemas con la interpretación de estas actividades conducen al dolor y al incumplimiento de los plazos porque tienden a
interpretarse como edictos en lugar de puntos de descubrimiento. En otras palabras, tienden a sobre especificar. Esto nos lleva a
una situación en la que ingenieros inteligentes muy bien pagados no tienen la oportunidad de resolver los problemas de los
usuarios, están atrapados implementando una solución subóptima.
A diferencia de los requisitos tradicionales, las historias de usuario cuentan lo que el usuario intenta lograr. Esto es importante
porque da contexto a cómo vemos los requisitos. Ya que hay múltiples maneras de ayudar a un
27 de 33
el usuario logra el objetivo, asegura que la solución cumpla con el objetivo (o el problema que el usuario está tratando de solucionar).
resolver).
4.1.2. Las historias de usuarios permiten estimaciones rápidas del nivel de esfuerzo
En cascada, hay una fase tradicional de recopilación de requisitos que puede ser del 20 al 30 % del proyecto general
línea de tiempo Por lo tanto, el equipo que realiza el trabajo no puede dar estimaciones hasta después de que se hayan establecido las especificaciones.
sido escrito Esto lleva a la fricción porque los equipos a menudo son llevados a una línea de tiempo que no
coincida con los requisitos, pero el cronograma y el presupuesto se decidieron antes de que se escribieran las especificaciones.
22 capturas.
Con User Stories, un equipo puede ver lo que el usuario está tratando de lograr y dar una estimación asociada generalmente en minutos u horas en
lugar de semanas o meses asociados con los requisitos tradicionales.
4.1.3. Las historias de usuarios permiten un alcance negociable

Los requisitos tradicionales tienden a ser "todo o nada" y no tienen sentido de priorización. Por lo tanto, la
El alcance de los requisitos tradicionales no es negociable. Esto puede conducir a lo que se conoce como "ingeniería de valor", que es la práctica de
crear soluciones rápidas pero frágiles para completar toda la funcionalidad.
a tiempo.
Con las historias de usuarios, si el nivel de esfuerzo estimado es diferente de lo que pensaron los patrocinadores del proyecto, el
el equipo y el propietario del producto pueden echar un vistazo a los objetivos de los usuarios en las historias y pensar en otros, menos
formas ricas en funciones (pero aún utilizables) para ayudar al usuario a alcanzar sus objetivos.
4.1.4. El estándar IEEE 830 se actualizó por última vez en 1998

Han pasado muchas cosas en el desarrollo de software desde entonces, pero muchas empresas aún no han revisado cómo
crean requisitos, por lo que todavía veo mucho de esto en el campo. A menudo, es porque se tomó una decisión
Hace aproximadamente 15 años para escribir los requisitos de esta manera, y se contrataron ejércitos de analistas de negocios para respaldar esta
decisión. En resumen, el uso continuado de las especificaciones de estilo IEEE 830 es tanto una función de la inercia como
es la toma de decisiones consciente.
¿Cómo se escriben las especificaciones en su empresa?
4.2. Cómo crear historias de usuario a partir de

requisitos tradicionales.
» Cuando entreno equipos, muchas veces mi atención se dirige a los analistas de requisitos,
porque se sienten incómodos al tratar de entender la diferencia entre una historia de usuario
y los requisitos tradicionales. Estuve hablando con un analista de requisitos la semana
pasada y se quejó: “Mi empresa comenzó a adoptar el camino ágil y me dijeron que escribiera
los requisitos como historias de usuario. No tengo idea de cómo escribir historias de
usuario. ¿Aún necesitamos los documentos de requisitos? Veo que la preocupación
expresada es una de las más comunes que pone nerviosa a la gente.
es dificil de entender
cómo dividir las grandes especificaciones de requisitos en partes más pequeñas de trabajo factible en la iteración. Aquí están
algunos consejos y trucos que ayudan a dividir los documentos de grandes requisitos en historias de usuarios.
Los documentos de requisitos tradicionales tienen características especificadas por cada módulo o hito.
28 de 33
Consejo 1: elija una característica a la vez y priorice

Tome cada módulo o gran característica del documento tradicional y comprenda
• Quién es el usuario de esa funcionalidad
• ¿Cuál es el propósito de ese requisito?
• ¿Por qué necesita esa funcionalidad?
El "Por qué" en el último punto le dirá el valor comercial real que el usuario final obtiene de la función. También le ayuda a
evaluar si el usuario final realmente necesita esa característica. Si ve que no hay un valor comercial real en la característica
de construcción, entonces empújelo al final de la pila. El objetivo es identificar las rocas grandes más importantes que son
útiles para que el usuario final construya su sistema.
Sugerencia 2: Dividir la característica principal en

partes pequeñas Ahora bien, esta gran roca obviamente no se puede construir en una iteración de 2 o 4 semanas. Hay
que descomponerlo en piezas más pequeñas. Comience a dividir los requisitos en partes más pequeñas. A medida que
identifique cada requisito más pequeño, intente idear la funcionalidad, es decir, los criterios de aceptación que nos digan si
estamos creando la característica correcta.
Consejo 3: Apóyalo con otros artefactos
» Un mito que muchos tienen en mente es que

una historia de usuario y los criterios de
aceptación son solo una lista de oraciones
con viñetas. Sin embargo, eso no es cierto.
Al escribir la historia del usuario y los criterios de aceptación, está bien respaldarlo con todos los artefactos
adicionales que se necesitan. Por ejemplo: cualquier estructura alámbrica, documento de reglas comerciales, cualquier
diagrama de arquitectura, etc., pero asegúrese de adjuntar las cosas mínimas sin invertir mucho tiempo y que el desarrollador
entienda la intención de la historia.
29 de 33
Consejo 4: asegúrese de que los requisitos sean claros

Asegúrese de que las condiciones de satisfacción para cada historia estén identificadas, también conocidas como criterios de aceptación; Eso ayuda al equipo
a construir la funcionalidad correcta.
Escriba las pruebas que se pueden ejecutar para verificar si realmente se implementa la funcionalidad correcta, también conocidas como pruebas de
aceptación, que confirman que se cumplen los criterios de aceptación. Ejecutar estas pruebas de aceptación calificaría la historia como TERMINADA y
aceptada por el usuario final.
Asigne dependencias a través de las historias y haga que se especifiquen en la misma historia de usuario como referencia. Como ejemplo, la historia de
"enviar correo electrónico" depende de la historia de "crear correo electrónico". Asegúrese de que se describa la función de nivel superior, es decir, la gran
roca, para que sepamos lo que estamos buscando una vez que se hayan creado todas las historias de usuario.
Describa cualquier suposición sobre cómo demostrará la roca pequeña al usuario final, por ejemplo, cualquier contenedor de prueba que desee usar hasta
que el entorno de prueba real esté listo.
Consejo 5: Repita y enjuague

Repita todos los pasos anteriores hasta cubrir una característica de su documento tradicional.
La descomposición es lo mismo, solo la haces impulsada por resultados en lugar de impulsada por actividades
Para resumir, tome un gran documento de especificación de requisitos, divídalo en función, divídalo en requisitos más pequeños, priorícelos, tome los más
importantes de la parte superior de la pila, capture suficientes detalles en forma de criterios de aceptación, también conocidos como la condición. de
satisfacción De esta manera, está determinando los requisitos más importantes, y los envía al equipo temprano para desarrollarlos, de modo que el retorno de
la inversión se pueda obtener más rápido.
¿Crees que esta forma de romper la roca grande en otras más pequeñas y construirlas es mejor que construir la roca más grande de una sola vez? Por
supuesto, estoy de acuerdo en que es necesario volver a integrar todas las piezas más pequeñas.
30 de 33
5. Recopilación y comunicación de historias de usuario
5.1. Cómo ejecutar un taller de historias de usuario

» Ejecutar un taller práctico de historias de usuario es una de las habilidades más valiosas que un producto
el propietario puede aprender.
5.1.1. 7 pasos para un taller de historias de usuario exitoso

Paso 1: Forme un grupo de 3 a 5 personas que entiendan el propósito del producto
3-5 parece ser el número mágico. Menos y es posible que te pierdas algunas ideas. Un poco más, y ralentiza el
proceso hacia abajo, así como rendimientos decrecientes en la calidad de las ideas generadas.
Deje que el equipo presente una visión del producto de sus sueños. Proponles que escriban alto nivel
características para la visión. Explique claramente lo que quiere decir con una característica. (Ejemplo: la página de inicio de sesión para un portal es
no es una característica). Tome cada característica e identifique los requisitos de alto nivel en las notas adhesivas de color.
Paso 2: presente la frase "EPIC" y dígales a los equipos que dividan las características en épicas en notas adhesivas de diferentes
colores
Haz un mapa mural y ayuda a los equipos a pegar las épicas exactamente debajo de las características. Cuando los equipos establecen
características y relación épica, trabajaría con ellos para hacer que el equipo escriba requisitos de alto nivel para
cada epopeya. Presente User Story con un ejemplo y su intención. Ayudar a los equipos a comprender varios formatos de
Historias de usuarios. Transmitir la importancia de identificar User Personas en esta etapa. Mostrar algunos ejemplos de
dividir historias de usuario. Proporcione algunas pautas de lo que se debe y no se debe hacer, así como de los escollos y las trampas al escribir al usuario.
cuentos.
Paso 3: Comience el ejercicio pidiendo a los equipos que escriban una línea de alto nivel como requisitos para cada epopeya en silencio
Cada persona toma un post-it del mismo color y escribe en silencio una historia de usuario por post-it. Una vez que todos hayan terminado de escribir
sus notas adhesivas, pídales que las lean en voz alta. Si alguien tiene duplicados, consolide.
» Dependiendo del tamaño de las epopeyas, puede tomar de 3 a 10 minutos obtener todas las principales historias de los usuarios.
ries. Puede observar el lenguaje corporal para ver cuándo terminan los equipos. Puedes observar
que el grupo pasa de estar acurrucado al principio a pararse/recostarse al final. Es probable que cada post-it
comience con un verbo. (por ejemplo, Redactar correo electrónico, Crear contacto, Agregar usuario, etc.) que
forma el "esqueleto ambulante" del mapa. Pida a los equipos que peguen a todos los usuarios
historias exactamente debajo de las epopeyas relacionadas. Este podría ser su primer momento 'ajá' para
una lluvia de ideas silenciosa.
31 de 33
Paso 4: Pida al equipo que agrupe las notas adhesivas en silencio.

Pida al equipo que acerque las cosas similares entre sí y que las cosas diferentes se muevan más lejos. Utilice la agrupación
silenciosa porque es más rápido que agruparlos en voz alta. Si se encuentran duplicados, elimínelos. Los grupos se formarán de
forma natural y bastante fácil. Una vez más, el lenguaje corporal lo ayudará a ver cuándo terminaron, generalmente de 2 a 5
minutos.
Paso 5: Presente los criterios de aceptación con un ejemplo Ayude

a los equipos a escribir criterios de aceptación para historias individuales. Ahora hable de los requisitos no funcionales. Pida al
equipo que proponga requisitos no funcionales para las mismas historias. Organice todas las historias en la pared y ayude a los
equipos a ordenarlas, pídales que dividan las historias por fecha o alcance.
Paso 6: Explique el tamaño de las historias utilizando los puntos de la historia y ayude a los equipos a dimensionar
todas las historias . El propietario del producto explica las restricciones de tamaño y facilita un ejercicio de dimensionamiento de los puntos de la
historia utilizando el póquer de planificación con el equipo.
Paso 7: Tome todas las historias de usuario en la primera versión, luego comience a dividir las historias para hacerlas
lo más delgadas posible Esto es para que las partes interesadas obtengan una comprensión sólida de las divisiones verticales
y para que podamos medir con mayor precisión Progreso.
Veo que hay mucho valor y motivación cuando los equipos presentan su propia visión y escriben las historias. La esencia del taller
puede perderse cuando entrego historias de usuario precocinadas al equipo.
¿Qué piensas?
5.2. Cómo explicar y presentar historias de usuarios
Cuando entreno a equipos y a sus propietarios de productos, una de las primeras áreas en las que quiero ayudarlos a corregir son
las sesiones de refinamiento del trabajo pendiente. La mayoría de las veces, estas son reuniones agotadoras de horas de duración
en las que los equipos se preguntan: "¿Por qué no podemos simplemente programar?" Al igual que muchas cosas, el dolor que
sienten las personas en un nuevo proceso se debe a las ineficiencias anteriores. En este caso, los propietarios del producto a
menudo no tienen idea de cómo presentar la información al equipo para poder dimensionar, refinar, dividir y, en última instancia,
entregar la historia. En este artículo, explicaré "Cómo explicar y presentar historias de usuarios".
5.2.1. Paso 1: Presente los antecedentes y el caso de negocios

Un gran error que veo que cometen los propietarios
de productos, especialmente con los equipos nuevos,
es saltar directamente a leer la historia al equipo sin
brindar antecedentes. En el caso de un proyecto que
ya tiene cierto impulso, esto es comprensible. Seguro
que no quieres reinventar la rueda. Sin embargo, para
los equipos que están comenzando un nuevo proyecto,
es muy importante que presente los antecedentes y el
caso comercial asociado con este proyecto.
» Presentar antecedentes y
caso de negocios no significa
leer un MRD o PRD de 40
páginas al equipo. Significa
ayudarlos a comprender el
problema desde una perspectiva
general y la solución para solucionar el problema.
32 de 33
5.2.2. Paso 2: Presente el problema y el área de funciones Los problemas

que son lo suficientemente grandes, complejos e importantes como para requerir un equipo de software generalmente
tienen “problemas secundarios” asociados con ellos. Estos subproblemas tienen áreas características para resolverlos.
El subproblema y el área de características son importantes porque es otro paso hacia abajo en la granularidad. Esto le da un contexto adicional a la
conversación.
5.2.3. Paso 3: Presente la historia de usuario y los criterios de aceptación Ahora

es el momento de presentar la historia de usuario, lo cual está bien, porque el equipo tiene cajas mentales para ponerla:
• ¿Cuál es el problema general que estamos tratando de resolver?
• ¿Cómo hemos descompuesto ese problema en problemas más pequeños ?
• ¿Cuál es el pequeño problema específico que estamos tratando de resolver con esta historia de usuario en particular?
» Recordatorio: cuando presente una historia de usuario, asegúrese de tener una idea clara de quién
es el usuario. Use personas para delinear información básica sobre sus diferentes tipos de usuarios,
como la edad, los puntos débiles, los objetivos generales y el nivel de comodidad con la tecnología.
A medida que presente las historias de usuario, también deberá presentar los criterios de aceptación de la historia. Invariablemente, el equipo tendrá
preguntas sobre los criterios de aceptación, los casos de uso específicos y otros escenarios no descritos en la historia del usuario. Asegúrese de que usted (o
su Scrum Master) actualice la historia con esta información adicional. La conversación es la parte más importante de una historia de usuario.
5.2.4. Paso 4: Pregunte al equipo si tiene suficiente información sobre esta historia de usuario para
dimensionarla Las primeras dos veces, el equipo se sorprenderá por la franqueza de esta pregunta. Pero esta
pregunta es muy importante para el progreso de la reunión. A medida que se presentan nuevas historias y requisitos,
a veces la conversación se degrada a una discusión sobre arquitectura, o un viaje por el carril de la memoria que
recuerda la última vez que desarrollaron una característica similar. Esto está bien, pero si no se controla, la
conversación continuará para siempre. Por lo tanto, deberá preguntarle al equipo de vez en cuando "¿Tiene suficiente
información sobre esta historia de usuario para dimensionarla?" Si no es así, su próxima pregunta debería ser "¿Qué
más necesita saber sobre esta historia de usuario para poder dimensionarla?" Continúe preguntando esto hasta que
obtenga un tamaño razonable.
5.2.5. El panorama general

Como siempre me gusta decir, "el contexto lo es todo". La diferencia entre cómo sugiero que los propietarios de
productos presenten las historias de los usuarios y cómo se hace en la vida real es que mi método brinda un contexto
completo. Si queremos aprovechar la capacidad intelectual colectiva del equipo, todos deben comprender qué tipo de
problemas buscamos resolver, para quién y cuál es el impacto comercial. Eso nos permitirá tomar decisiones
inteligentes y hacer concesiones en lo que respecta a la entrega.
33 de 33

User Stories in Detail Español

Cargado por

Copyright:

Formatos disponibles

User Stories in Detail Español

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

User Stories in Detail Español

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Un documento técnico ágil

Historias de usuarios en detalle

Historias de usuarios en detalle

Copyright © 2014-2015, AgileLeanHouse A/S. Reservados todos los derechos

Autor Revisado 2015-03-15

Historias de usuarios en detalle

Historias de usuarios en detalle

4.2. Cómo crear historias de usuario a partir de requisitos tradicionales.................................... .....28 5.

Historias de usuarios en detalle

1. Creación de historias de usuario

1.1. Cómo escribir una historia de usuario

Paso 1: Describe quién quiere la característica El

• ¿Qué hacen día a día?

• ¿Cuál es su nivel de comodidad con la tecnología?

• ¿Qué metas están tratando de lograr?

• ¿Cuáles son los dolores diarios con los que se enfrentan?

Historias de usuarios en detalle

Paso 2: Describir lo que quieren La principal

Describa el resultado deseado del usuario en la historia de usuario.

Paso 3: Describa por qué lo quieren Otra gran

• Nos ayuda a comprender el valor asociado con la funcionalidad.

• Nos da la oportunidad de explorar otras formas de alcanzar ese objetivo.

Paso 4: Cree criterios de aceptación en torno a la nueva característica Una historia

Historias de usuarios en detalle

• El usuario puede agregar hasta 10 direcciones en sus 'libretas de direcciones'

• Direcciones internacionales no admitidas

• El usuario puede agregar direcciones en la "configuración de la cuenta" o durante el pago.

Paso 5: participe en una conversación para completar los

Hay algunos puntos clave:

• La historia de usuario no es independiente.

• La conversación es la parte más importante de la historia del usuario.

• Las historias de usuario se elaboran progresivamente.

¿Qué otros desafíos tiene para comprender y crear historias de usuario?

1.2. Cómo escribir buenas historias de usuario

» Una pregunta que surge

para nuestro tipo de trabajo. Es

sistema a partir de 50 frases ingeniosas!"

Historias de usuarios en detalle

Consejo 2. Incluya metadatos u otros artefactos con la historia de usuario.

Consejo 4. Involucrar al cliente en la escritura de las historias.

Mantenga una mente

1.3. Cómo desarrollar historias de usuario

Historias de usuarios en detalle

En este artículo, presentaré 4 técnicas sobre cómo desarrollar historias de usuario.

1.3.1. Técnica 1: Entrevistas a usuarios

Realice entrevistas 1 a 1 y en grupos pequeños para

1.3.2. Técnica 2: Cuestionarios

1.3.3. Técnica 3: Observación

Ir al lugar donde el usuario suele trabajar,

Historias de usuarios en detalle

1.3.4. Técnica 4: Talleres

Después de que haya una gran cantidad de historias,

• ¿Qué querrá hacer el usuario a continuación?

• ¿Qué errores podría cometer el usuario aquí?

• ¿Qué podría confundir al usuario en este punto?

• ¿Qué información adicional podría necesitar el usuario?

1.3.5. Los procesos ágiles lo ayudan a integrar requisitos nuevos y emergentes

¿Cuáles son otras formas de desarrollar historias de usuario?

1.4. Cómo escribir historias de usuario para errores