Spike qué es y cómo utilizarlo en equipos Scrum

05/04/2023
Un Spike es un experimento destinado a responder a una pregunta o a recopilar información, más que a producir un producto que se pueda entregar al mercado. A veces se genera una historia de usuario que es imposible de evaluar (entender: el qué se quiere o como se puede abordar, el nivel de incertidumbre es enorme, no es posible estimarla, etc.) hasta que los developers realizan algún trabajo para resolver una pregunta técnica o un problema de diseño, etc.
Spike en scrum

Si nuestra situación es la que se comentaba antes, una opción es crear un Spike, aunque la verdad yo no lo recomiendo mucho, mas adelante veremos por que. Según Mike Cohn, un Spike es como una actividad de investigación para dividir una historia de usuarios compleja y grande . De hecho lo especifica en su modelo S.P.I.D.R de división de historias de usuarios. Otros ven el Spike como un elemento en el Backlog que tiene el propósito de proporcionar una respuesta o solución a un reto o problema que hay:

dividir historias con spider de mike cohn

Origen del término Spike

El término spike proviene de eXtreme Programming (XP), donde «Una solución spike es un programa muy simple para explorar soluciones potenciales». Ward Cunningham describe cómo se acuñó el término en la wiki C2.com: «A menudo le preguntaban a Kent [Beck]: ¿Qué es lo más sencillo que podemos programar que nos convenza de que vamos por el buen camino?. Descubrir los reto mediante experimentos a menudo nos llevaba a soluciones más sencillas y convincentes». Kent lo llamó Spike.

Cómo introducir el Spike en el Product Backlog o Sprint Backlog

Como cualquier elemento del Product Backlog, el Spike no será menos, debemos de introducirlo en el Backlog y debe de ordenarse con el resto de PBIs. A la hora de crearlo, tenga en cuenta lo siguiente:

  • ¿Para qué hacemos este spike?: objetivo
  • ¿Qué resultados esperamos conseguir?: resultados clave
  • ¿Qué mejoraría en el producto o en los usuarios? : impacto
  • ¿Cuáles son los puntos complejos, con incertidumbre que queremos investigar o experimentar?: Guía

Luego en la Sprint Planning se debe de tener en cuenta a la hora de crear el Sprint Backlog y el Spike estará ahi también.

Y la pregunta del millón: ¿Hay que estimarlo? pero si no tenemos ni idea de lo QUÉ hay que hacer ni del CÓMO hacerlo… estamos locos… 😛

Indica TimeBox para los Spike’s

Una manera de controlar los spike’s es indicar Timebox, un día, dos, tres, lo que se acuerde con el equipo. Al final de este experimento se comparten los aprendizajes, feedback, etc. esto quizás pueda dar lugar a otro experimento. 

Lo que quieres hacer como organización es maximizar el número de experimentos que puedes hacer por unidad de tiempo

Jeff Bezos, Harvard Business Review

Un dato relevante a la hora de utilizar Spike’s, es intentar abordar retos específicos y NO muy grandes, ya que sino es posible que no se consigan los resultados en el timebox que te se ha marcado o se puede tardar mucho en recoger feedback.

¿Qué no es un Spike?

Un Spike no es una fase de análisis de una historia, en otras palabras, tengo Product Backlog Item, donde no sé que linea de código tocar, pues listo, hago un spike para investigar y luego desarrollo el PBI… ¡Pues NO!

Comentar que la verdad nunca estoy a favor del uso de los sipke’s, ya que parece como una declaración de pedir permiso a no sé quién para hacer un experimento, entonces, ¿dónde queda eso de la autoorganización y la autogestión y que los developers se encargan del CÓMO? . Al final las historias de usuario o PBIs, son hipótesis, que se requieren de validar y para ello se genera un incremento y se entrega al mercado o usuario y se recoge feedback. En un video de Todd Miller lo comenta bien claro, aunque, desde mi humilde punto de vista, no hay que ir ni a un extremo ni otro 😉

El mayor riesgo de trabajar con los Spikes en un Scrum Team es que adopten este tipo de tareas como una herramienta para crear análisis técnicos detallados, planes y diseños detallados. ¡Un Spike es una excepción, no la regla!

Quizás pueden ayudar pero el exceso en su uso puede ser malo. Siempre en su justa medida.

¿Te ha gustado este contenido?

¡Valora este contenido!

Promedio de puntuación 5 / 5. Recuento de votos: 4

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Escrito por: Youssef Oufaska
Amo las actividades en familia, aficionado a la salsa cubana, bachata dominicana, desarrollo de productos digitales y la programación

Otras publicaciones

Agile Product Management

Agile Product Management

Diferencia entre Project mindset y Product mindset El Project Mindset fomenta e impulsa el éxito utilizando métricas internas (esas KPIs) que...

leer más
Apúntate a la newsletter

Apúntate a la newsletter

Manténte informado sobre todo lo relacionado con Agile Product Management, Scrum, Management 3.0 y Kanban

¡Mensaje enviado!

Training from the BACK of the Room!

 11 y 12 de noviembre en Madrid

Facilitado por Jose Casal

You have Successfully Subscribed!