Plantillas/Templates para utilizar en tareas, funcionalidades o historias de usuario en Jira u otra herramienta de gestión

Hola por ahí,

Pues acá hacía tiempo no escribía porque apenas me estaba acostumbrando a mi nuevo empleo. Estoy trabajando como Scrum Master para una empresa de desarrollo de software, así que posiblemente empiece a surgir mucho de que escribir a partir de ahora. En nuestra empresa utilizamos Jira, pero la plantilla puede ser utilizada en cualquier otro software en el campo de Descripción del ticket.

Se me ocurrió que puede ser interesante platicarle sobre algo que tuvimos que resolver en nuestros equipos de Scrum que usan Jira como herramienta de gestión. Ya saben que yo soy fan de tener las funcionalidades o requisitos del software documentados utilizando una plantilla detallada aunque esta documentación se vaya enriqueciendo en cada sprint o iteración, pero la realidad es que no todos los proyectos tienen esto desde el principio por lo que nos toca improvisar sobre la marcha.

Un problema que suele presentarse es que las Issues o Tickets vienen de distintas fuentes y personas, incluso a veces de un sistema de Help Desk (si quieres conocer algunos de estos sistemas puedes leerte este artículo en internet). Entonces, ¿como el Equipo de Desarrollo y el Product Owner pueden refinar estas incidencias cuando vienen con poca información?, pues en mi caso demorábamos mucho en nuestros Backlog Refinements debido a la poca información y teníamos que estar dejando comentarios y más comentarios de aquí para allá y de allá para acá hasta tener claridad de lo que se quería, en el mejor de los casos. En el peor caso se empezaba a trabajar en issues por la urgencia donde no estaban claros lo criterios de aceptación.

Es por eso que como Scrum master propuse esta plantilla, que fue revisada y validada por todos en el equipo. Tenemos dos tipos de plantilla, una para bugs o errores y otra para historias, funcionalidades y tareas. En el siguiente post explicaremos la plantilla para bugs y errores.

Plantilla de descripción de tickets de tipo Story o Task en herramientas de gestión (Ej: Jira)

____________________________________

Propósito
____________________________________

Primero, debes definir quién hace la solicitud y qué hace. Este formato de declaración impone la perspectiva del usuario sobre el requisito.

Como el usuario, Quiero realizar una acción, Entonces puedo lograr algo importante para mí

Por ejemplo:

Como contador de mi iglesia, quiero iniciar sesión en mi cuenta, entonces puedo ver las transacciones del último mes

La última parte (Entonces/Pero) es la parte más importante. También es lo más difícil. Concéntrate en el problema que el usuario está tratando de resolver.

___________________________________

Dependencias de otros requisitos y funcionalidades afectadas
___________________________________

• Las funciones / problemas relacionados que el desarrollador debe tener en cuenta o pueden verse afectados.
• Para el control de calidad es muy importante saber esto, por lo que deben ejecutar alguna prueba de integración basados en lo que aquí se escriba

___________________________________

Reglas de negocio
___________________________________

• Enlace a la documentación del negocio o explique aquí cualquier regla de negocio que deba cumplirse al implementar la historia/tarea/funcionalidad

___________________________________

Criterios de Aceptación - Funcional
___________________________________

• ¿Cuáles son las condiciones requeridas para realizar la funcionalidad?
• ¿Qué acciones toma el usuario para usarlo?
• ¿Cuáles son los resultados observables de la acción?

Una vez has definido la funcionalidad a un alto nivel en  la sección del propósito, tienes que definir en detalle cada uno de los escenarios que deben ser cubiertos para cumplir el requisito

Una posible sintaxis puede ser:

Escenario 1: Nombre o resumen del escenario
Dado una serie de pre-condiciones
Cuando un grupo de acciones son realizadas
Entonces una respuesta del sistema o resultado específico se hace visible 

Cualquiera de estas 3 sentencias puede ser extendida con Y o PERO. Ejemplo:

Dado pre-condición uno Y pre-condición dos PERO no existe la pre-condición tres
Cuando el usuario x realiza la acción uno Y luego la acción 2
Entonces una respuesta del sistema o resultado específico se hace visible PERO otro resultado

Todos los flujos conocidos (positivos o negativos) deben estar representados por un escenario.  Esta sección es de suma importancia para los desarrolladores (programadores, testers, etc.), para conocer todos los casos que deben ser cubiertos y probados.

Los escenarios deben ser escritos en tercera persona. 

Con frecuencia al Dado es el mismo para varios o todos los escenarios. Para ese caso utilizamos el Background. Por ejemplo:

Background

Dado que el usuario está en la página de inicio de sesión

   Y el usuario no ha iniciado sesión

Escenario 2: Inicio de sesión: la dirección de correo electrónico no está en el sistema

Cuando el usuario ingresa una dirección de correo electrónico que no está en el sistema

   Y el usuario ingresa una contraseña

   Y el usuario envía el formulario

Entonces aparece un mensaje de error, "Credenciales no válidas. ¿Olvidó su contraseña?"

   Y olvida tus enlaces de contraseña a la página de contraseña olvidada

Escenario 3: Inicio de sesión: contraseña no válida

Cuando el usuario ingresa una dirección de correo electrónico en el sistema

   Y el usuario ingresa una contraseña incorrecta

  Y el usuario envía el formulario

Entonces aparece un mensaje de error, "Credenciales no válidas. ¿Olvidó su contraseña?"

   Y olvida tus enlaces de contraseña a la página de contraseña olvidada

Escenario 4: Inicio de sesión: información faltante

Cuando el usuario no completa un correo electrónico

   Y el usuario ingresa una contraseña

  Y el usuario envía el formulario

Entonces aparece un mensaje de error, "Se requiere dirección de correo electrónico".

___________________________________

Criterios de Aceptación - No Funcional
___________________________________

• Reliability
• Performance efficiency
• Security
• Usability
• UX requirements

Puedes utilizar la misma técnica de escenarios de arriba o simplemente numerar los requisitos no funcionales que deben ser cubiertos.

___________________________________

Imágenes y Videos
___________________________________

Aquí puedes agregar imágenes y videos que apoyen la especificación. De preferencia referéncialos en cada una de las secciones anteriores.

___________________________________

Notas e información extra
___________________________________

Cualquier otra información no cubierta en las secciones anteriores y que creas puede ayudar al equipo en la implementación del ticket.

De momento eso es todo, agradecería un comentario, si alguien quiere enriquecer la plantilla o la empieza a aplicar también es bienvenido a comentar. Esperen en estos días un post para la plantilla de Bugs y Errores.

Graciassssssss