¿Cómo crear una buena historia de usuario?

La primera pregunta que nos viene a la mente es: ¿Quién debería escribir la historia de usuario? La respuesta es sencilla el Product Owner. ¿Por qué? Porque el es el responsable de todas las tareas que entran en el equipo. El Product Owner debe hacerse no sólo responsable de la priorización de las historias sino que debe conocer en profundidad que tarea se le está pasando al equipo.

Seguidamente vendría otra pregunta: ¿Qué debe contener la historia? La historia de usuario debe contener la explicación de que se desea obtener y para qué. Pero no debe contener como debe hacerse. Es potestad del product owner el decidir que tareas se van a realizar durante un sprint pero también es potestad del equipo el decidir cómo se va a implementar una tarea. Como siempre esto no es una línea pintada en el suelo, el Product Owner y el equipo tienen espacio para hablar sobre las historias y pueden llegar a consensos que no acuerdos (que sería lo más indicado, si todo el mundo comparte la idea y la forma de llevarla a cabo es más fácil avanzar y coger la responsabilidad).

Escribir una historia de usuario no es tan sencillo como coger la típica plantilla "As who, I want what so that why". Requiere algo más que eso !!!!.

Por ejemplo siguiendo esta plantilla podría escribir una historia tal que así:

Como Compañía, quiero que los usuarios de la web pasen más rato en nuestro site porque así tendremos más posibilidades de ingresar dinero por publicidad.

Como historia podría ser una historia válida, no lo niego. Pero si paso esto a uno de mis equipos para que valoren la historia tengo dos opciones: una que den una estimación sobre algo que no se aproxime a lo que el cliente tiene en la cabeza o dos que me tiren la historia a la cabeza y salga en la próxima retrospectiva en el lado negativo de la pizarra (yo me decanto por esta segunda :-) ).

En primer lugar, una historia de usuario debe ser concreta en su explicación, debe expresar de una forma inequivoca la funcionalidad que se desea implementar.

¿Esto implica que escribir como quiero que la implemente? No !!.

¿Esto implica que debo escribir una historia de dos páginas? No !!

En primer lugar el Product Owner debe adaptarse al equipo, a la forma de entender las cosas, a su forma de interactuar, a su lenguaje. Cada equipo es un ecosistema en si mismo independientemente de las normas tanto formales como informales de la compañía en la que estén. Esta sintonía no se genera de la noche a la mañana requiere dar un paso tras otro, por tanto la respuesta a ¿Cómo consigo esto? es: simple prueba y error juntado con una pizca de empatía.

Por tanto, la historia de usuario debe explicar de una forma clara para el equipo de que se desea obtener con ella. Por otro lado debe dejar claro también que criterios se utilizarán para validar que el resultado de dicha historia cumple con los objetivos para los que fue creada. De esta forma el equipo podrá validar que su trabajo se está desarrollando acorde con el plan establecido y evitará sorpresas al final de sprint.

¿Cuánto debe durar un sprint en Scrum?

Cuando empezamos a utilizar Scrum en nuestra empresa una de las primeras preguntas es: ¿Cuánto deben durar nuestras iteraciones (sprints)? La respuesta como en la mayoría de casos es depende. Pero claro, supongo que esta respuesta no es la que esperabais por lo que voy a intentar daros unas pistas para que con la experiencia podáis decidir cuál será la duración de vuestros sprints.

Primero de todo una observación, el libro blanco de Scrum nos dice que una vez hemos establecido la duración de nuestros sprints está debe mantenerse para todos nuestros posteriores sprints. Esto es cierto ya que de esta forma el equipo podrá tomar medidas cada vez más exactas de su velocidad aprendiendo de los sprints anteriores. Pero esto no quiere decir que pasado un tiempo de estudio el equipo pueda tomar la decisión de variar la duración de sus sprints. Hay que pensar que esta metodología promueve la adaptación y el aprendizaje continuo por lo que no hay que tener miedo de modificar algo si el equipo cree que puede ayudar a mejorar el trabajo ofrecido tanto en forma como en resultado.

Una vez entendido el primer punto, mi opinión es que el sprint debe durar el suficiente tiempo para que permita al equipo dar un resultado que ofrezca un valor real. Pero también hay que tener en cuenta otros factores a la hora de tomar la decisión final.

