Me resulta más conveniente describir los requisitos en términos técnicos. Entonces, ¿es posible no usar las historias de usuarios en Scrum? ¿Seguirá siendo Agile?
¡Claro que puedes! Scrum no prescribe qué representación concreta de los requisitos debe usar. No existe el término "historia de usuario" en la Guía Scrum . La Guía Scrum opera " Elemento de la cartera de productos " en su lugar.
Scrum Guide impone tres restricciones a una PBI bien definida (o "refinada" en la terminología de Scrum):
Entonces, en teoría, PBI puede ser cualquier tipo de representación de requisitos.
Razón principal por la que se utiliza User Story: está más orientado al cliente .
Pero si usted es propietario del producto y no tiene problemas de comunicación con las partes interesadas, puede sentirse libre de operar con el tipo de representación de requisitos que desee.
Finalmente, cita de Scrum Primer :
Los elementos de la cartera de productos se articulan de cualquier manera que sea clara y sostenible. Contrariamente al malentendido popular, el Product Backlog no contiene "historias de usuarios"; simplemente contiene elementos. Esos elementos se pueden expresar como historias de usuarios, casos de uso o cualquier otro enfoque de requisitos que el grupo encuentre útil. Pero sea cual sea el enfoque, la mayoría de los artículos deben centrarse en ofrecer valor a los clientes.
Por lo tanto, si está bien para las partes interesadas, no hay problema, incluso si aplica los requisitos del "estilo SRS" (como las frases "el sistema debe...").
Tener una historia de usuario es un poco fundamental para formar un equipo Scrum. Técnicamente diría que no estás "haciendo scrum". Sin embargo, aún puede ser ágil si funciona para su equipo y su cliente...
La decisión de usar o no las historias de usuario no debe basarse en la conveniencia para usted, debe basarse en lo que el equipo necesita para tener éxito y lo que debe hacerse para que el cliente obtenga un incremento de producto de calidad al final del iteración.
Si el equipo puede pensar lo suficientemente fuera de la caja (y comprender el valor comercial del elemento de trabajo que documenta) para solucionar y crear algo para un cliente en una iteración sin una historia de usuario formal... entonces hágalo. Si está escribiendo detalles de implementación para su equipo y se sienten como "monos de código", entonces está frustrando el propósito de usar Scrum y capacitar al equipo para brindar valor incremental a un cliente.
Técnicamente no, de acuerdo con el principio del manifiesto Agile 1 ["Nuestra máxima prioridad es satisfacer al cliente a través de la entrega temprana y continua de software valioso ".] [1], porque los requisitos técnicos explican solo los detalles de implementación, implementación, mantenimiento y no el valor comercial que aportan al producto.
De acuerdo con lo que está hablando, solo se necesitan requisitos técnicos, es una tarea particular que se explica por sí misma, o estos requisitos no son puramente técnicos y aún contienen la explicación de un propósito al que sirven, es decir , el valor comercial . Debido a que el valor comercial se trata de la ganancia que el Usuario obtiene al usar este Producto y esta Función en lugar de cualquier otra cosa (por ejemplo, el Usuario puede ahorrar/ganar dinero, adorar la interfaz de usuario u obtener un conjunto de funciones que cubre sus necesidades primordiales, cuando ninguna otra aplicación puede hacerlo, etc.).
Interesante pregunta. Es una pena que no lo haya visto antes; me hace recordar que el valor comercial es una combinación funcional y técnica, mientras que la división de requisitos funcionales frente a requisitos técnicos se inventó solo por conveniencia y simplicidad.
Ewan
Stanislav Bashkirtsev