How do you manage stakeholder requests during a sprint?

This is wholly inaccurate. The scope of a Sprint must be flexible, because quality (DoD), resources (team size), and sprint length are fixed. The first step should be to define a Sprint Goal that keeps the scope flexible to meet the goal.

In the real world, finding the right balance between satisfying stakeholder needs and keeping the sprint goal intact is essential. Open and regular communication with stakeholders is the secret to ensuring everyone's on the same page and expectations align with the sprint goal. While staying focused is crucial, we can also be open to some flexibility when important stakeholder requests arise.

Consider setting aside a bit of extra time during each sprint to deal with important and unexpected requests from stakeholders. This extra time can be changed as needed, depending on how urgent and essential these requests are.

Absolutely! Having a clear and agreed-upon sprint scope is crucial for effective sprint planning and execution in Scrum. The sprint scope serves as a commitment by the development team to deliver specific product backlog items during the sprint.

I need to agree with Maarten below: It's not about agreeing on the scope, it's about agreeing on the goals. As the PO is the one dealing with the stakeholders and requests, the team should focus on the delivery part and organize the tasks as they see fit, even modifying them during the sprint if it will allow the team to achieve the goal. Amending goals and scope due to PO's needs should be really rare and happen only in the most dire of situations, like when the sprint goal is no longer relevant.

This is the wrong approach, I would not stress what they can't do, but how you would like them to be involved at the Sprint Review for example. Collaborate actively with your stakeholders outside the events as necessary to succeed.

Clearly communicate the sprint's purpose to stakeholders. Emphasize that the sprint goal is fixed, and any changes to the sprint backlog can only occur under exceptional circumstances. Provide an alternative channel for stakeholders to share their inputs, such as through the product owner, so they feel heard without disrupting the sprint.

Again, Marteen is super right here - the stakeholders will like not care about your rules, but about the value they need to get from you. Explaining Agile scrum will likely come off as POsplaining stuff to them, only making things worse. It should be more of a case of understanding the stakeholder's position and urgency and making him/her understand your current position and commitments.

We follow - WSJF for the product backlog prioritization. We allow Stakeholders to input the request (backlog) but also request them to score them on a) User-Business Value, b) Time Criticality and c) Risk Reduction (Along with the reason why they scored higher or lower number) The Development team also score those task based on the time required to complete the requirement. Using the WSJF formula, we create Ranking and based on the Ranking, We pick tasks for the upcoming sprint based on the available capacity. This way, Everyone knows what will be picked up next and the reason for the same.

If stakeholder's requests are in line with Product roadmap and important from competitor product feature perspective then those requests need to be analysed with the help of various available techniques like MOSCOW, WSJF, cost of delaying other user stories, dependency mapping etc. Whole idea of Agile is to be flexible with requirements!

This is a terrible idea and you should not have a separate list like this, because then you have two lists to manage instead of one. It's your job to make sure there is no list, as the moment there is a queue you will be slowing down the time-to-market and be working on ideas a few years old.

"Use a stakeholder backlog"? Really? Great - let's have multiple sources of work for the team. That way it will be really easy for them to figure out what they should work on next. NO! Scrum is very clear. If stakeholders come up with new requests, they go to the Product Owner. If the PO considers the request to be something that needs to be worked on urgently, they can take it to the Developers and ask them if it is something they could take into the current Sprint without risking the Sprint Goal or reducing quality. If the Developers say yes, then they take it into the current Sprint. If the Developers say no, the PO then has the option to cancel the Sprint - thus creating visibility and transparency for the stakeholders.

Consider the size and complexity of your project when deciding whether to maintain a separate stakeholder backlog. In smaller projects or those with fewer stakeholders, direct communication with the product owner might suffice. For larger projects, having a structured stakeholder backlog can help prioritize and manage requests more efficiently.

With a simple thought process that the team "Owns" the product they create, we expect teams to make that decision themselves. Based on previous releases teams are also capable of anticipating incidents. All items that are not a part of sprint scope but could be done without impacting the committed program increment scope- the team can include and align with the business owner(s) or stakeholders. This is primarily a team decision as they are the "Owners" of the product. Any major issues that can disrupt the program increment needs to be communicated and discussed with relevant stakeholders -here the decision is based on impact to the customers and business instead of program increment / product development

That is not works! 100%. After a while, this new backlog becomes to a recycle bin! If something is valuable, so add to product backlog right now. if not, let it go! you don't need more backlog, you need more pivot!

Any "backlog" is just a tool, supposedly it should help us decide what we want to do next. If your tool (backlog) doesn't make decision making (leading your product) easier, then you likely have a non-helpful tool/artefact preventing you rather than supporting you.

