Metodología Scrum: qué es y cómo funciona

Orígenes del Scrum

El término Scrum (traducido del inglés como melé) fue acuñado y definido por Ikujiro Nonaka e Hirotaka Takeuchi en los años 80, cuando las principales empresa de desarrollo tecnológico empezaban a dominar el mercado y a definir formas de trabajo. Ambos publicaron en 1986 en la Harvard Business Review el artículo “El nuevo nuevo juego para el desarrollo de productos”. Así abrieron la puerta al Scrum.

El avance de las formaciones de las melés en los partidos de rugby, inspiró a Nonaka y Takeuchi para bautizar una nueva forma de trabajar que ya venía dándose en muchas empresas tecnológicas como Honda, Canon y Fuji-Xerox. 

«El enfoque de las ‘carrera de relevos’ para el desarrollo de productos entra en conflicto con el objetivo de obtener la máxima velocidad y flexibilidad. En su lugar un enfoque como el rugby (donde el equipo intenta avanzar como equipo, enviando el balón hacia atrás y luego avanzar) sirve mejor al tipo de desarrollo que necesitamos hoy en día». Por eso Scrum y equipo auto-organizado van siempre de la mano.

En 1993, Jeff Sutherland y su equipo en Easel Corporation adaptaron la metodología Srcum al desarrollo del software (Software Development Process). El método Scrum estaba ahora orientado a objetos, a un control de procesos empírico, desarrollo iterativo e incremental, a una mejora continua de la productividad, así como al desarrollo de sistemas complejos y ágiles.

Así pues, hoy en día el Scrum se aplica a cualquier proyecto que necesite de una metodología ágil y de una gestión muy flexible orientada a objetivos y resultados concretos. El Scrum es perfecto para desarrollar software o construir webs, pero también para fabricar coches e incluso edificar casas.

¿Qué es SCRUM?

Scrum es una metodología ágil que permite realizar proyectos más orientados a las necesidades de la empresa y de los clientes, de una forma más eficiente y en un menor plazo de tiempo, a través de un marco de trabajo colaborativo que permite generar equipos de alta productividad.

Scrum se basa en una iteración continua, donde se realizan pequeñas actividades para construir un producto o proyecto de forma incremental, entregando en cada iteración una propuesta de valor cada vez más desarrollada. Scrum es la más utilizada de las llamadas metodologías ágiles de desarrollo de proyectos.

Los principios del Scrum son simple pero no fácil de aplicar. Las compañías que consiguen implementarlos, consiguen mejoras de 4 a 10 veces en productividad, time-to-market y competitividad. A pesar de las mejoras que aporta, muy pocas compañías consiguen vencer sus propias resistencias y conseguir todos los beneficios del Scrum.

El nombre Scrum, no es un acrónimo, proviene del Rugby y significa melé, y al igual que en Rugby,  todos los jugadores actuan como una unidad para hacer avanzar la pelota. En Scrum todos los componentes de un equipo  realizan actividades de forma iterativa e incremental para desarrollar el proyecto.

A la hora de poner en marcha un proyecto, toda empresa debe asegurar que el equipo implicado conoce sus tareas y plazos de tiempo de entrega. Scrum es una metodología de trabajo que nos ayuda a conseguirlo y que, además, permite agilizar la entrega de valor al cliente en iteraciones cortas de tiempo.

La metodología Scrum 

es un marco de trabajo o framework que se utiliza dentro de equipos que manejan proyectos complejos. Es decir, se trata de una metodología de trabajo ágil que tiene como finalidad la entrega de valor en períodos cortos de tiempo y para ello se basa en tres pilares: la transparencia, inspección y adaptación. Esto permite al cliente, junto con su equipo comercial, insertar el producto en el mercado pronto, rápido y empezar a obtener ventas 

¿En qué se basa la metodología Scrum?

