Bajo Scrum, tenemos una historia que se estimó bastante corta. Una vez que un desarrollador recogió la historia, resultó que se requiere una cantidad significativa de preparación técnica, y esto se está arrastrando enormemente.
La empresa acordó que el trabajo de preparación se puede dejar como está una vez que lleguemos al final del sprint, para que el desarrollador pueda continuar con otro trabajo (más importante), lo que significa que la historia no se puede hacer. Este es un acuerdo explícito con la empresa de que la historia actual se recogerá más tarde (después de que haya pasado una fecha límite en particular).
¿Deberíamos mover esta historia problemática a Listo, marcarla como cancelada y luego resucitarla en un sprint posterior o simplemente deberíamos marcarla como bloqueada y dejarla donde está hasta que algún (posiblemente mucho) sprint posterior tenga la capacidad de retomarla?
Una tercera opción es que dividamos la historia en dos: una para el trabajo de preparación y otra para el trabajo real. Pero con eso queda la pregunta: ¿Qué se debe hacer con la historia real, dadas las pautas ágiles?
Evalúa el impacto en el Sprint Goal y luego permite que el Product Owner cumpla su función en consecuencia.
[L]a historia no se puede hacer... ¿Deberíamos mover esta historia problemática a Listo, marcarla como cancelada y luego resucitarla en un sprint posterior[,] o deberíamos simplemente marcarla como bloqueada y dejarla donde está hasta algún ( posiblemente mucho) más tarde sprint tiene capacidad para recogerlo?
Ninguna de las anteriores. No puede tratar una historia incompleta o una característica que no se puede enviar como "terminada". El trabajo tampoco puede transferirse automáticamente de Sprint a Sprint sin violar los principios básicos del marco.
Una pregunta más importante, sin respuesta en la publicación original, es si esta historia es esencial o no para alcanzar el Sprint Goal actual. Si es así, y si no se puede completar dentro del Sprint actual, entonces el propietario del producto debe decidir si trabaja con el equipo para volver a definir el objetivo o declarar una finalización anticipada del Sprint y regresar a la planificación del Sprint.
Independientemente de si el Sprint finaliza antes de tiempo o no, el trabajo inacabado "no se hace" y se devuelve a la Lista de Producto al final del Sprint. El propietario del producto puede decidir si volver a priorizar el trabajo para un Sprint futuro, eliminar la prioridad, descartarlo por completo o refactorizar/editar/descomponer la historia de la forma que considere adecuada.
No conozco ninguna guía ágil oficial sobre esto. Sin embargo, hay algunas cosas que la práctica común dictaría:
1) Parece que su equipo y su negocio tuvieron exactamente la conversación correcta sobre qué hacer cuando descubrieron que era mucho más grande. ¡Gran trabajo!
2) La historia se inició y dejaste de trabajar en ella. No lo movería a listo, sino que lo volvería a colocar en la cartera de pedidos para que lo retome más tarde. En realidad, no suena como si estuviera bloqueado, solo que lo ha quitado de prioridad, por lo que el PO debe moverlo donde crea que va con prioridad. Esta es una de las pocas excepciones en las que realmente recomendaría cambiar el tamaño de la historia para representar el nuevo tamaño, solo porque en realidad impulsará las decisiones más adelante.
3) Limpieza: si el equipo trabajó un poco en la historia, es posible que no quieran dejar el código a medio terminar dando vueltas. Ya sea que la forma correcta de limpiar sea retroceder o simplemente ordenar el código para que pueda recuperarse fácilmente más tarde sin causar problemas, su equipo tendrá que decidir, pero cree un espacio para ello.
Scrum define tres roles. Cuando se trata del trabajo en el Sprint, el Equipo de Desarrollo lo pronostica y lo alinea con un Objetivo de Sprint determinado por el Equipo Scrum.
Si el trabajo resulta ser diferente de lo que esperaba el equipo de desarrollo, colaboran con el propietario del producto para negociar el alcance del Sprint Backlog dentro del Sprint.
La forma en que el Equipo Scrum gestiona ese trabajo depende de ellos, ya que se mantienen transparentes sobre el esfuerzo, los problemas y los resultados. ¿El equipo está tratando de comerse al elefante de una vez en lugar de en pequeños bocados? ¿Se puede dividir el artículo en unidades funcionales más pequeñas? ¿Se necesitan múltiples picos de aprendizaje (investigación, prototipo, prueba de concepto o experimentos seguros para fallar) para determinar el mejor enfoque?
¿Qué son las "directrices ágiles" y cómo cree que son aplicables? (Consulte la definición de ágil ).