SCRUM: StoryPoints de Historias No aprobadas Vs CarryOver

StoryPoints de Historias No aprobadas

Hay algunas preguntas que surgen relacionado a historias no aceptadas, alejadas de SCRUM, que tienen como respuesta diferentes estrategias. Ellas son:

¿Qué hacer con los puntos gastados en la historia rechazada?
¿Los puntos gastados quedan como capacity y/o se arrastran al próximo sprint para que figuren en la prómxima velocity?
¿Son puntos perdidos de la velocity o se suman a una próxima velocity?

Aquí surge el concepto de Carryover...

Carryover

El Carry Over es una User Story Comprometida y No Aceptada por el Cliente en la Demo/Review al final del Sprint. En otras palabras, es la historia no finalizada y acarreada de un sprint a otro (Kell Condon, 2015).

Se pueden tomar diferentes estrategias para manejar el carruover. Por ejemplo estas son algunas:

Estrategia 1:

El carryover conlleva puntos perdidos (Kell Condon, 2015). La velocidad debe bajar porque el equipo no fue capaz de entregar trabajo "Done" aceptado. Son puntos perdidos de la velocity actual y no se suman a una próxima velocity (ya que la velocity refleja carrera real actual de sprint y no vale sumar puntos que realmente no se hicieron en la carrera). Los puntos quemados de la historia de usuario no se arrastran ni se contabilizan en el futuro. La historia de usuario pasa al backlog para ser reestimada para ser tomada en próximos sprint. Solo se reestima el trabajo restante, cuando se toma la historia en una planning, o lo que quede por hacer si se pudo recuperar algo de lo hecho.
En esta estrategia no es necesario manejar el concepto de carryover ya que no se acarrean puntos, directamente se acarrea la historia como nuevo trabajo a estimar. El trabajo gastado pero no aprobado se pierde como velocity, fue trabajo no útil para el objetivo del sprint en el que se hizo.

Estrategia 2:

El carryover genera puntos arrastrados que contabilizan para velocity futura, o sea que los puntos quemados de la historia de usuario no aprobada se arrastran y se contabilizan en el futuro (Kell Condon, 2015). La historia pasa al backlog para ser reestimada y ser tomada en próximos sprint (pero sumando los storypoints gastados, como si tuviera memoria). Solo se reestima el trabajo restante, cuando se toma la historia en una planning, o lo que quede por hacer si se pudo recuperar algo de lo hecho y se suma a lo acarreado. O sea que se reestima el SP Remanente, o sea los SP que restan para terminar esta US. Por ejemplo si se quemaron 3 SP (en sprint previo) y faltan 2 SP (de la Reestimación), la historia pesará 5 SP (Tamaño real de la US).


Referencia:

- (Kell Condon, 2015) Article, "Pick A Side: How to handle sprint carry over":

http://requirements.seilevel.com/pick-a-side-how-to-handle-sprint-carry-over