Si nos encontramos en un momento en que estamos creando un nuevo producto es obvio que queramos tener cuanto antes mejor un producto base que nos permita salir al mercado y después ir añadiendo nuevas mejoras que ofrezcan valor a los usuarios finales. En este caso yo recomendaría utilizar sprints cortos (por ejemplo dos semanas) ya que de esta forma podremos adaptarnos de una manera más ágiles a los cambios inherentes a la creación de un producto.

En cambio si ya tenemos un producto consolidado en el mercado con un número elevado de usuarios la utilización de sprints cortos (seguramente con varios equipos scrum) a la larga puede ser contra producente. La primera idea que nos puede venir a la mente es que con sprints más cortos podremos ofrecer más funcionalidades a nuestros usuarios finales. Pero si nos ponemos en la piel de nuestros usuarios (que al final son nuestros clientes y a quienes nos debemos) que nos estén modificando el producto que utilizamos cada día quizás no nos aporte el valor que esperamos. En estos casos yo recomendaría alargar los sprints de los equipos, una buena medida sería de 3 a 4 semanas.

Espero haber aclarado un poco más esta eterna pregunta y recordad que al final la decisión debe ser una mezcla entre valor aportado, paso sostenible y adaptación a nuestros clientes.

¿Medir las historias de usuario en puntos o en horas?

Esta es la eterna pregunta que se realiza en el seno de un equipo scrum al comenzar a usar esta metodología. Los integrantes del equipo están acostumbrados a dar sus estimaciones en tiempo y les resulta extraño medir su esfuerzo en puntos.

Entonces, ¿Por qué medir las historias de usuario en puntos? En este post intentaré dar una explicación para que podáis convencer a vuestros compañeros de las virtudes de medir las historias en puntos.

En primer lugar uno de los puntos que la metodología basada en Scrum intenta resolver es poder dar un dato fiable de cuanto puede producir un equipo en el plazo delimitado de un sprint. Y este es un punto importante ya que el trabajo será realizado por el equipo y no por personas individuales. Si tenemos en un equipo tres programadores: un programador que calificaríamos como superior a la media, un programador senior y un programador júnior. Es de esperar que si asignamos la misma tarea a los tres programadores el tiempo para resolverla de cada uno será diferente, por ejemplo:

                 El programador junior resolverá la tarea en H horas.

                 El programador senior resolverá la misma tarea en H/2 horas.

                 Y el programador experto resolverá dicha tarea en H/3 horas.

Cogiendo este ejemplo como premisa, cuando nuestro Product Owner asigne esta tarea al equipo deberemos gestionar las diferentes tareas asignándole una persona en concreto para poder dar una estimación clara de cuantas historias podremos realizar en un sprint. Obviamente esto supone un exceso de gestión que nos devuelve otra vez a las metodologías convencionales. Además nos obligará a asignar las tareas complejas siempre a las mismas personas y esto no ayudará a que el resto del equipo madure y coja confianza.

Bueno, ¿Y cómo nos olvidamos de las horas/hombre y empezamos a medir por puntos?.  Empecemos por tener una escala de puntuación base para cualquier tarea. Normalmente se utiliza los puntos asignados en las cartas de poker planning. Los valores de estas cartas son: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 e infinito. Hay que tener en cuenta que la puntuación escogida además de darnos una aproximación de cuanto puede costar desarrollar una tarea también lleva un factor de incertidumbre que aumenta a medida que el número de puntos aumenta.

El valor 0 indica que una historia de usuario es muy simple y que puede estar realizada con un esfuerzo mínimo e infinito indica que la historia es tan compleja que no hay manera de saber cuanto se puede tardar en realizarla (en este caso la historia deberá ser troceada en historias más pequeñas con la finalidad de poder medirlas con más detalle)

El paso más adecuado para empezar a cambiar la forma en que medimos nuestro trabajo sería escoger una historia de usuario que todos consideremos como la más simple (por ejemplo realizar un formulario con tres campos) y preguntar a todos los miembros cuantos puntos de esfuerzo asignarían a esta tarea. El programador experto pensará "bueno esto lo puedo realizar en 3 horas", el programador senior pensará "seguro que necesito 4,5 horas para acabar la historia" y el programador júnior pensará "como mínimo necesito 9 horas para tener la historia terminada". Basándose en sus experiencias en horas intentaran hacer su primera traducción a puntos de historia, después de alguna que otra discusión acordarán una puntuación para dicha historia, por ejemplo 2 puntos.

