¿Cuenta esto como una historia de usuario para un juego básico de Sudoku?

Estoy tratando de hacer una historia de usuario para un juego básico de Sudoku, utilizando el enfoque de desarrollo de software ágil.

Entiendo el concepto detrás de las historias de los usuarios, pero me preguntaba si era posible obtener un ejemplo para profundizar mi comprensión.

Diría

• Como un ávido jugador de Sudoku, quiero tener múltiples niveles en diferentes dificultades.
• Como jugador nuevo, quiero un nivel de introducción al juego que me enseñe lo básico.

contar como una historia de usuario?

Sus ejemplos pueden contar como historias de usuario, pero les falta una parte muy importante: el objetivo que el usuario desea alcanzar cuando se implementa la historia.
Este objetivo puede ser obvio para usted, pero debe escribirlo de todos modos.

Una historia de usuario tiene el formato

As a <user>
I want <feature>
So that <goal>

La parte del objetivo es importante, porque ayuda a los desarrolladores a tomar las decisiones correctas.

Su segundo ejemplo podría tener dos objetivos muy diferentes, que conducirían a diseños diferentes.

• Como jugador nuevo, desearía un nivel de introducción al juego para enseñarme los conceptos básicos, de modo que pueda resolver el juego y tener una sensación de logro.
• Como jugador nuevo, me gustaría tener un nivel de introducción al juego que me enseñe los conceptos básicos, para que pueda aprender las reglas del juego.

En el primer caso, solo tener un nivel fácil sería suficiente, pero en el segundo caso desea guiar al usuario por qué un cierto número debe / no debe colocarse en una celda en particular.

Además del buen punto que Bart mencionó sobre el objetivo, me gustaría centrarme en la parte "ágil". Aunque lo que tienes son historias de usuarios, están muy por encima del lado "épico" del espectro y aún no son útiles para el desarrollo.

Tal como lo veo, generalmente comenzaría con historias como las anteriores cuando planifica inicialmente un nuevo producto o característica, para tener una buena idea de lo que desea construir, y luego comenzaría a romper este tipo de "épica "historias a fragmentos cada vez más pequeños hasta que tenga un conjunto de historias que sea directamente accionable para el desarrollo. En particular, cuando practique el desarrollo impulsado por pruebas (TDD), le gustaría llegar a un nivel de granularidad tal que cada historia de usuario sea naturalmente traducible a solo unos pocos casos de prueba (aunque cada uno podría ser complejo).

Ejemplos de tales historias más accionables podrían ser:

• Como jugador, quiero pedirle al juego que genere un tablero de Sudoku solucionable para mí, de modo que pueda comenzar a planificar mi enfoque.
• Como jugador, quiero poder completar valores en la celda, usando mi mouse y que el juego indique si el valor invalida el tablero, para poder probar rápidamente las posibles opciones y retroceder si es necesario.

Recomendaría la siguiente publicación excelente de Alex Cowan para obtener más información sobre esto: Su mejor historia de usuario ágil .