Dentro de las metodologías agiles, Scrum se basa en aspectos como: 

  • La flexibilidad en la adopción de cambios y nuevos requisitos durante un proyecto complejo.
  • El factor humano.
  • La colaboración e interacción con el cliente.
  • El desarrollo iterativo como forma de asegurar buenos resultados.

Los pilares o características de la metodología Scrum más importantes son 3:

1. Transparencia

Con el método Scrum todos los implicados tienen conocimiento de qué ocurre en el proyecto y cómo ocurre. Esto hace que haya un entendimiento “común” del proyecto, una visión global.

2. Inspección

Los miembros del equipo Scrum frecuentemente inspeccionan el progreso para detectar posibles problemas. La inspección no es un examen diario, sino una forma de saber que el trabajo fluye y que el equipo funciona de manera auto-organizada.

3. Adaptación

Cuando hay algo que cambiar, el equipo se ajusta para conseguir el objetivo del sprint. Esta es la clave para conseguir el éxito en proyectos complejos, donde los requisitos son cambiantes o poco definidos y en donde la adaptación, la innovación, la complejidad y flexibilidad son fundamentales.

Roles en el equipo Scrum

Con la metodología Scrum, el equipo tiene como foco entregar valor y ofrecer resultados de calidad que permitan cumplir los objetivos de negocio del cliente.

Para ello, los equipos de Scrum son auto-organizados y multifuncionales. Es decir, cada uno es responsable de unas tareas determinadas y de terminarlas en los tiempos acordados. Esto garantiza la entrega de valor del equipo completo, sin necesidad de ayuda o la supervisión minuciosa de otros miembros de la organización.

En Scrum existen 3 roles muy importantes : Product Owner, Scrum Master y Equipo de desarrollo.

 1. Product owner:

Es el responsable de maximizar el valor del trabajo del equipo de desarrollo. La maximización del valor del trabajo viene de la mano de una buena gestión del Product Backlog, el cual explicaremos más adelante.

 El Product owner es el único perfil que habla constantemente con el cliente, lo que le obliga a tener muchos conocimientos sobre negocio.

Para finalizar, un equipo Scrum debe tener solo un Product Owner y este puede ser parte del equipo de desarrollo. 

2. Scrum Master:

Es el responsable de que las técnicas Scrum sean comprendidas y aplicadas en la organización. Es el manager de Scrum, un líder que se encarga de eliminar impedimentos o inconvenientes que tenga el equipo dentro de un sprint (que ya revisaremos en detalle más adelante), aplicando las mejores técnicas para fortalecer el equipo.

Dentro de la organización, el Scrum Master tiene la labor de ayudar en la adopción de esta metodología en todos los equipos. 

3. Equipo de desarrollo:

Son los encargados de realizar las tareas priorizadas por el Product Owner. Es un equipo multifuncional y auto-organizado. Son los únicos que estiman las tareas del product backlog, sin dejarse influenciar por nadie.

page34image32545008

Los equipos de desarrollo no tienen sub-equipos o especialistas. La finalidad de esto es transmitir la responsabilidad compartida si no se llegan a realizar todas las tareas de un sprint. 

Los hitos de la Metodología de trabajo Scrum

Principios  SCRUM

page32image44278512

Proceso Scrum

El desarrollo iterativo se realiza en un sprint, que contiene los siguientes eventos: sprint planning, daily meeting, sprint review y sprint retrospective.

Se compone de los artefactos

1. Sprint

El corazón de Scrum es un Sprint, es un intervalo prefijado de tiempo (no inferior a una semana ni superior a un mes) durante el cual se crea un incremento de producto “Hecho o Terminado” utilizable, potencialmente entregable. A lo largo del desarrollo de construcción hay Sprints consecutivos de duración constante.

En realidad cada Sprint se puede considerar un mini-proyecto dentro de un proyecto mayor. Al igual que los proyectos, los Sprint se utilizan para lograr algo. Cada Sprint cuenta con un objetivo (lo que se va a construir o desarrollar en ese periodo), un método y un plan flexible que guía el proceso. 

