Scrum Poker sin complicaciones. Y con algún emoji volando.
Crea una sala, comparte el enlace y empieza a estimar con tu equipo. Sin registro, sin suscripciones y con un toque divertido.
El propósito del proyecto
StoryFlop nace de una idea sencilla: poder hacer Scrum Poker sin encontrarse con suscripciones, pagos por asiento o límites de participantes y votaciones impuestos por la herramienta. El propósito es que cualquier equipo pueda centrarse en conversar y estimar, de forma ágil y sin complicaciones.
Prepara las historias, invita al equipo por enlace y revela las cartas cuando todos hayan votado. Y cuando la sesión necesite un poco de energía, lanza un emoji a un compañero: estimar también puede ser divertido.
Las salas son temporales: sus datos asociados se eliminan tras 14 días de inactividad. Conserva las decisiones importantes en vuestro backlog y consulta la política de privacidad antes de compartir información. Privacidad
¿Una idea para mejorar StoryFlop?
Comparte una propuesta o cuéntame qué ha fallado. No necesitas una cuenta. Los mensajes son privados y los revisa Jaume.
Contacto y soporte
También puedes escribir a este correo para comunicar incidencias, proponer mejoras o correcciones de las guías y consultar sobre privacidad.
Para una incidencia, indica la página, el navegador y los pasos para reproducirla. Para una corrección, incluye el enlace y el párrafo al que te refieres. Evita enviar códigos de salas activas o contenido confidencial del equipo.
Cómo están planteadas las guías
Los recursos publicados bajo la firma StoryFlop forman parte de la documentación del proyecto. Explican el uso de la herramienta y proponen ejercicios de estimación; no representan una certificación ni una afiliación con los autores del método o de Scrum.
Las guías separan las funciones de StoryFlop de los ejemplos de otros productos. Los casos y los personajes son ficticios y se indican como tales. Los números sirven para explicar una decisión; no son tablas de esfuerzo reutilizables entre equipos.
Cada guía incluye su fecha de publicación y las fuentes pertinentes. Las correcciones y los cambios sustanciales se reflejarán en el contenido y en su fecha de revisión. Puedes sugerir mejoras cuando una instrucción resulte ambigua o deje de coincidir con la aplicación.