Bien, en ese momento ya tendremos una historia de referencia. Las siguientes historias podrán basarse en ella. El equipo podrá decidir si la siguiente historia es más o menos difícil que la historia que ya ha puntuado y asignarle una puntuación según la escala definida en las cartas de planning poker. Este proceso se irá realizando hasta que el equipo considere que no puede realizar más historias en un sprint. Llegado a este punto el equipo podrá decir cuantos puntos en total realizará durante el transcurso de dicho sprint.

¿Quiere decir esto que el equipo ya está en disposición de medir las historias en puntos? La respuesta es sí y no. Es un comienzo pero los resultados se irán viendo sprint tras sprint. A medida que el equipo vaya utilizando la metodología irá refinando su forma de puntuar las historias y dará una aproximación más certera en sus previsiones. No podemos esperar que el equipo acierte a la primera en sus predicciones pero con la confianza necesaria y el trabajo constante iremos viendo como el equipo evoluciona y progresa.

Con el tiempo la eterna pregunta ¿Pero que es un punto? irá desapareciendo de nuestros sprint planning. El equipo irá adaptando de una forma natural su forma de puntuar. En ese estadío podremos tener la certeza que cualquier historia de usuario será realizada por cualquier miembro del equipo y que el esfuerzo dedicado será el que el equipo puntuó en el momento de valorar la historia independientemente de quién la realice.

El rol del Scrum Master en un equipo Scrum

Como siempre empecemos por una pequeña descripción que nos proporciona nuestra querida Wikipedia:

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El Scrum Master se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

Bueno, ahora que ya tenemos un punto de partida pasemos a desarrollar esta figura dentro de Scrum. La primera pregunta que podría venir a la mente de un neófito es: ¿Por qué el Scrum Master no es un líder?  Buena pregunta, como digo siempre las cosas han de hacerse paso a paso. Un equipo scrum sin un líder establecido es el estadío ideal pero para llegar hasta este punto hay que recorrer un largo camino donde tanto el Scrum Master como el equipo deben ir pasando por unos estados de madurez que les permita llegar a este nirvana existencial. Pasemos a ver en que diferente momentos se encontrará un equipo antes de poder decir que la definición de la Wikipedia es la que define su equipo.

Primer estadío, el Scrum Master yo antes era jefe de proyectos. En este momento el equipo acaba de empezar su singladura, venimos de un modelo tradicional de desarrollo donde existen unos roles y una funcionalidades muy marcadas. El Scrum Master-Jefe de Proyectos reparte el trabajo, define las tareas a implementar y su orden junto con el Product Owner. El equipo suele estar agazapado tras él. La frase "tránquilos ya me encargo yo" está al orden del día. En definitiva el Scrum Master sigue desarrollando su rol de Jefe de Proyectos  pero se ha cambiado el nombre. Empezamos a aplicar los procesos de scrum pero el equipo sigue teniendo la sensación de que reporta su trabajo al Jefe del equipo en lugar de explicar su trabajo al resto del equipo. El Scrum Master modera las reuniones, establece el orden y hay esa sensación de que los miembros del equipo buscan su aprovación cuando exponen su opinión. Como he dicho este es el primer estadío, si te encuentras en él no te preocupes. Es un primer paso y quizás el más habitual, nadie nace sabiendo.

Segundo estadío, ser Scrum Master mola ya no soy el responsable de todo. El equipo empieza a rodar, los miembros empiezan a tomar responsabilidades y el Scrum Master aprende a delegar sobre el equipo y esperando que lo va a hacer bien. Ahora que el Scrum Master empieza a dejar ese viejo vicio de ordeno y mando (command and control) comienza a indagar sobre las maneras de mejorar tanto él como el equipo e intenta aplicarlas en el día a día. En estas pruebas de mejora tanto el equipo como él se retro-alimentan en la motivación porque ven que algunas de las prácticas realmente ayudan a poder mantener un paso sostenible con una mejora en el desarrollo. En este estadío las cosas empiezan a funcionar pero también tiene un riesgo, el Scrum Master puede empezar a pensar que ya ha llegado a su cota máxima de perfeccionamiento. Es importante en este punto que tenga los pies puestos en el suelo.

Tercer (pero no último estadío), ahora ya puedo ser un Agile Coacher. Ahora el equipo empieza a estar un estado en el que su dependecía del Scrum Master suele ser mínima, las cosas funcionan con un alto grado de  satisfacción, los miembros del equipo son seniors y saben tomar decisiones (más o menos correctas) tanto individualmente como en equipo, son capaces de solventar los impedimentos como equipo y de plantear nuevas formas de mejoras. Vamos lo que cualquiera llamaría un equipo de alto rendimiento. En este estadío el Scrum Master empieza a ser una figura que parece prescindible y quizá sea uno de los peligros a los que se enfrenta la persona que decidío tomar este rol. ¿Qué hacer al llegar a este nivel? Podemos tomar dos decisiones, la primera es seguir mejorando tanto a nivel personal como ayudando en la organización o podemos pensar que nuestra etapa en la empresa a llegado a su fin y que debemos ir a otro sitio donde podamos ayudar a otros equipos. ¡Esa ya es tu decisión!.