2. Planificación del Sprint

En esta reunión todo el equipo Scrum define qué tareas se van a abordar y cuál será el objetivo del sprint. La primera reunión que se hace en el sprint puede llegar a tener una duración de 8 horas para sprints de un mes. 

El equipo se hace las siguientes preguntas:

  • ¿Qué se va a hacer en el sprintEn base a ello, se eligen tareas del Product backlog. 
  • ¿Cómo lo vamos a hacer? El equipo de desarrollo define las tareas necesarias para completar cada ítem elegido del Product Backlog.

La definición de qué se va a hacer implica que el equipo tenga un objetivo y se encuentre comprometido con la entrega de valor que se hará al cliente al final del sprint. A esto se le llama sprint goal.

El resultado de esta reunión es el sprint goal y un sprint backlog (que revisaremos más adelante).

En esta reunión se define el incremento de producto “entregable” que se llevará a cabo, la forma en que el equipo desarrollará el incremento y el trabajo asignado a cada uno.

Al final de la reunión cada miembro el equipo sabe en qué trabajará, qué se espera que haga y la forma en que lo hará posible. Las reuniones de planificación recogen las ideas y aportaciones al proyecto de cualquiera de sus integrantes, de manera que el resultado final de la reunión no es una imposición del “jefe” o del departamento más importante, sino una suma de acuerdos con la que todos los participantes están implicados al mismo nivel aunque con papeles diferentes (como en la melé). 

3. Reunión Diaria

Es una reunión diaria dentro del sprint que tiene como máximo 15 minutos de duración. En ella debe participar, sí o sí, el equipo de desarrollo y el Scrum Master. El Product Owner no tienen necesidad de estar presente.

En esta reunión diaria el equipo de desarrollo hace las siguientes tres preguntas:

  • ¿Qué hice ayer?
  • ¿Qué voy a hacer hoy?
  • ¿Tengo algún impedimento que necesito que me solucionen?

Esta reunión es la más oportuna para poder inspeccionar el trabajo y poder adaptarse en caso de que haya cambio de tareas dentro de un sprint.

Los Scrums diarios mejoran la comunicación, evitan otras reuniones, identifican y eliminan obstáculos para el desarrollo, destacan y promueven la rápida toma de decisiones, y mejoran el nivel de de conocimiento del proyecto del equipo de desarrollo. Esta es una reunión clave de inspección y adaptació

4. Revisión del Sprint

La review del valor que vamos a entregar al cliente se hace en esta reunión, al final de cada sprint. Su duración es de 4 horas para sprints de un mes, y es la única reunión de Scrum a la que puede asistir el cliente. En ella el Product Owner presenta lo desarrollado al cliente y el equipo de desarrollo muestra su funcionamiento. El cliente valida los cambios realizados y además brinda feedback sobre nuevas tareas que el Product Owner tendrá que agregar al Product backlog.

Se lleva a cabo al final del Sprint, para inspeccionar el incremento y adaptar, si es necesario, el Product Backlog. El Equipo Scrum y el cliente colaboran durante la revisión de lo que se hizo en el Sprint. Esta es una reunión informal, y la presentación del incremento está destinada a obtener retroalimentación y fomentar la colaboración. En función de las aportaciones del cliente, pueden recogerse cambios del Product Backlog para introducirlos en el siguiente Sprint.  

5. restrospectiva del Sprint

La retrospectiva es el último evento de Scrum, tiene una duración de 3 horas para Sprints de un mes, y es la reunión del equipo en la que se hace una evaluación de cómo se ha implementado la metodología Scrum en el último sprint.

Es una gran oportunidad para el equipo Scrum de inspeccionarse a sí mismo, proponiendo mejoras para el siguiente sprint.

El resultado: una lista de mejoras que debe aplicar el siguiente día, ya que al finalizar la retrospectiva, inmediatamente comienza un nuevo sprint, que incluye el sprint planning, daily meeting, sprint review y la ya mencionada sprint retrospective.

