Scrum: Stories que no terminaron y sus Story Points

Estimados, una consulta bien precisa respecto a un caso que quizá es común, pero que aun no logro detectar en charlas o literatura, y por lo tanto me llena de dudas cada vez que ocurre.

Imaginemos que una Story, en un Sprint NO logra ser terminada; e imaginemos que el desarrollo se hizo parcialmente, y no se alcanzó a crear o identificar Test Cases, ni menos ejecutarlos.

Imaginemos también que el motivo por el cual no se terminó la story no fue por que ella era más compleja de lo estimado, sino que fue debido a que hubo problemas externos a la story: capacity en el equipo por falta/enfermedad de algún integrante, o por que otra story resulto ser monstruosa, etc. Es decir, la story misma no estaba mal estimada.

Entonces, esa story cae en el Backlog para ser revisada y posiblemente incluida en el próximo Sprint (para finalizarla).

Ahora bien, en el próximo Sprint, la story ¿tendrá el mismo Story Point que en el anterior? o por el contrario la regla correcta es pensar que como la Story ya se desarrolló (aun cuando parcialmente), queda menos que desarrollar, y por lo tanto (suponiendo que ninguna otra variable se haya alterado), el Story Point, debería ser menor que el considerado en el Sprint anterior ???

¿La Story tendría 2 medidas de Story Point (una por cada sprint donde participa) ?
¿Afecta esto métricas?
¿Que hacen estos casos?

Gracias por sus iluminadoras opiniones.

1 me gusta

Hola Rodrigo

Los “story points” son una manera de medir el ancho de banda que ocupa el trabajo en un Item solicitado a tu equipo.

Algunas buenas noticias

