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:
Indice de contenidos
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.