Herramientas para la metodología Scrum

Las herramientas que se utilizan en Scrum están definidas para maximizar la transparencia dentro del equipo; es decir, que todos tengan una misma visión de lo que está ocurriendo en el proyecto

Es la oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y crear un plan de mejoras para ejecutar durante el siguiente sprint. El propósito de la retrospectiva de Sprint es:

  • Revisar cómo fue el último Sprint en lo que respecta a las personas, relaciones, procesos y herramientas;
  • Identificar y ordenar los temas principales que salieron bien y las potenciales mejoras, y
  • Crear un plan para la implementación de mejoras con respecto a cómo el Equipo Scrum hace su trabajo.

Las herramientas o artefactos principales de Scrum

 son: product backlog y sprint backlog.

1. Product backlog

Básicamente, el product backlog es el listado de tareas que engloba todo un proyecto. Cualquier cosa que debamos hacer debe estar en el product backlog y con un tiempo estimado por el equipo de desarrollo.

La responsabilidad exclusiva de ordenar el product backlog es del Product Owner, que se encuentra en constante comunicación con el cliente para asegurarse de que las prioridades están bien establecidas.

La ordenación también es 100% responsabilidad del Product Owner, por lo que las tareas que están más arriba deben de ser las de mayor prioridad.

El equipo de desarrollo elige tareas del product backlog en el sprint planning para generar tanto el sprint backlog como el sprint goal.

2. Sprint backlog

Es el grupo de tareas del product backlog que el equipo de desarrollo elige en el sprint planning junto con el plan para poder desarrollarlas. Debe ser conocido por todo el equipo, para asegurarse de que el foco debe estar en este grupo de tareas.

El sprint planning no cambia durante el sprint, solo se permite cambiar el plan para poder desarrollarlas.

Los principales beneficios de Scrum

La implantación de los métodos de trabajo Scrum para el desarrollo de proyecto aporta ventajas respecto a los sistemas tradicionales.

  • El cumplimiento de las expectativas del cliente con el proyecto desarrollado gracias a la presentación de las demos de Sprint al cliente (Product Owner) que proporcionan un feedback al equipo.
  • Mayor flexibilidad ante los cambios, la metodología está pensada para adaptarse a los cambios, ya sean éstos requerimientos del cliente o modificaciones del mercado.
  • Reducción del Time To Market, al desarrollar las partes más importantes al inicio, el cliente dispone de partes de valor que puede empezar a utilizar antes.
  • Aumento de la productividad de los equipos de la empresa a los que se les otorga mayor autonomía para organizarse y mayor libertad, reduciendo protocolos y burocracia.
  • Reducción de los riesgos debido a que primero se validan las funcionalidades más importantes del proyecto, lo que permite anticiparse a los riesgos que puedan surgir.
  • Scrum es muy fácil de aprender: los roles, hitos y herramientas son claros y tienen un objetivo por lo que es un método muy relacionado con nuestra manera diaria de trabajar.
  • El cliente puede comenzar a usar el producto rápidamente.
  • Se agiliza el proceso, ya que la entrega de valor es muy frecuente.
  • Menor probabilidad de sorpresas o imprevistos, porque el cliente está viendo frecuentemente el proyecto.

Algunos incvenietes de la metodología Scrum

  • Aunque Scrum sea fácil de aprender, es muy difícil implementarlo. Esto supone una predisposición y un cambio de cultura de la organización que debe ir desde los altos mandos hasta los clientes.
  • La necesidad de tener equipos multidisciplinares puede ser un problema, ya que es difícil encontrar personas que sean capaces de hacer todo el trabajo de un equipo.
  • El equipo puede tender a realizar el camino más corto para conseguir el objetivo de un sprint, el cual no siempre ofrece resultados de calidad.

Pero yo soy de los que me quedo con grandes ventajas y por eso hoy dia es tan popular y es la herramienta de proyectos mas elegida entre las start-ups