Está bien demostrado que usar “story points” no aporta valor sobre el simplemente dividir las historias en itemes que “quepan” en el largo de la iteracion/sprint y finalmente contar cuantos lograste (te recomiendo este articulo de Joshua Kerievsky Stop using Story Points.

Fijate que un item comenzado y que no se logra no genera valor.

Te recomiendo el libro “Actionable Agile Metrics”, donde se explica como

Mi socio @Manuel_Cepeda hizo una charla basada en este libro, disponible en el siguiente enlace:

¿Cuando estará listo? Métricas y forecasting con #kanban

Saludos
Agustin

1 me gusta

Manteniéndome dentro de scrum (aunque estoy completamente de acuerdo con @agustinvillena) En mi opinión, la historia debe ser re-estimada usando la técnica que normalmente usen para ello (planning poker pej). Lo importante es considerar tanto lo que ya se ha desarrollado como lo que se ha aprendido hasta el momento y usar las ceremonias de scrum ya establecidas.

1 me gusta

Creo que esto debería responder mejor tu pregunta

todo depende que tan bien este entrenado el scrum master o iteration manager gestione la sinceridad de los story points hacia el Product Owner.

Dejar cosas ocultas al SM o IM, significa que el integrante del equipo o el equipo no confía en él, sucediendo el caso… inmediatamente cambia lo. Pues no se están cumpliendo los principios de la agilidad.

2 Me gusta

Oh, tremendo tema ese de tomar crédito por un avance parcial, no había considerado ese punto de vista.

Siempre había esperado que no se contabilizara para la velocidad ni que se obtengan métricas a medias. La re-estimación que sugerí era solamente como consecuencia de que en el tiempo transcurrido se había hecho algún aprendizaje o trabajo que debía ahora ser tomado en cuenta.

Pero veo como alguien muy ensimismado en las métricas como algo manipulable podría intentar hacer algún esquema raro con las tareas medio terminadas. También puedo ver que alguien no con todo el conocimiento, o entrenamiento como dices, considere que quizás es buena idea. (spoiler: no lo es)

Gran aporte @jcalonsoh! Gracias!

1 me gusta

Muchas gracias por todas las iluminadoras opiniones.

Ahora bien, aun me queda la duda practica:

Suponiendo:

  • Estamos usando Story Point (quizá en un futuro no lo usemos más pero solo cuando hayamos entendido bien y superado la etapa de madurez supongo).
  • Una story no terminada aporta cero valor al producto, por más que todo el desarrollo ya se haya hecho y falte probarlo solamente (es decir, story no demostrada es story que no existe).
  • No hay mala intención, sino mas bien desconocimiento. Y, por lo tanto, no se le intenta ocular nada al PO, sino mas bien se le ha informado cada vez que algo no queda completamente listo.

Entonces:
¿Como se debe afrontar una story no terminada?
¿Que ocurre con lo ya desarrollado?
Si logramos prever en los primeros días del Sprint que alguna Story no podrá terminar, ¿La debemos sacar? ¿Que ocurre con las holguras de tiempo que algunos desarrolladores experimentarán al sacar la Story? (recordar que los casos en que se ha dado es principalmente no tenemos capacity de testing) ¿será que nos faltan mas testers?.

He escuchado de casos en que el código es reversado, es decir quitado del ambiente de pruebas, de modo de dejar limpio el ambiente con solo lo que ya se ha probado y demostrado.

Nosotros no lo hacemos así, puesto que es fijo que esa story no terminada, entra en el siguiente Sprint, y por lo tanto el sacar el código para volver a ponerlo, es un retrabajo desde nuestra perspectiva.

Esta interesante el tema, y desde ya estoy dispuesto a recibir todos los ‘alcachofasos’ respectivos, si la respuesta está en la teoría y me falta estudiar mas.

Gracias nuevamente.

Respuestas en mi opinión:

Técnicamente, se debiera considerar el sprint como fallido al no cumplir con lo comprometido, pero ahi no entiendo mucho de las consecuencias ni de la ceremonia que corresponde.

Va a depender, en parte de las herramientas que uses y en parte de las definiciones para tu proyecto. por ejemplo, ¿cada sprint pasa a producción una vez aprobado? ¿usas feature toggles? ¿usas gitflow o feature branches? etc. cada caso te abre unas puertas y te cierra otras.

Sacar la historia me parece contraproducente. De alguna forma tiene que quedar registro (evidencia) de que una historia falló en el sprint, ya sea en simple estadística (historias falladas por sprint) o como parte de una ceremonia (alguna reunión o documento). Para eso, la historia quizás deba ser marcada como abandonada o fallada, en vez de ser sacada, ya que de la misma forma que nadie puede poner historias una vez iniciado el sprint, nadie debiera sacarlas tampoco.

Obviamente testing es un cuello de botella para ti (y para la mayoría de nosotros!). eso significa que debes hacer un análisis de capacidad y para eso es mejor kanban y un sistema de fujo que un storyboard y un sistema de timebox.

Pero dicho esto, si haces que los story points de historias falladas/abandonadas afecten tu velocidad, el promedio de tu velocidad va a bajar de acorde (leer el comentario de @agustinvillena nuevamente!) y va a forzar que tus devs se comprometan a menos, lo que debiera llevar a un equilibrio.

Bueno, por ejemplo, puedes reducir o reasignar a tus devs, conseguir más capacidad testing ya sea aumentando la cantidad de ellos o quizás invertir tiempo en desarrollo de automatización que facilite la tarea de los testers. En realidad eso va a depender de tu contexto y lo que consideren más efectivo.

Entiendo y comparto tu observación, especialmente en tu contexto (falta solo testing y fixes) pero también es cierto que el retrabajo no es completo desperdicio. El código que ha sido escrito y se elimina para re-hacerse, especialmente cuando tienes fresco en la mente lo que se hizo y cómo (viniendo del sprint anterior por ejemplo) te da la oportunidad de iniciar de cero, ahora con más experiencia y una mirada de cómo podría quedar. Va a tomar tiempo volver a hacerlo, probablemente el mismo que tomó hacerlo en el inicio, pero esta vez estará mejor hecho.
Es un concepto algo avanzado para programadores de entender (contra-intuitivo, como mucho en agilidad), en general la idea/iniciativa del retrabajo debiera venir de ellos (como todos lo que corresponde a su área de responsabilidad, es decir, métodos y herramientas)

1 me gusta

Guau,

Entiendo y agradezco el feedback.

Solo que debo reconocer que el primer comentario me dejó helado:

¿Como se debe afrontar una story no terminada?
Técnicamente, se debiera considerar el sprint como fallido al no cumplir con lo comprometido, pero ahi no entiendo mucho de las consecuencias ni de la ceremonia que corresponde.

Pero bueno, todo apunta a que no hayan estos casos y que todo lo que se comprometa se cumpla.

Gracias.