# User Story
Es utilizado para describir una funcionalidad del sistema desde el punto de vista el usuario. Esto esta directamente relacionado con la relevacion de requerimientos.

Son cortas y no tienen un lenguaje tecnico. Utiliza tanto comunicacion oral como escrita, estas por medio de conversaciones directas con el desarrollador y los papeles del panel.

## Que tiene
- Descipcion.
- Criterio de evaluacion.
- Valor -> Maximisa la satisfaccion del cliente.
- Ficha estructural.
- Como (rol) quiere objetivo -> para beneficio.
### Lo más clave es
1. Descipcion.
2. Pruebas / Criterios Aceptacion.

## 3 C
### Cartas
Como las propias de trello o jira. Condensan de forma directa el contenido de la conversacion con lo que se debe hacer.

### Conversacion
En esta lo que sucede es que el desarrollador y el manager hablan con el stakeholder. Este ida y vuelta es crucial para llenar los detalles y que el equipo entienda el trabajo a realizarse.

Esto no es una cosa de una vez sino que es un proceso que se mantiene sobre el tiempo para mantener el equipo alineado en el desarrollo.

### Confirmacion
Es el paso final, consiste en validar el desarrollo usando un criterio claro. y confirmando que el software cumpla con laos estadares acordados.

## Dependencias
Las historias de usuario tienen que ser independientes una de otra.

## Bocetos
Crear mocks de las pantallassd que va a ver el usario, una forma adicional de capturar condiciones de satisfaccion de las historias de usuario.

## Invest
### Independiente
las dependencia entrre las historias crean problema de priorizacion
### Negociable
Se debe de definir entre el desarrollador y el usuario
### Valuable
tiene que aportar valor al usuario
### Estimable
tiene que poderse estimar facilmente
### Small
Tiene que entrar en una sola iteracion
### Testeable
Tiene que ser testeable

## Story points
## Story points
Estos son puntos los cuales permiten evaluar cada US de forma independiente de las horas que un equipo le tendria que dedicar. Y se calculan usando la escala de fibonnacci.