SOFTWARE PARA SCRUM: TRELLO

Cómo implementar la metodología ágil Scrum en Trello para tu equipo de desarrollo

Crea tus listas en Trello

Aquí es donde Trello trae la magia a Scrum:

Ahora que ya has definido cuál es tu meta final, sólo debes crear un tablero Trello para añadir todas las tareas desglosadas!

Crea tarjetas que correspondan a tareas que quieres emprender. Ten en cuenta que no deberías tardar más de una semana en completar la tarea, de lo contrario quiere decir que probablemente debes desglosar todavía más esa tarea.

Construye tu backlog primero, después haz una lista para “Por hacer”, “Haciendo” y “Hecho”. (Puedes llamarlas como tu quieras. Yo llame mi primera lista “A bordo” en lugar de “Por hacer”).

Añadir una lista “En revisión” es útil como lugar de espera si tienes muchos asuntos que necesitan revisión. Otra lista que puedes incluir es “Posponer para la siguiente semana” para todo lo que no pudiste completar en el sprint. Esto no debería pasar frecuentemente, y si sucede, deberías analizar por qué está sucediendo.

Planea tu primer sprint

Ya creaste tus listas y algunas tareas en tu backlog. ¡Ahora ya puedes planear tu primer sprint!

El Product Owner debería hacer una parte de la planificación antes de que todos se reúnan. Esta persona deberá revisar el backlog y examinar cuidadosamente cada tarjeta para determinar cuánto esfuerzo implica un tarea, el posible valor que puede resultar de eso, las fechas de entrega asociadas y prioridades generales del equipo.

Durante la primera reunión de planificación del sprint, el Product Owner debe decidir cuáles son las tareas que se van a incorporar al sprint. Es claro que debe haber una discusión con el equipo para que todos estén de acuerdo con estas iniciativas. Aunque el Product Owner tiene la decisión final, no es una dictadura y la retroalimentación de todos se debe tomar en cuenta.

Una vez que decidiste cuáles son las piezas que se van a agregar al sprint, necesitas agregar “story points” (o puntos de historia en español). Los story points son números asociados a una tarea, que indican cuánto esfuerzo se está invirtiendo en una tarea. Algunos equipos utilizan, en lugar de números, un sistema de tallas de playeras (XS, S, M, L, XL). Esto no es para medir exactamente el número de horas de esfuerzo que involucran las tareas, más bien es para ayudarte a darte cuenta de la cantidad de esfuerzo relativo invertido con respecto al de otras tareas.

Por ejemplo, le asignaste un 5 a “escribir una entrada en el blog”, y un 1 a “escribir entradas en Facebook”, por que uno requiere mucho más trabajo que el otro (o se puede pensar en un talla grande vs talla chica).

Para determinar los story points o la talla de las playeras, pregúntale a tu equipo. Esto no es algo que decide el Product Owner, más bien algo que se decide en equipo. Cada quien puede proponer un número y discutirlo hasta que se llegue a un acuerdo sobre la cantidad de esfuerzo que implica una actividad. ¡No te conviene que una persona piense que es muy poco esfuerzo y otra que piense que le puede tomar toda una semana! Es muy importante que todos estén en el mismo canal con respecto de esto.

Una vez que haz desglosado las tareas, estas listo para empezar tu sprint!

Construye un sprint más robusto

Si apenas estas empezando, no trates de incorporar demasiadas cosas. Mejor, cada semana cuando estés planificando tu sprint, discute sobre el sprint anterior y sobre lo que se puede mejorar. Trata de encontrar la manera de ir mejorando semana a semana. Tip de pro: no incorpores funciones solo para probar cosas nuevas. Busca una función que te permita resolver algún problema específico con el que te estés enfrentando.

Etiquetas

