Según Ken Schwaber, “El plan mínimo necesario para iniciar un proyecto Scrum consiste en una visión y un Product Backlog. La visión describe por qué se lleva a cabo el proyecto y cuál es el estado final deseado”.
También se supone que el propietario del producto debe colaborar estrechamente con el equipo para crear esta visión del producto. Esto es deseable porque al haber participado en este proceso, el equipo tendrá una comprensión más profunda de la visión.
Dado esto, en nuestra gran organización se necesita tiempo y varias reuniones con las partes interesadas para lograr un consenso sobre la visión y la dirección del producto. Entonces, ¿está bien tener un Sprint 0 sin código de entrega?
Creo que su problema es tratar de calzar un proceso que viene antes del inicio de sus sprints, en un sprint inicial. Su situación plantea dos preguntas, en mi opinión.
1. ¿Es la metodología Scrum tener un sprint sin un entregable que se pueda enviar?
Normalmente no.
Scrum tiene la intención de evitar la planificación detallada por adelantado y el concepto de hacer las cosas, "hechas", es un inquilino clave. Si bien puede ser creativo cuando define, "hecho", en última instancia, el concepto de "sprint 0" no es parte de la filosofía de Scrum, ni es un plan que no ofrece una característica que se puede enviar.
2. ¿Puedo adaptar Scrum para que se ajuste a mis necesidades?
Claro, pero no sería Scrum.
Dicho esto, no hay ninguna razón por la que no pueda implementar Scrum puramente, si ese es su objetivo, en la situación que ha descrito. Si bien la cita que das de Ken Schwaber es cierta, "El plan mínimo necesario para iniciar un proyecto Scrum consiste en una visión y un Product Backlog", eso no excluye la posibilidad de que en tu organización se requiera más que eso.
Esta planificación adicional antes de que comience una serie de sprints no necesita definirse como "sprint 0". Si su ecosistema de desarrollo requiere la planificación de proyectos debido a una política interna, entonces es perfectamente legítimo llamar a las cosas por su nombre; refiérase a esto como un proceso distinto fuera de su implementación de la metodología Scrum.
¿Está bien tener un Sprint 0 sin código de entrega?
Manteniéndose fiel al marco Scrum, la respuesta sería NO.
¿Puedes cronometrar el Sprint 0? Si la respuesta es no, entonces estaría violando dos factores importantes del marco Scrum, el primer time-boxing y el segundo código potencialmente entregable al final de cada sprint. Como ha mencionado, la organización necesita tiempo y varias reuniones con las partes interesadas para llegar a un consenso sobre la visión y la dirección del producto, por lo que cronometrar este ejercicio podría ser una esperanza contra toda esperanza.
Es por eso que Mike Cohn llama a esta parte un proyecto antes del proyecto :
Durante este proyecto antes del proyecto, los primeros miembros del equipo (quizás solo un futuro propietario del producto) pueden trabajar para crear una cartera de productos inicial, encontrar o contratar miembros del equipo, configurar el entorno técnico, etc.
Uno de los mayores problemas de tener un sprint cero es que establece un precedente de que hay ciertos sprints o tipos de sprint que tienen reglas únicas.
Incluso el concepto de Sprint Zero es discutible entre los padres fundadores de Agile, como afirmó Alistair Cockburn :
Tengo la vaga sensación de que alguien fue presionado por su uso de Scrum cuando hizo algo que no tenía un valor comercial obvio al principio, e inventó "¡Oh, eso fue Sprint Zero!" para alejar a los campesinos con los picos de su peldaño.
... y luego otros pensaron que era una gran respuesta y comenzaron a decirla también. ... y luego se convirtió en parte de la cultura.
y en palabras de Ken Schwaber :
Exactamente... el sprint 0 se ha convertido en una frase mal utilizada para describir la planificación que ocurre antes del primer sprint... y dado que la planificación crea artefactos que a menudo cambian, debe minimizarse antes del primer sprint y luego ocurrir cada sprint en la reunión de revisión de sprint/planificación de sprint (planificación justo a tiempo)
A menudo hay debates entre los practicantes de Scrum sobre si tener un Sprint Zero o no. Puede eludir los diversos argumentos redefiniendo cuál será el Sprint Goal para el primer Sprint y ajustando las expectativas de lo que se demostrará en la Revisión del Sprint.
A veces, el impulso de tener un "Sprint Zero" parece una necesidad de tener una cadena de herramientas o un sprint arquitectónico sin un resultado concreto. Sin embargo, si profundizas más, el verdadero objetivo suele ser evitar contar el primer sprint en la velocidad de tu equipo. Sin embargo, todo el trabajo relacionado con el proyecto debe llevarse a cabo en el Product Backlog como un costo visible para el proyecto, así que no llene su primer sprint con trabajo invisible.
La respuesta técnicamente correcta dentro del marco es garantizar que la arquitectura, la cadena de herramientas y otras historias de infraestructura necesarias se incluyan en la cartera de productos. Por ejemplo, el Sprint Goal del primer sprint podría ser algo como:
Instale la infraestructura de desarrollo necesaria para poner en marcha el proyecto.
Es posible que incluso necesite varios sprints de este tipo al comienzo de un proyecto; eso está bien, también. Las historias de usuario aceptadas en esos sprints iniciales se seleccionarían para cumplir con los Sprint Goals definidos.
Una interpretación literal del proceso de Sprint Review parece hacer que las historias que no son de fondo sean un no-no. Sin embargo, esto no es realmente así. El objetivo del proceso es hacer que el progreso (o la falta de él) sea visible para las partes interesadas y proporcionar un punto de inflexión dentro del proyecto para recopilar comentarios de las partes interesadas. Esto generalmente funciona mejor con características tangibles o accesibles para el usuario, pero cualquier cosa que pueda demostrar de una manera visual o atractiva será suficiente.
Por ejemplo, la primera Revisión del Sprint de su equipo sin duda podría demostrar entregas orientadas al desarrollador, tales como:
Depende del equipo, incluidos el propietario del producto y el Scrum Master, educar a las partes interesadas sobre la necesidad de estos requisitos previos del proyecto. Barrer estos entregables debajo de la alfombra a través del mecanismo "Sprint Zero" es una forma de eludir la necesidad de educar a la organización, pero en última instancia engaña a las partes interesadas y al equipo de los beneficios completos de un proceso transparente.
¡ Tenga en cuenta que Scrum habla de incrementos potencialmente entregables (PSI) en lugar de código potencialmente entregable ! Por supuesto, puede enviar código, pero también puede enviar otras cosas. Por ejemplo, un documento de visión de producto podría ser un incremento que se puede enviar. Los sprints con el objetivo de obtener información a menudo se denominan Sprints de exploración. No son inusuales.
En general, la idea del incremento entregable es hacer que defina un objetivo claro para su iteración. Esa es la única manera de hacer que su progreso sea medible. No puede medir su progreso en la tarea "comprender el dominio del problema", pero puede medir el progreso en la creación de un documento que contenga la visión del producto. Porque en este último caso puedes discutir el resultado y averiguar si es aceptable o no.