El rol del Product Owner en un equipo Scrum

Empecemos como siempre mirando que nos dice la Wikipedia sobre el rol de Product Owner:

El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

Bueno, como primera aproximación a la definición de este rol no está mal pero cuando empecemos a implementar la metodología y estemos metidos en las trincheras  veremos que este rol es más complejo que una definición de tres líneas.

¿Cómo debe ser la persona que ocupe el rol de Product Owner? Pues desde mi punto de vista debe ser una persona segura de sí misma ya que al ser la puerta de entrada del equipo tendrá la presión de los diferentes clientes que quieren que sus requisitos sean desarrollados antes que el resto. Desde la dirección de la compañía también se le deberá dar potestades al Product Owner para tomar decisiones, ya que de no ser así al final esta figura dejaría de tener valor convirtiéndose en un mero canal de entrada.

El Product Owner tiene que ser un buen escritor de historias. ¿Y qué es esto? Como ya hemos comentado uno de los artefactos más importantes de Scrum son las historias de usuario. El Product Owner es el encargado de escribir dichas historias para comunicar al equipo las diferentes funcionalidades que se incorporarán en un sprint. Por tanto, el Product Owner tiene que hacer foco en adaptar su lenguaje a un lenguaje que el equipo pueda entender. Las historias deben estar bien explicadas y deben quedar claros los criterios de validación de la misma.

Como propietario del producto se encargará de supervisar que los resultados del proyecto son los esperados y que se consigue maximizar  la rentabilidad del producto. Esto suena muy bien pero cómo llevar a cabo estas responsabilidades. El Product Owner deberá trabajar estrechamente con el equipo para evaluar que las historias que se desarrollan son las más importantes (priorización de historias). Al inicio de cada sprint deberá re-evaluar las historias para asegurarse que en el próximo sprint las historias que están en lo más alto de la pila son las que permitirán dar un mayor valor tanto al producto como al cliente final. También participa en la presentación del resultado obtenido tras cada sprint validando que las soluciones implentadas cumplen con los criterios de validación (en un entorno ideal esta tarea debería realizarse durante el sprint con la finalidad de adelantarnos a posibles desviaciones).

Ahora imaginemos que queremos desarrollar nuestros productos en nuestra empresa utilizando metodologías ágiles. Ya tenemos un equipo de trabajo y queremos aprovecharlo. ¿Qué perfil se adecúa mejor a este nuevo rol? La respuesta como en muchos casos es depende. Si nuestra compañía es una empresa final, seguramente tendremos un departamento de producto y un departamento de desarrollo. La solución más fácil es escoger un Product Manager para el puesto de Product Owner. En cambio, si estamos en una empresa dedicada a ofrecer servicios a terceros quizás la aproximación más razonable sería la transición de Jefe de Proyectos a Product Owner ya que este perfil cumplirá muchos de los requisitos que hemos definido anteriormente.

Otra pregunta que suele surgir muy a menudo es: ¿El Product Onwer se debe mantener fijo en el tiempo para un equipo o debe variar según el desarrollo que se realiza? Mi opinión es que el Product Owner debe ser siempre el mismo para un equipo Scrum. ¿Por qué? Cada equipo Scrum tiene su propio ecosistema, lo que funciona en un equipo puede no funcionar en otro. La adaptación entre las diferentes personas que conforman el equipo lleva su tiempo, cuanto más se conocen las personas más se refuerzan los lazos de identidad y el trabajo debería mejorar. Si vamos cambiando en el tiempo al Product Owner siempre tendremos un tiempo de aclimatación (como comprenden mejor las historias los miembros del equipo, que se les puede pedir y que no, que les motiva, etc.). Obviamente esto influye directamente en el rendimiento del equipo.

Roles dentro de un equipo Scrum

Un equipo scrum está formado por personas con conocimientos diferentes per que se complementan para llevar a cabo el trabajo. Todo los miembros son importantes, además tiene voz y voto en las decisiones a tomar (ya comentamos en posts anteriores que un equipo scrum es autogestionado).