Puedes usar las etiquetas de muchas maneras. Utilízalas cuando quieras darle mayor claridad a tus proyectos. Por ejemplo, puedes usar etiquetas que funcionan como categoría de proyecto. Si estas en marketing, puedes usar “Contenido” o “Materiales para ventas”. Si estas en soporte al cliente, puedes usar “Caso de estudio” o “Onboarding”, etc.

También puedes usar las etiquetas para identificar más detalles de una tarea que se encuentra dentro de una lista. Antes de añadir una lista “En revisión” al tablero de Sprint Marketing, nosotros simplemente utilizamos una etiqueta con el mismo nombre. La etiqueta marca las tareas que se encuentran en la lista “Haciendo” para que se revisen, antes de pasar a la lista “Hecho”. Esto es de gran ayuda cuando hay personas, como el manager, que siempre revisan las iniciativas.

Checklist



Las checklists son estupendas para desglosar todavía más las tareas. En situaciones en las que tienes tareas con muchas piezas pequeñas, una manera estupenda de mantenerla organizada y asegurarse de que ninguna de las tareas se pierda, es con una checklist. También es de mucha ayuda para los miembros del equipo cuando quieren ver en donde se encuentra específicamente esa tarea y que tanto falta para terminarla.

Propietarios

¡Error! Nombre de archivo no especificado.

Cada equipo hace esto un poco diferente. En algunos equipo, no se empieza el sprint hasta que cada tarea tiene asignado un propietario. En otros equipos, puedes empezar sin propietarios, luego cada individuo escoge una tarea y se convierte en el propietario cuando la empiezan. Como sea que decidas hacerlo, Trello te la pone fácil. Puedes asignar un propietario o incluso varios propietarios a cada tarjeta, y después cambiarlo cuando muevas la tarjeta a otra categoría.

Fechas de vencimiento

Idealmente, la mayoría de tus tareas deberán completarse al final del sprint, pero en algunos casos tendrás fechas de entrega específicas antes de que acabe el sprint. Si este es el caso, puedes asignar una fecha de vencimiento en la tarjeta Trello para que quede claro que la tarea tiene una fecha de entrega próxima a vencer. Esto activará recordatorios y notificaciones para que no se te olvide. Si tienes varias tarjetas así, puedes usar el Power-Up Calendario para revisar todo en la vista de calendario.

Visualiza el tablero de Trello en la vista de calendario para saber las fechas de vencimiento de las tareas durante el sprint.

Power-Ups

Si quieres ser más eficiente , existen varias Power-Ups y extensiones de Chrome que te pueden ayudar a obtener mayores beneficios de ágil Scrum y Trello. Mis extensiones favoritas de Chrome son Scrum para Trello, que automáticamente suma los puntos de historia en una tarjeta para que puedas ver los puntos totales en una lista, y Contador de Tarjetas Trello, que cuenta el número de tarjetas en cada lista así como el número total de tarjetas en el tablero.

Existen una docena de Power-Ups diferentes en el directorio de Trello. Aquí te muestro algunas de mis favoritas y cómo las utilizo:

Google Drive: Adjunta archivos o carpetas completas a cada proyecto. Las vistas preliminares de los archivos adjuntos se pueden ver en cada tarjeta, y también muestra cuándo fueron editados por última vez y por quién.

Slack: Mantén a tu equipo al día cuando una iniciativa se mueva a otra etapa redistribuyendo las actualizaciones de Trello en canales de Slack. También puede comentar y mover las tarjetas Trello desde Slack.

Campos personalizados: Si las etiquetas no funcionan muy bien para actualizar cada tarea, los Campos personalizados te puede ayudar. Estos campos te permiten personalizar las tarjetas para que los detalles salten a la vista de inmediato.

Hello Epics: Esto te permite establecer relaciones padre/hijo con tus tarjetas. Me parece muy útil cuando tengo un proyecto enorme que debe ser desglosado en varias tareas largas.


Otras Power-Up muy útiles son BurndownPlanning Poker y Tarjetas Ágiles.

SCRUM : moda y éxito en la actualidad

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR
Aviso de cookies