Scrum: obtener historias de usuario

21 de julio de 2016
3 min. de lectura

En el artículo 'Hoy hablemos de Scrum' estuvimos dando un breve recorrido por los roles, componentes y etapas del proceso iterativo que Scrum plantea para el desarrollo de proyectos.

Pues bien, en esta oportunidad vamos a hablar un poco acerca de algo que yo llamo “etapas ocultas”.

Con esto me refiero a que si bien en el episodio anterior planteamos la necesidad de tener ciertos componentes para la correcta utilización del framework, no se mostró explícitamente como, cuando y donde se obtienen estos componentes. 

La razón por la que las llamó “etapas ocultas” es porque en el proceso vimos que los componentes están ahí, pero no vemos claramente planteada la etapa de su obtención ¿En que momento se hace la reunion para obtener el product backlog? ¿Que se hace en esa reunión? La respuesta a esas interrogantes vamos a verlas por partes.

Historias de usuario

Al momento de iniciar un proyecto todas las necesidades del usuario se definen o se sobre entienden como “requerimientos”, estos deben escribirse y detallarse lo mejor posible para que tanto el product owner y el equipo de desarrollo estén en la misma sintonía. En el episodio anterior comentamos que estos requerimiento en Scrum eran conocidos como historias de usuario.


En primera instancia debemos tener en cuenta que para elaborar estas historias de usuario hay celebrar una reunión inicial. Esta reunión se realiza con el Product Owner, Stake Holders y el equipo de desarrollo antes de iniciar el desarrollo del proyecto.

En dicha reunión cada miembro de los Stake Holders e incluso el product owner van tomando la palabra de manera ordenada y uno a uno van describiendo las necesidades que tiene el proyecto, lo que ellos desean que el producto, en palabras más simples, los requerimientos propiamente. 

Cada miembro de la reunión toma marcadores y post-it, e inicia la escritura de historias de usuario, la idea es detallar en los post-it el requerimiento puntual con todas las características resaltantes que se deban tener en cuenta para el caso. 

Para darle mayor entendimiento y puntualidad a estas historias, Scrum plantea ciertas palabras claves al momento de redactarlas.

En la imagen anterior podemos ver los elementos básicos de la historia. Lo primero que tenemos es el nombre de la historia, el rol que la solicita (para el ejemplo vemos que dice “Lector del Blog”), lo que quiere y para que lo quiere. 

De esta forma podemos tener las historias de usuario de una manera muy concreta, con un mayor entendimiento para cualquiera del grupo.

A raíz de tener el enunciado definido, pasamos describir lo que se conoce como criterios de aceptación en dichos criterios se colocan todas las consideraciones necesarias que se deben tener en cuenta al momento de desarrollar dicha historia. Un ejemplo de estos criterios los podemos ver en la siguiente imagen. 

En la imagen observamos algunas consideraciones importantes que el desarrollador debe tomar en cuenta al momento de tomar esta historia de usuario y hacerla realidad. 
Regularmente estas historias son escritas por el usuario, sin embargo los miembros pueden apoyar la labor en la reunión. La razón por la que es el usuario que las realiza es porque él conoce lo que quiere ver plasmado en su producto. 

Las consideraciones que se deben tener en cuenta al momento de redactar las historias de usuario son: 

Independientes: 

Una historia no puede depender de otra ya que al momento del desarrollo pueden resultar muchos factores bloqueantes. 

Negociables: 

Deben ser ambiguas en su enunciado para poder debatirlas, no son propiamente un contrato así que deben dar espacio al momento de definir los alcances y limitaciones de la misma.

Valoradas: 

Deben definir cuánto valor le aportan al proyecto del cliente, cuál aporta más que otra. Estimable: Se debe poder predecir el tiempo que le tomará a la persona que la agarre hacerla realidad. 

Pequeñas: 

Las historias son complicadas de estimar y si tenemos historias muy grandes el grado de dificultad aumenta, por lo que es recomendable que si tenemos historias muy grandes las dividamos en historias más pequeñas. 

Verificables:

Tener los criterios de aceptación ayuda a la persona que la lleva a cabo, saber si la ha realizado correctamente. Acá termina este episodio.

Esperamos haber sido bastante explícitos en todo el post y que les haya sido de utilidad. En caso de tener algún comentario no duden en dejarlo. 

En el próximo episodio estaremos estudiando otro de los componentes del framework.

Nos vemos en un próximo post

Suscríbete