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!)

¿Qué es SCRUM?

Creo que la primera entrada de este blog, por obligación, debe ser una explicación de qué es Scrum, para que se utiliza y qué beneficios aporta en frente a las metodologías convencionales basadas en desarrollos en cascada.

Para empezar vamos a ver que nos dice Wikipedia sobre SCRUM:

Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.
Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums.

Bueno, ahora que ya tenemos una definición sobre que es Scrum pasemos a entrar en detalle sobre la metodología.

Primer detalle a tener en cuenta para aplicar Scrum en tu empresa: La dirección de la misma debe estar completamente convencida de que quiere aplicar este tipo de metodología ágil. De no ser así el resultado puede ser cuanto menos decepcionante. La aplicación de metodologías como Scrum requiere un cambio de mentalidad y requiere esfuerzo e implicación. Para empezar requiere que se cambie el modelo de distribución de las personas. Normalmente las empresas están organizadas en departamentos que interactúan entre ellos para realizar tareas complejas. En un ámbiente de metodología ágil las personas se distribuyen en equipos multidisciplinares y autogestionados que actúan como una unidad para llevar a cabo un proyecto asignado desde principio a fin.

Bueno, una vez tenemos una empresa que ha tomado la decisión de trabajar de una forma ágil deberemos montar los equipos necesarios para realizar las tareas necesarias para conseguir los objetivos empresariales. ¿Y cómo formo un equipo Scrum? Pasemos a definir los diferentes roles que deberemos cubrir:

• Product Owner: Este rol se encarga de priorizar y definir las tareas que el equipo deberá realizar. Es el enlace "formal" entre el equipo y los clientes.
• Scrum Master: Es el encargado de que el equipo siga las reglas y los procesos de Scrum.  Además ejerce una figura de facilitador ayudando a quitar impedimentos y protegiendo y aislando al equipo de interrupciones externas.
• Team Member: Cada uno de los miembros del equipo. Cada miembro del equipo comparte la responsabilidad y el objetivo del trabajo que realizan.

Ahora que ya tenemos a nuestros colaboradores organizados por equipos podemos pasar a definir el proceso.

Cuando desarrollamos un proyecto con Scrum, éste deberá ser dividido en espacios temporales que denominaremos iteraciones (sprints en inglés).

Para poder mejorar el proceso, realizar mediciones y responder de una forma ágil al cambio dichas iteraciones deberán estar acotadas en un espacio temporal corto (entre 2 y 4 semanas). Además deberemos asegurar que tras cada iteración el equipo deberá entregar un resultado completo (un paquete de funcionalidades acabadas) o lo que es lo mismo un incremento de producto final que se susceptible de ser entregado con el mínimo esfuerzo al cliente cuando éste lo solicite.

Las acciones que realizará el equipo dentro de una iteración (o sprint) serán las siguientes:

• Reunión de planificación de la iteración (Sprint Planning Meeting): Esta es la reunión inicial de una iteración. En ella el Product Owner presenta al equipo las diferentes funcionalidades (historias de usuario) que son más prioritarias. El equipo, una vez a resuelto sus dudas sobre las funcionalidades, estimará cuanto esfuerzo será necesario para realizar cada una de ellas. Al final comunicará cuanto trabajo es problable que se realice durante la iteración.
• Reunión de seguimiento de la iteración (Daily Scrum Meeting): Cada día de la iteración se realizará una reunión a primera hora del día para realizar un seguimiento del trabajo realizado. En dicha reunión cada miembro del equipo deberá responder a las siguientes cuestiones:
• ¿Qué hice ayer?
• ¿Qué tengo planeado hacer hoy?
• ¿He tenido algún impedimento que no me haya permitido alcanzar mis objetivos?
• Reunión de revisión de la iteración (Sprint Review Meeting): Esta reunión se realiza al final de la iteración. En ella el equipo presentará todas las funcionalidades (historias de usuario) finalizadas durante la iteración a los interesados. También se comunicará que trabajo no ha podido ser finalizado.
• Reunión de retrospectiva de la iteración (Spring Retrospective): Al igual que la reunión de revisión, esta reunión se realizará al final de la iteración. En ella el equipo (sin la participación del Product Owner) analizará como se ha trabajado y que impedimentos han salido durante la iteración. La finalidad de ello es la mejora continua del equipo. Es importante salir de la reunión con acciones concretas para solucionar impedimentos o mejoras del proceso.

En los siguientes posts iremos desgranando los diferentes aspectos de la implementación de Scrum. ¡Nos vemos en el siguiente post!