Who is "you" in this context? The scrum master, an individual developer? Creating value is a team effort so there should be a WE-centric way of working. Avoid getting stuck in a one-dimensional list as long as possible. Try to work in a map-like format with a few possible paths to the impact that you are aiming for. If there is transparency for everybody that there might be different solutions that could create the outcome (not output) our customers (as a group, not a loud stakeholder) want, then it's also easier to scrap an idea that ends up not working. Just hop on the next experiment and don't get stuck in the sunk cost fallacy. Of course, you should define your experiments with a time box, metrics and learnings so you can validate them.

Well, in my practice, if stakeholder requests any changes during the sprint, I would first analyse the request with terms of the priority and the type of change. If their requirements are priority and makes sense, I communicate them and say in order to take that in to the current sprint, this is what I have to drop off depending on the sizing. If they agree and also technical team agrees and its a high priority, I would definitely accommodate the changes in the sprint, if not depending on the priority it will be added to the backlog and taken for the respective sprints coming in future. Sometimes the requests might be a total change. If so i'll have a thorough discussion with stakeholders and tech teams on our way forward before next sprint

I believe that two backlogs, Product and Sprint, are sufficient. The PO can make modifications to the Product Backlog based on Stakeholder input and reprioritize it. During the sprint planning meeting, the PO and Team can discuss prioritized items and pull the work into the sprint.

Priorizar o backlog, pode se tornar um desafio interessante, quando uma quantidade de Produtct Owners começa a aparecer, dentro do mesmo projeto/backlog. Neste sentido, a negociação precisa ser uma habilidade importante a entrar em ação, e surgem algumas perguntas: 1) Como é a comunicação com os Products Owners na sua organização? 2) Você investe tempo para conhecer suas expectativas? 3) você fala sobre prazos com eles? Uma grande variedade de questões que tumultuam o projeto diante de partes interessadas, acontecem por falta de comunicação eficaz.

Agile work is about learning. How do we learn more about the customers' needs to fulfil, the viability of the solutions we come up with and finally our way of working, in the team, between teams and with system around the team? Stakeholders, customers, other teams and everybody else who can help us by adding perspectives and providing valuable feedback are welcome to provide insights and learnings. If you measure sprint progress by reporting status per task then you are far away from a trust-based way of working.

Stakeholder can be identified based on their power, interest, influence etc and depending on the engagement matrix, a communication plan will help to coordinate and get inputs regularly throughout the sprint and product goals. Having their presence in the sprint reviews helps in collecting feedbacks and for the team to understand their scope clearly.

In the agile world, communication and collaboration stand out as the most crucial elements. Teams should consistently update stakeholders on sprint progress, communicate challenges, and share team achievements. Soliciting feedback is essential for continuous improvement.

Communication and collaboration with stakeholders on a regular basis should decrase the number of defects and additional requests, if the acceptance criteria is properly set. Educate stakeholders about the Scrum framework and cycle, set boundaries and agree on expectations. Even though Agile principle is to welcome change even late in the development phase, if this request is not urgent or if it is just a small aestethic change and the product is working well without it, you can put the request in queue and advise the Client why it is waiting and when is planned to be done. Of course if it an important functionality or urgent request refine the backlog and put it in the sprint

Active participation of the stakeholder is very important specially the PO. Keep them engaged, build trust, highlight to them the development work, once completed show case and take feedback on their opinion / acceptance. This will help build long lasting product.

To manage stakeholder requests during a sprint: 1. Capture requests. 2. Prioritize with product owners. 3. Include in sprint planning. 4. Estimate effort. 5. Communicate transparently. 6. Avoid scope creep. 7. Review progress daily. 8. Iterate as needed. 9. Stay flexible. 10. Document and learn for the future.

During a Sprint, managing stakeholder requests involves balancing the need to stay focused on the current Sprint goals while being responsive. If a request comes in, assess its urgency and impact with the Product Owner. If it's critical, the team might need to adjust the Sprint, but otherwise, note the request for future Sprints or the product backlog. Keep communication open with stakeholders, explaining why sticking to the Sprint plan is important for delivering consistent value, while also assuring them that their needs will be addressed in due time.

How do you manage stakeholder requests during a sprint? You say: “no”! Because there is a product backlog, sprints are short, and the team needs to focus.

Plan, prioritize, refine backlog if needed, be transparent about it and clearly communicate plan to the stakeholders. If needed educate them in the framework and the processes team has set.

Not sure you can say 'no' if it is a critical requirement and lives are at stake! In an ideal world you probably wouldn't want to bring new stories in mid-sprint but sometimes they trump all other priorities and have just got to be done - and quickly.