|
| Lo que debes sabér sobre las Historias de Usuario en el desarrollo ágil de software |
Historias de Usuario en Scrum: Guía Práctica desde la Perspectiva de un Analista Funcional en Formación
Cuando empecé mi camino como Analista Funcional, una de las primeras cosas que captó mi atención fue el concepto de "Historia de Usuario" y cómo, a través de ella, las metodologías ágiles de desarrollo de software sitúan al usuario real en el centro de su proceso diario.
Al principio, la idea de convertir los
requerimientos del sistema en pequeñas narrativas parecía simple,
pero a medida que me sumergí más en el mundo de Scrum, me di
cuenta de que hay mucho más de lo que parece detrás de esta básica, pero poderosa herramienta.
Hoy quiero compartir contigo lo que he aprendido sobre las
historias de usuario, especialmente si estás en la etapa inicial
de tu carrera o simplemente te interesa entender cómo funcionan en el
marco de Scrum.
¿QUÉ ES UNA HISTORIA DE USUARIO?
Primero, vamos a lo básico. Una historia de usuario es una descripción breve, en lenguaje sencillo, de una funcionalidad que un usuario necesita del sistema.
En otras palabras, se refiere a contar de manera simple, aunque con una
cierta estructura semántica, qué debe hacer el sistema desde el punto de
vista del usuario.
La estructura más utilizada, en consecuencia, quedará conformada de la siguiente manera:
"Como [tipo de usuario], quiero [acción] para [objetivo]."
Por ejemplo:
✔ "Como comprador, quiero agregar productos a mi carrito para realizar compras más adelante."
✔ "Como administrador, quiero generar reportes mensuales para analizar el desempeño de la tienda."
✔ "Como auditor, quiero poder registrar hallazgos en la app durante las auditorías de 5S para llevar un control detallado de los incumplimientos."
✔ "Como jefe de planta, quiero visualizar el cronograma de auditorías de 5S para asegurarme de que todas las áreas críticas sean evaluadas regularmente."
Por ejemplo, para la historia de usuario "Como auditor, quiero poder registrar hallazgos en la app durante las auditorías de 5S", algunos posibles criterios de aceptación podrían ser:
📌 El auditor debe poder agregar fotos y comentarios a cada hallazgo.
📌 El sistema debe permitir la edición de hallazgos antes de finalizar la auditoría.
📌 Todos los hallazgos deben guardarse automáticamente en la base de datos central al finalizar la auditoría.
Los criterios de aceptación son esenciales porque proporcionan claridad y aseguran que todas las partes involucradas tengan la misma comprensión de lo que significa "completar" una historia de usuario.
No se trata solo de describir una característica, sino de entender el
"qué" y el "por qué" detrás de esa necesidad.
Por ejemplo, una historia de usuario podría ser:
Por ejemplo, una historia de usuario podría ser:
"Como usuario, quiero poder registrarme en la plataforma para acceder
a contenido exclusivo."
Esta simple frase encapsula un requerimiento clave, y como ves, se
enfoca en el valor que el usuario final espera obtener.
Esta herramienta es la piedra angular de los proyectos que utilizan metodologías ágiles, como Scrum, porque ayudan a mantener al equipo enfocado en entregar valor de forma incremental, ajustándose estrictamente a las necesidades reales del usuario.
Esta herramienta es la piedra angular de los proyectos que utilizan metodologías ágiles, como Scrum, porque ayudan a mantener al equipo enfocado en entregar valor de forma incremental, ajustándose estrictamente a las necesidades reales del usuario.
¿POR QUÉ SON IMPORTANTES LAS HISTORIAS DE USUARIO EN SCRUM?
Scrum se basa en la entrega continua de valor, y las historias de
usuario son esenciales para lograrlo.
En lugar de trabajar con un extenso documento de requerimientos al
inicio del proyecto, Scrum propone un enfoque más ágil y adaptable, en
donde las historias de usuario permiten al equipo rápidamente
priorizar, estimar y trabajar en pequeñas piezas de funcionalidad, lo
que facilita la entrega de versiones incrementales del producto.
Imagina que estás construyendo una aplicación compleja. Si intentaras definir cada detalle desde el principio, es probable que te enfrentes a cambios constantes a medida que el proyecto avanza y las necesidades del usuario evolucionan.
Imagina que estás construyendo una aplicación compleja. Si intentaras definir cada detalle desde el principio, es probable que te enfrentes a cambios constantes a medida que el proyecto avanza y las necesidades del usuario evolucionan.
Las historias de usuario, al ser más flexibles y modulares, te
permiten adaptarte a estos cambios sin perder de vista el rumbo.
Otro aspecto a destacar es que las historias de usuario permiten a
todos en el equipo comprender fácilmente por qué están haciendo lo que
hacen y, sobre todo, cómo su trabajo agrega valor al producto.
ESTRUCTURA DE LA HISTORIA DE USUARIO
Su estructura es bien simple, pero en esa simpleza está su
fortaleza.
La fórmula más común para redactar una buena historia es centrarse en
el "quién", el "qué" y el "para":
- Quién: ¿Quién es el usuario?
- Qué: ¿Qué quiere hacer ese usuario?
- Para qué: ¿Por qué es importante para él?
La estructura más utilizada, en consecuencia, quedará conformada de la siguiente manera:
"Como [tipo de usuario], quiero [acción] para [objetivo]."
Por ejemplo:
✔ "Como comprador, quiero agregar productos a mi carrito para realizar compras más adelante."
✔ "Como administrador, quiero generar reportes mensuales para analizar el desempeño de la tienda."
✔ "Como auditor, quiero poder registrar hallazgos en la app durante las auditorías de 5S para llevar un control detallado de los incumplimientos."
✔ "Como jefe de planta, quiero visualizar el cronograma de auditorías de 5S para asegurarme de que todas las áreas críticas sean evaluadas regularmente."
|
| Estructura básica de una Historia de Usuario |
CRITERIOS DE ACEPTACIÓN
Una parte crucial de las historias de usuario son los criterios de aceptación, los que representan las condiciones que deben cumplirse para que una historia de usuario se considere completa.
Los criterios de aceptación detallan lo que se espera que el sistema
haga en situaciones específicas, ayudando a los desarrolladores y
testers a entender exactamente qué se requiere.
Por ejemplo, para la historia de usuario "Como auditor, quiero poder registrar hallazgos en la app durante las auditorías de 5S", algunos posibles criterios de aceptación podrían ser:
📌 El auditor debe poder agregar fotos y comentarios a cada hallazgo.
📌 El sistema debe permitir la edición de hallazgos antes de finalizar la auditoría.
📌 Todos los hallazgos deben guardarse automáticamente en la base de datos central al finalizar la auditoría.
Los criterios de aceptación son esenciales porque proporcionan claridad y aseguran que todas las partes involucradas tengan la misma comprensión de lo que significa "completar" una historia de usuario.
¿QUÉ HACE QUE UNA HISTORIA DE USUARIO SEA EFECTIVA?
No todas las historias de usuario logran su cometido, algunas son más efectivas que otras, la clave está en cómo se redactan y gestionan.
Aquí te comparto algunas BUENAS PRÁCTICAS que he aprendido, para
redactarlas correctamente.
1. Apóyate en la palabra INVEST:
En realidad, esa palabrita es un acrónimo introducido por Bill Wake en
2003 para describir las características de una buena historia de
usuario:
Independiente:
Debe poderse desarrollar por separado de otras historias.
Negociable:
No es un contrato rígido; puede ajustarse según sea necesario.
Valiosa:
Debe proporcionar valor al usuario o al negocio.
Estimable:
Debe poder estimarse en términos de tiempo o esfuerzo.
Simple:
Debe ser lo suficientemente pequeña para completarse en un
sprint.
Testable:
Debe poderse verificar que se ha implementado correctamente.
Usar el marco INVEST me ha ayudado a redactar historias de usuario
claras, manejables y efectivas.
2. Céntrate en el usuario: La HDU debe enfocarse estricamente
en las necesidades del ususario o stakeholder específico.
3. Evita la ambigüedad: La historia debe ser específica en cuanto al resultado esperado y no
dejar lugar a interpretaciones. Es importante que todos los miembros del
equipo la entiendan de la misma manera.
4. Inluye criterios de aceptación: Te permitirán establecer
cuándo la historia estará terminada, brindando claridad a los
desarrolladores sobre qué es lo que se espera lograr con esa HDU.
5. Trabaja en colaboración con Stakeholders: No trabajes en
solitario. Involucra a los usuarios finales, a los Product Owners, y a
cualquier otra persona relevante desde el principio. Ellos te
proporcionarán la información necesaria para crear historias precisas y
relevantes.
6. Priorízalas: No todas las historias de usuario son igual de importantes. Es vital priorizarlas según el valor que aportan al producto. Esto asegura que el equipo trabaje primero en lo que realmente importa. Una técnica de priorización ampliamente utilizada es la TÉCNICA MOSCOW.
7. Descompónelas, si es necesario: Una HDU debe ser alcanzable en un sprint, pero si es demasiado grande, descomponla en historias más pequeñas. Esto facilita su gestión y en consecuencia, la entrega de valor incremental.
6. Priorízalas: No todas las historias de usuario son igual de importantes. Es vital priorizarlas según el valor que aportan al producto. Esto asegura que el equipo trabaje primero en lo que realmente importa. Una técnica de priorización ampliamente utilizada es la TÉCNICA MOSCOW.
7. Descompónelas, si es necesario: Una HDU debe ser alcanzable en un sprint, pero si es demasiado grande, descomponla en historias más pequeñas. Esto facilita su gestión y en consecuencia, la entrega de valor incremental.
8. Documenta las dependencias: Aunque las historias deben ser
lo más independientes posible, en caso de que dependan de otras tareas,
es importante que estas dependencias se documenten claramente.
HISTORIAS DE USUARIO EN LA PRÁCTICA
Hasta ahora, hemos visto qué son las historias de usuario y cómo se estructuran. Pero, ¿cómo se implementan en la práctica?Creación de Historias de Usuario
Es responsabilidad del product owner (PO) generar las
historias de usuario que conformarán el product backlog, pero
esa no es una tarea que deba realizarla en la soledad de su
escritorio. Deberá apoyarse en el equipo de scrum y en especial en
el analista funcional.
Durante esta sesión, se generan tantas historias como sea posible,
cubriendo todas las posibles interacciones que los usuarios tendrán con
el sistema.
|
| Scrum planning |
No te preocupes si las primeras historias que se escriban no son
perfectas. El objetivo es empezar a poner las ideas sobre la mesa. A medida que avanzas, se irán refinando y ajustando las
historias de usuario para que sean más claras y manejables.
Priorización y Estimación
Una vez que tienes un conjunto de historias de usuario, es hora de
priorizarlas, siendo esa otra de las responsabilidades lideradas por el
Product Owner.
La priorización se basa en el valor que cada historia de usuario aporta
al producto y en cómo se alinea con los objetivos del proyecto.
Una técnica de priorización muy útilizada es la
TÉCNICA MOSCOW.
El término MOSCOW es en realidad un acrónimo que representa diferentes
niveles de prioridad:
Después de priorizar, el equipo de scrum realiza la estimación. Esto implica evaluar cuánto tiempo y esfuerzo se necesitará para completar cada historia de usuario.
- M (Must have) – Debe tener: Estos son los requerimientos o funcionalidades críticos que son esenciales para el éxito del proyecto. Sin ellos, el sistema no funcionaría o no cumpliría con sus objetivos mínimos. Son imprescindibles y deben ser completados en el plazo establecido.
- S (Should have) – Debería tener: Estos son requerimientos o funcionalidades importantes pero no críticos. Aunque no son indispensables para la funcionalidad básica del sistema, su implementación mejora significativamente el producto. Se espera que se incluyan si es posible dentro del plazo del proyecto.
- C (Could have) – Podría tener: Estos son requerimientos o funcionalidades deseables que aportarían valor adicional al producto, pero no son esenciales. Se priorizan solo si hay tiempo y recursos suficientes, ya que no afectan directamente la funcionalidad clave.
- W (Won’t have this time) – No tendrá en esta versión: Estos son requerimientos que no se implementarán en esta fase del proyecto o en la versión actual, pero pueden ser considerados en futuras iteraciones o versiones.
Después de priorizar, el equipo de scrum realiza la estimación. Esto implica evaluar cuánto tiempo y esfuerzo se necesitará para completar cada historia de usuario.
Esta estimación se realiza en puntos de historia (story points),
los que representan una medida abstracta del esfuerzo relativo requerido
para la tarea.
La escala utilizada podrá ser lineal o mejor aún, no lineal como es el
caso de la serie de Fibonacci y la estimación se lleva adelante
durante una actividad de equipo denominada Planning Poker.
En ella cada miembro del equipo asigna puntos a una historia de
usuario, usando cartas numeradas (generalmente de la serie de
Fibonacci). Los valores se revelan simultáneamente y se discuten las
diferencias para llegar a un consenso.
Implementación durante el Sprint
Previo a cada sprint, durante el sprint planning, el equipo selecciona un conjunto de historias de usuario para trabajar y esas historias se desglosan en tareas más pequeñas que pueden ser asignadas a los miembros del equipo.
Uno de las condiciones necesarias es que la historias elegidas puedan
ser finalizadas en un sprint, caso contrario deberán ser
divididas.
A lo largo del sprint, el equipo trabaja para completar estas tareas,
con el objetivo de entregar una versión funcional del producto al final
del sprint.
Es durante esta fase que el valor de las historias de usuario realmente se hace evidente.
Es durante esta fase que el valor de las historias de usuario realmente se hace evidente.
Al dividir el trabajo en pequeñas historias manejables, el equipo puede
mantener un enfoque claro y trabajar de manera más
eficiente.
Además, el feedback continuo del Product Owner y de los usuarios
finales asegura que el producto final se alinee con las expectativas y
necesidades reales.
Relación con Jira
Una herramienta que es fundamental en la gestión de historias de
usuario es Jira.
Esta aplicación es ampliamente utilizada en el mercado para gestionar
proyectos ágiles, y es ideal para trabajar con historias de
usuario.
En Jira, cada historia se convierte en una tarea que puede asignarse,
priorizarse y seguirse a lo largo del sprint o desglosarse en
sub-tareas.
|
| Gestión de historias de usuarioen jira |
Además, Jira permite agregar los criterios de aceptación directamente
en la historia de usuario, lo que facilita la revisión y verificación
una vez que se completa la tarea.
Por ejemplo, si estás trabajando en la historia de usuario "Como auditor, quiero poder registrar hallazgos en la app durante las auditorías de 5S", en Jira podrías crear subtareas para "Desarrollar formulario de registro de hallazgos", "Implementar funcionalidad de carga de fotos", y "Configurar almacenamiento automático de datos". Cada una de estas subtareas puede tener sus propios criterios de aceptación y ser gestionada de manera eficiente dentro del sprint.
Por ejemplo, si estás trabajando en la historia de usuario "Como auditor, quiero poder registrar hallazgos en la app durante las auditorías de 5S", en Jira podrías crear subtareas para "Desarrollar formulario de registro de hallazgos", "Implementar funcionalidad de carga de fotos", y "Configurar almacenamiento automático de datos". Cada una de estas subtareas puede tener sus propios criterios de aceptación y ser gestionada de manera eficiente dentro del sprint.
DESAFÍOS COMUNES Y CÓMO SUPERARLOS
Como todo en la vida, trabajar con historias de usuario tiene sus desafíos. Aquí te comparto algunos de los que he enfrentado junto a tips para superarlos:Historias de Usuario Demasiado Grandes (Epics):
A veces, una historia de usuario es tan grande que no se puede
completar en un solo sprint. En estos casos, la solución es descomponer
la historia en varias más pequeñas.
Por ejemplo, si estás trabajando en una historia como "Como auditor,
quiero generar reportes completos de auditorías de 5S", podrías
dividirla en subhistorias como "Crear la funcionalidad de exportación de
reportes en PDF" y "Implementar la opción de agregar comentarios a los
reportes."
Falta de Claridad en los Criterios de Aceptación:
Los criterios de aceptación pueden ser ambiguos, lo que lleva a
malentendidos y re-trabajos.
Para evitar esto, es importante que los criterios de aceptación sean
específicos y verificables. Involucrar al Product Owner y a los
desarrolladores en la definición de estos criterios puede ayudar a
asegurar que todos estén en la misma página.
Priorización Confusa:
En algunos proyectos, puede ser difícil decidir qué historias de
usuario priorizar, aquí es donde el Product Owner juega un papel
crucial, utilizando su conocimiento del negocio para guiar al
equipo.
Herramientas como la matriz de valor vs. esfuerzo pueden ser útiles
para visualizar qué historias ofrecen el mayor retorno de inversión.
Cambios Constantes en los Requerimientos:
En un entorno ágil, es común que los requerimientos cambien con el
tiempo.
Aunque esto puede ser desafiante, es importante recordar que la
flexibilidad es uno de los pilares de Scrum.
Mantener una buena comunicación con los stakeholders y estar dispuesto
a ajustar las historias de usuario según sea necesario es clave para
manejar estos cambios.
CONCLUSIÓN FINAL
Trabajar con historias de usuario en el marco de Scrum ha sido una experiencia enriquecedora para mí como analista funcional en formación.
No solo me ha permitido disponer de una herramienta relativamente fácil
entender e implementar para capturar las necesidades del usuario, sino
que también me ha enseñado sobre la importancia de la sinergia dentro
del equipo scrum y de mantenerme enfocado en la entrega de valor.
Las historias de usuario, cuando se redactan y gestionan correctamente, son una herramienta poderosa para guiar el desarrollo de software de manera ágil y eficiente.
Las historias de usuario, cuando se redactan y gestionan correctamente, son una herramienta poderosa para guiar el desarrollo de software de manera ágil y eficiente.
Y, lo más importante, aseguran que siempre estemos trabajando para
entregar lo que realmente le importa al usuario final, es decir, su gran
mérito es poner en el centro de la escena al usuario real.
Si estás comenzando en el mundo del análisis funcional o simplemente quieres mejorar tus habilidades, te animo a que practiques la redacción de historias de usuario, experimentes con herramientas como Jira y busques siempre la colaboración con tu equipo y stakeholders, aunque estos sean de un entorno ficticio que te inventes.
Si estás comenzando en el mundo del análisis funcional o simplemente quieres mejorar tus habilidades, te animo a que practiques la redacción de historias de usuario, experimentes con herramientas como Jira y busques siempre la colaboración con tu equipo y stakeholders, aunque estos sean de un entorno ficticio que te inventes.
¡El aprendizaje continuo es clave en este emocionante campo!
Bueno, eso fue todo, al menos por ahora. Espero sinceramente haberte aportado valor con este artículo. Si has llegado hasta aquí, te lo agradezco de corazón.
Este artículo es el resultado de un excelente curso de 120 hs, recientemente
Bueno, eso fue todo, al menos por ahora. Espero sinceramente haberte aportado valor con este artículo. Si has llegado hasta aquí, te lo agradezco de corazón.
Este artículo es el resultado de un excelente curso de 120 hs, recientemente
completado, sobre el Análisis Funcional en el desarrollo de software.
Quiero expresar mi más sincero reconocimiento y gratitud a la organización SilverTech, un sitio altamente recomendable para personas +50 que desean explorar nuevos caminos en el mundo laboral actual.
¿Tienes dudas, preguntas, otros puntos de vista o sugerencias sobre temas que te gustaría ver en el blog?
No dudes en dejar un comentario. Escribo con el propósito de ayudar y disfrutar del proceso, pero también para mejorar y aprender de tus opiniones.
Si deseas saber más sobre mí, te invito a visitar mi perfil en LinkedIn.
¡Que tengas una excelente semana y hasta pronto!
