Estimación en Scrum

¿Qué es estimar en el contexto de Scrum?

• Hacer un cálculo exacto del tiempo necesario para completar una tarea.

• Hacer un cálculo aproximado del esfuerzo necesario para completar una historia de usuario.

• Dividir una tarea en partes iguales para reducir su complejidad.

• Definir los requisitos exactos de una funcionalidad.

¿Qué información es útil para hacer una estimación en Scrum?

• Las mejores suposiciones disponibles.

• Experiencias pasadas y documentación de proyectos similares.

• La velocidad del equipo y la complejidad de las funcionalidades solicitadas.

• Todas las anteriores.

¿Por qué en proyectos ágiles no se estima en días como en el modelo cascada?

• Porque las tareas en Scrum son más cortas.

• Porque el ciclo de desarrollo en agilidad depende de sprints, no del tiempo total del proyecto.

• Porque no se puede estimar con precisión en agilidad.

• Porque no hay requisitos claros en agilidad.

¿Qué técnica de estimación se basa en clasificar las historias de usuario en XS, S, M, L, y XL?

• BUS

• Secuencia de Fibonacci

• Tallas de poleras (T-Shirt Size)

• Kanban

En la técnica BUS, ¿qué significa que una historia sea clasificada como "Big"?

• Que es una historia fácil de completar en un sprint.

• Que la historia debe ser dividida en varias partes, ya que es muy grande para un sprint.

• Que la historia es incierta y necesita refinamiento.

• Que es la historia más importante del proyecto.

¿Qué técnica de estimación utiliza una escala numérica para asignar puntos de historia?

• T-Shirt Size

• BUS

• Secuencia de Fibonacci

• Estimación por consenso

Si una historia es demasiado grande para un sprint, ¿qué se recomienda hacer?

• Esperar hasta el próximo sprint para completarla.

• Dividir la historia en partes más pequeñas que generen valor incremental.

• Reducir la complejidad de la historia sin modificarla.

• Dejar la historia fuera del backlog.

¿Cuál de las siguientes es una técnica para dividir historias de usuario grandes?

• Definir flujos de trabajo implícitos.

• Utilizar la regla del 80/20.

• Asignar más desarrolladores a la historia.

• Ignorar las historias grandes hasta el final del proyecto.