Aún así dentro del equipo hay unos roles determinados que son primordiales para que el equipo evolucione y consiga llegar a unas cotas de máxima productivad combinada con un paso sostenible.

A continuación pasaré a detallar estos roles y sus deberes con el equipo.

Product Owner

El rol del Product Owner es uno de los más importantes y delicados dentro de un equipo de Scrum (si bien estrictamente no forma parte del equipo como tal). La persona encargada de este rol tiene que saber hablar tanto el lenguaje del cliente como el lenguaje del equipo. Es el encargado de planificar y priorizar las tareas que desarrollará el equipo en cada sprint. No sólo tiene que estar focalizado en el sprint actual sino tener una visión a largo plazo. Es el único punto de entrada de trabajo en el equipo.


Scrum Master

Como norma general suele ser un miembro del equipo. Es el encargado de mantener el foco en las reglas y procesos del desarrollo ágil. Como suele ser un perfil senior debe encargarse de ayudar al resto de miembros del equipo para que crezcan dentro del sino del equipo. A su vez se encarga de facilitar las reuniones. En su rol también se encarga de solventar los impedimentos que afectan al equipo, además debe hacer incapie en proteger al equipo de interrupciones externas durante la ejecución de un sprint.

Team Member

Quiero destacar que no menos importante es la labor de los miembros del equipo scrum. Si los miembros del equipo se comprometen con la nueva forma de trabajar por mucho esfuerzo que ponga el Scrum Master la implementación de la metodología puede ser muy traumática. Poco a poco los miembros del equipo tienen que colaborar en la autogestión del mismo y también deben ir cogiendo más responsabilidad tanto en las tareas del equipo como en las formas para conseguir mayores cotas de productividad. Su colaboración e implicación en las reuniones que completan el proceso seguro ayudarán a conseguir estos objetivos. En un equipo consolidado debería ocurrir que el liderazgo del Scrum Master poco a poco se fuera diluyendo en el equipo ya que todos los miembros del mismo tienen ya asilimada tanto la metodología como que deben hacer para mejorar sprint tras sprint.

Scrum y sus artefactos

En el anterior post describí en líneas generales en que consiste Scrum. A partir de ahora iremos profundizando más en la metodología, en este post veremos los diferentes artefactos que utilizaremos.

Historia de usuario (user story)

El primer artefacto del que hablaremos serán las historias de usuario (user stories). Una historia de usuario es la definición de un requisito (normalmente una funcionalidad) que el equipo deberá desarrollar como parte de un sprint. Normalmente las historias de usuario se escriben en post-its o tarjetas.

¿Por qué un post-it o similar? Es importante que las historias de usuario estén a la vista y presentes durante todo el sprint para servir como recordatorio del trabajo al que se ha comprometido el equipo, además debemos poder moverlas para indicar en que estado están en todo momento. Pero también tienen que desaparecer una vez el sprint haya terminado y la tarea haya sido completada. ¿Cómo hacer esto? Qué os parece pegar la historia en la pared más cercana al equipo, o mejor en un tablero.

Tablero scrum (scrum board)

El principal objetivo del tablero scrum es mostrar de una forma clara y sencilla el estado del sprint en cada momento. En el deberá quedar reflejado en que estado están las historias de usuario incluidas en el sprint, qué miembros del equipo están trabajando en cada historia, si hay alguna desviación en el trabajo planificado, etc. En definitiva, el tablero es tanto un espacio para la sincronización del equipo como un testigo del estado del proyecto.

Burndown

El Burndown es una gráfica que nos permite ver cuantos puntos de historia deberiamos hacer cada día para llegar al final del sprint con todas las historias finalizadas. Cada día en el Scrum Daily Meeting los miembros del equipo informarán al resto de los puntos que se han hecho de cada historia el día anterior y quedarán informados en el Burndown.

En nuestra gráfica tendremos dos ejes. El eje de las Y nos indicarán los puntos de historia y el eje de las X nos informará de los días hábiles del sprint. Por otro lado marcaremos al inicio del sprint una línea que irá desde los puntos que se estimaron por el equipo que se iban a realizar durante el sprint hasta el último día del sprint. Durante el sprint iremos actualizando una segunda gráfica con los puntos realizados de historia, cuanto más cerca este esta segunda gráfica de la línea inicial más cerca estaremos de cumplir nuestros objetivos fijados (aunque veremos en posteriores posts que esto es la teoría y que la práctica es un poco más difícil ... ¡Ey, nadie dijo que todo fuera fácil!)