jueves, 15 de diciembre de 2022

Definition of Ready

DEFINITION OF READY 

Es un checklist que se necesita para que los equipos decidan tomar tal o cual historia del backlog.

Es lo que el equipo define como informacion minima necesaria para tomar la historia.

Cada equipo define su Definition of Ready, no todos los equipos necesitan la misma cantidad y calidad de informacion para aplicar a una historia.

Checklist de un caso de Ejemplo para un Definition of Ready

  • Incluir Descripcion Breve y Clara📌
  • Incluir Dependencias.📌
  • Incluir Mockup para UI📌
  • Incluir Casos de Prueba y/o Criterios de Aceptacion.📌


Diferencia entre Definition of Done y criterios de aceptacion 

Es un criterio de aceptacion pero aplicada a todas las historias a diferencia de los criterios de aceptacion que aplica a una sola Historia.

El definition of Done : Son estandares generales que se aplican a todas las historias y se definen por los equipos.

Ejemplo para un  Definition of Done

  1. La Historia debe ser autorizada por el Product Owner.
  2. La historia tiene su Definition of Ready.
  3. QA dio el ok a sus criterios de aceptacion.
  4. El Manual de Usuario asociado si existe fue actualizado si la historia añade funcionalidad o cambia interface o comportamientos.
  5. El stake holder a traves de una demo del release por liberarse dio su conformidad.

 Proceso de Elaboracion de la User Story

Paso 1 de La historia

  • Como User Persona
  • Quiero
  • Para

Paso 2 de la historia Refinar la Historia del paso 1 a traves de la conversacion y la cofirmacion

https://www.youtube.com/@kott



Recomendacion

Cada historia deberia tener la definition of ready incluida de preferencia deberia usarse un template de la historia tipo plugin de jira para chrome,etc.

https://www.youtube.com/@kott


Debe cumplir a UINVEST

U: Delimitado a la experiencia que el usuario espera de la historia.
N: Negociable se puede negociar el alcance de la historia.
V: Valor para el usuario (negocio).
E: Estimable en el tiempo. 
S: Historia de tamaño pequeño no mas de dos o tres dias recomendable maximo medio sprint.
T: Testeable debe poderse probar, debe saberse si cumple con la expectativa del usuario.
I: Independiente de otras historias de backlog.


Formato Recomendado para las Historias

  • Descripcion Clara
  • Bussiness Value
  • Acceptance Criteria(Criterios de Aceptacion)
  • Dependencias Identificadas
  • El product Owner aprobo la historia
  • La historia no debe tomar mas de 2 o 3 dias
  • La estimacion la debe hacer el equipo de desarrollo
  • Card Conversation Confirmation


La definition of ready no se debe usar como excusa para no añadirse una historia de valor y prioritaria para el negocio.



No hay comentarios:

Publicar un comentario

La era del big data y open data en la administración pública

  Dos Opciones de Resumen del documento  Opcion A El artículo "Big Data: una herramienta para la administración pública" explica c...