How do you manage expectations when stakeholders demand immediate changes mid-sprint?

If the sprint just kicked off with 85-75% of the sprint left, then it is somewhat manageable with the development and QA teams buy in to initiate rationalization. Identifying who the stakeholder is that is bringing the change is the first step since some stakeholders don't have actual authority to change the course of a sprint. The Stakeholder matrix should help with that if there is one. Then it is a matter of sitting with the Product owner/manager to help understand that brining things mid sprint would derail progress. Priority of the request has to be assessed, estimated and tradeoff presented, and if priorities can be shift with enough business justification, then it might be appropriate to bring this into the current sprint.

Considero que establecer límites claros es muy importante y también lo es comunicar de manera efectiva las consecuencias de los cambios solicitados por el cliente. Una forma práctica de establecer estos límites puede ser la siguiente: 1. Definir un alcance al inicio del sprint detallando claramente las funcionalidades a desarrollar, los criterios de aceptación y la fecha de entrega estimada. 2. Utilizar herramientas como kanban boards o roadmaps para visualizar el alcance del sprint y los compromisos adquiridos. 3. Establecer canales de comunicación claros y priorizar los cambios solicitados con base en el valor que aportan al negocio. 4. Negociar y ofrecer alternativas de solución si fuese posible.

Como se diz "o bom acordo inicial entre as partes pode reduzir muita frustra??o". Apesar de que se possa ser acordado com antecedência as exce??es previsíveis de problemas de percurso, um tópico muito importante a ser levado em conta é "sprint de curta dura??o", pois sprints que ultrapassam duas semanas tendem a elevar o nível de ansiedade dos POs e/ou Stackholders, principalmente num mundo acelerado de diversas formas, e poderá acarretar em cobran?as maiores e mais intensas. Agora, dentro deste contexto apresentado anteriormente, imagine adicionar a situa??o em que os "donos do negócio" percebem que priorizaram algo equivocadamente, ou que n?o faz mais sentido? Fatalmente o resultado será muito negativo de várias formas possíveis.

I love being flexible and agile. I take every request into consideration. I ask that the stakeholder show me the data and the impact this mid-sprint request will have, over the other tasks that are already slated for the current sprint. If it makes sense, then absolutely I want the engineering team working on the highest value features, and I want them recognized for making the effort and succeeding at the task. I also ask the stakeholder to make sure the request is clearly documented and there's a method to measure the result, to confirm all data and impact used to justify the mid-sprint change.

Lo más óptimo para priorizar estas solicitudes de cambio sería utilizar una matriz de priorización para evaluar el valor de negocio que aporta cada cambio solicitado y su impacto en los objetivos del proyecto, ya que con estos insumos será posible tomar decisiones más acertadas e informadas.

Change requests don't mean that every detail must be implemented on the next/current sprint, but the SM should immediately evaluate the change request so that the company will gain/maintain value per the request. This might mean working with stakeholders and scrum team on “smart” phased releases to address the whole change request.

Clients may not always understand the complexities involved in the changes they request, which can lead to unrealistic expectations. Educating clients about the potential consequences of late-stage changes, such as increased costs and delays, helps them make more informed decisions. By proactively explaining how scope creep affects timelines and budgets, you empower clients to prioritize effectively. A well-informed client is more likely to collaborate on solutions that prevent unnecessary scope expansion.

Al momento de gestionar las solicitudes de cambio y expectativas del cliente es muy importante escuchar atentamente las necesidades de las partes interesadas y buscar soluciones que satisfagan sus expectativas sin comprometer los objetivos del proyecto. Así mismo, en lugar de rechazar directamente una solicitud de cambio, lo ideal sería ofrecer alternativas o soluciones parciales que puedan ser aceptables sin llegar a afectar lo que se espera del proyecto.

I love being flexible and agile. I take every request into consideration. I ask that the stakeholder show me the data and the impact this mid-sprint request will have, over the other tasks that are already slated for the current sprint. If it makes sense, then absolutely I want the engineering team working on the highest value features, and I want them recognized for making the effort and succeeding at the task. I also ask the stakeholder to make sure the request is clearly documented and there's a method to measure the result, to confirm all data and impact used to justify the mid-sprint change.

Especially when consulting, implementing a formal change management process helps manage any deviations from the original scope. This process should include a system for submitting, assessing, and approving change requests, with a clear understanding of how these changes affect the project timeline and budget. By formalizing this process, you ensure that all changes are justified and approved by key stakeholders. It provides a controlled environment to adapt to necessary changes while minimizing disruption and maintaining client expectations.