Stakeholder pushing to add more stories into the sprint

Question

Sprint planning is done. Sprint backlog is ready. Sprint goal is set. Now stakeholder wants to add one more story, even though there's not enough capacity to deliver it.

Team agreed to take this story, if we can remove any other story from sprint backlog to accommodate the new one, but stakeholder refuses to remove any story from the Sprint backlog.

I already explained that the Sprint goal is set and it’s not advised to change the goal when Sprint is already in progress. How to handle this situation?

Answer 1

There are three things to consider: Sprint length, Sprint Planning, and Product Ownership.

One of the determining factors in Sprint length is the ability to synchronize with the business or stakeholders. You want them to be long enough such that you can get value-added work done, but short enough to be able to incorporate valuable feedback. You also need them to be long enough to allow stakeholders to generate feedback, but not have to wait a long time to get an Increment with the feedback incorporated. In your case, perhaps a 3 week Sprint is too long - if feedback comes in very early after Sprint Planning, the stakeholders may be waiting nearly 6 weeks to see that particular feedback delivered.

Another common piece of advice is to not allocate 100% of your Sprint to the Sprint Goal. Consider that the Sprint Goal is what the team is committing to delivering to the stakeholders. If your entire Sprint capacity is dedicated to the Sprint Goal, you have no way to handle things that come up, such as team members needing to take time off without warning or production issues that require immediate attention or minor changes to the Sprint Backlog based on feedback. A rule of thumb that I've seen and encourage applied is between 60-70%, as a maximum, of the Sprint Backlog should be related to the Sprint Goal. If your organization frequently has the team handling emergent issues, you can consider dedicating even less of the Sprint Backlog to the Sprint Goal.

The third point is Product Ownership. The Product Owner needs the ultimate authority to order the Product Backlog, which often means the ability to say no to stakeholders. However, having a Sprint length that better supports synchronization with stakeholders outside of the Scrum Team and a Sprint Backlog that is more forgiving to emergent issues can both help the Product Owner and the Development Team support changes while still being able to give reasonable forecasts and then reflecting back on the forecasts.

This also sounds like a good opportunity for the team's Scrum Master to teach the stakeholders about the value of iterative and incremental development, empiricism, and the strengths of Agile Software Development and Scrum.

Answer 2

Adding to the excellent answer from Thomas.

A lot of people who are not experienced with software development think that the more features that get implemented in a sprint, the better it is. They do not understand that there are implications for quality and for team workload/morale.

Try not to think of the stakeholder as a problem. Instead, work closely with them to understand their needs and their motivation. The ideal result is an approach that works well both for the team and for the stakeholders.

It is also important to reflect the pain. If the stakeholder insists on adding work to an already packed sprint then they need to understand the implications. If you don't have time to do some testing or if there are incomplete stories at the end of the sprint, ensure that this is widely communicated.

For example, you could say at the sprint review something like:

With the late addition of a story it was a real challenge to complete all the work in the sprint. We ended up having to skip some compatibility testing and we didn't manage to do any user acceptance testing. On top of that there is some technical documentation that still needs to be updated, so we haven't been able to get all the stories to the team's definition of done.

Try not to be adversarial, but also make the results of their action transparent.