En este post hablaremos de los spikes Scrum. Se trata de usa de esas palabrejas que se escuchan en el mundillo agile y que no siempre se tiene muy claro de qué va.

Básicamente, podemos decir que un spike representa el esfuerzo dedicado por parte del Equipo de Desarrollo Scrum a algo que no es desarrollar código. Esta es la definición corta.

Te propongo profundizar en este tema y darle un buen repaso a este concepto no demasiado extendido. Ni siquiera en muchas organizaciones que, en principio, trabajan de forma ágil.

Vamos a ello.

Leer másSpikes en Scrum

En el post sobre el Product Backlog estuvimos viendo los distintos ítems o elementos o PBIs (Product Backlog Items) que incluye este artefacto Scrum. Y de entre todos ellos, las Historias de Usuario tienen un papel especialmente relevante ya que recogen las funcionalidades de negocio, y deben por tanto estar escritas por el Product Owner.

En este post profundizaremos en las Historias de Usuario Scrum. Veremos que son, su formato y cómo escribir buenas Historias de Usuario.

Adelante!!

Leer másHistorias de Usuario

Scrum no requiere de complejas plataformas ni software sofisticado. Todos conocemos la historia de amor entre Scrum y los postits. Y es que nos basta con una pared vacía, unos rotuladores y unos postits para poder aplicar un Scrum que haría emocionarse al mismísimo Jeff Sutherland.

Como ya sabrás, en Scrum el Product Backlog es una pila, es decir, una lista priorizada de ítems de diversa naturaleza (requisitos funcionales, requisitos técnicos, descripción de incidencias, etc).

Pues bien, a efectos prácticos ¿cómo representamos el Product Backlog? ¿cómo almacenamos esa información para que sea cómoda de manejar, comprensible y transparente a todos?

En este post haré una comparativa entre crear un Backlog físico y crear un Backlog virtual mediante alguna herramienta software.

Veamos.

Leer másProduct Backlog Físico vs Product Backlog Virtual

En Scrum, el Product Backlog, o Pila de Producto, o Lista de Producto, es, valga la redundancia, reflejo del producto que pretendemos crear.

Podemos compararlo con el catálogo de requisitos de toda la vida, o con el catálogo de casos de uso. Sea como fuere, debe recoger todas las funcionalidades que describen el producto.

Pero además debe registrar todas aquellas tareas técnicas relacionadas con la construcción de dicho producto. Por tanto, el Product Backlog va más allá de los requisitos de negocio, de forma que podemos considerar que todo aquello que no aparezca en el Backlog directamente no existe.

Unificar y centralizar todo lo relacionado con un producto en un único documento (artefacto, le llama la Guía) tiene una enorme ventaja de cara a la transparencia. Se acabó eso de te lo indiqué en un correo, o aquello de eso está recogido en una excel en el repositorio, o eso otro de yo ya lo dije en aquella reunión…

Insisto: lo que no está en el Product Backlog no existe.

Por tanto, ya que el Product Backlog o Lista de Producto es la representación viva del producto, hay que procurar saber darle el tratamiento adecuado, ya que un mal Backlog conducirá inevitablemente a un mal producto.

Leer másEl Product Backlog

Si hay un rol de Scrum controvertido y que más confusión genera es el del Scrum Master, la tercera pata del Equipo Scrum junto con Product Owner y Equipo de Desarrollo.

El motivo de esta polémica es que no queda muy claro en la Guía en qué se traduce, siendo prácticos, eso de líder-servicial, o eso de eliminar impedimentos al Equipo de Desarrollo, o eso de facilitar.

Porque, ¿Qué significa exactamente eso de eliminar impedimentos? ¿o actuar como líder-servicial? ¿en qué consiste y cómo se hace eso, sobre todo si soy un Scrum Master con poca experiencia?

En este post profundizaremos en esta interesante figura y trataremos de descifrar cuáles son las verdaderas competencias del Scrum Master.

Al lío.

Leer másEl Scrum Master