¿Es la documentación una historia de usuario? [cerrado]

Necesitamos hacer alguna documentación del usuario para un producto en el que hemos estado trabajando durante los últimos sprints. Ahora estamos comenzando un nuevo proyecto en el próximo sprint y el PO está haciendo que la documentación del producto producido previamente sea una historia de usuario para este sprint.

Me pregunto su opinión sobre este enfoque. Personalmente, no estoy de acuerdo con que la documentación sea una Historia de usuario dentro de Scrum porque no produce ningún código.

EDITAR: Gracias por sus opiniones chicos. Tenía en mi cabeza que un sprint consistía en implementar un incremento de software de trabajo, pero sus puntos de vista han cambiado mi perspectiva. Gracias por todas tus respuestas.

"Como usuario de X, necesito saber cómo funciona X" me parece una historia de usuario legítima. Esto podría resultar en documentación escrita o ayuda en línea.

El punto no es solo código, sino que cumple con los requisitos de los usuarios.

Idealmente, la documentación es parte de cada historia de usuario y nunca se acumula. Pero, en el mundo real, eso a menudo no sucede. En ese caso, debe crear una historia de usuario para ponerse al día con una pieza de documentación faltante específica.

Tienes razón, no produce ningún código. Pero sí satisface un requisito del usuario y debe priorizarse frente a otros requisitos del usuario.

Si esto significa que nunca se hace, porque esta y esa funcionalidad se está trabajando, entonces probablemente no necesitó tanto la documentación.

Estoy de acuerdo con la evaluación de la documentación de pdr si se trata de requisitos, documentación técnica o del proyecto. Idealmente, debería incorporarse al trabajo de sprint.

Creo que la documentación del producto es muy diferente, ya que es un producto real solicitado por el usuario y proporciona valor directamente al usuario. Esto debe entenderse, por supuesto, que la documentación del producto no es esencialmente una tarea técnica, sino una tarea funcional, y puede o no ser una actividad adecuada para un recurso técnico en el proyecto.

Creo que debería ser una historia de usuario, sin embargo, creo que se debe asignar a estas tareas un recurso de proyecto que tenga una comprensión firme de los requisitos comerciales, la perspectiva del usuario y buenas habilidades de escritura técnica. Idealmente, este sería un analista de negocios si hay uno disponible, o tal vez un probador de control de calidad de orden superior con una comprensión firme de los requisitos, historias de usuarios y buenas habilidades técnicas de escritura. Esto también podría ser un desarrollador, sin embargo, la documentación del producto escrita por los desarrolladores tiende a no ser tan de alta calidad o tan útil porque los desarrolladores generalmente están demasiado cerca de los detalles técnicos.

En nuestra organización, el equipo de herramientas, a cargo de mantener y mejorar nuestro sistema de integración continua, está utilizando Scrum para ayudarlos a administrar su trabajo. No están escribiendo código, pero están practicando Scrum de todos modos.

Para responder específicamente a su pregunta, le preguntaría si el equipo considera que la documentación es parte de la "Definición de hecho" o no.

Si el equipo considera que la documentación es parte de la "definición de hecho", entonces no hay necesidad de una historia adicional y la historia no puede aceptarse a menos que la documentación esté escrita y validada.

Si el equipo considera que la documentación no es parte de la "definición de hecho", crearía una historia separada para que el propietario del producto pueda administrar su trabajo.