Sprint Goal a difficult balance

Hi Andrea,

Prioritizing would be the key. I normally classify the sprint backlog into Must haves, Should haves, Could haves and wont haves (based on relevance to the sprint goal...so non negotiable items with high impact on the goal would be the must haves). The could have and wont have items would be the slack which you can drop from the sprint as they dont impact the goal as much as the must have and should haves. In case there are tasks which come up during the sprint validate it against the goal and if not related check if can be added to the product backlog. If the tasks are critical and need to be taken as a part of the sprint then you can remove items from the slack and prioritize the new ones.

If it is planned improvements and required to clear technical debt then you need to have the sprint such that you do 70% new features and 30 % improvements (the percentage can vary based on scenario). If the improvements can be something which can be verified then you can add it as a part of the sprint goal like improve response time by x seconds.

Based on the situation you can figure out the best approach after discussion with the team during the sprint retrospective.

Scrum is commitment based. The Scrum Guide makes it clear that during the Sprint no changes are made that would endanger the Sprint Goal. So, as long as the work you are describing does not put the Sprint Goal at risk, there is no prescription against doing it.

Where do you get the idea that only Product Backlog Items directly related to the Sprint Goal should be included in the Sprint Backlog?

Although I have worked with teams that work this way, I've found it less than optimal for the very reasons you describe. There are often maintenance tasks that the team not only needs to do to keep productivity high in future Sprints, but that the team has capacity for in the Sprint being planned. There could be other types of work, too.

I don't think there's a magic number for how much capacity should be dedicated to the Sprint Goal and how much capacity should be dedicated to other work. I've seen cases where achieving the Sprint Goal - the most valuable change for stakeholders - was very small and only used a fraction of the team's capacity. I've also seen cases where the best possible Sprint Goal took most of the team's available capacity. I see this as a struggle between the Product Owner, who is seeking to maximize stakeholder value, and the Developers, who are seeking to maximize their ability to continually deliver value over the life of the product. It's up to each team or organization to find that balance, and the right balance could change Sprint over Sprint.

I would also like to know where you found that the Sprint Backlog has to consist of only items that support the Sprint Goal.  In my experience, there are always some items that the Developers choose to include in the Sprint Backlog that have nothing to do with the Sprint Goal but have everything to do with their ability to continue delivering usable, valuable increments (think technical debt items). 

The Sprint Goal allows the team to focus on the most important items and ensure that they are addressed.  But it does not prohibit them from including other items that are needed.  For example, there could be some technical debt that needs to be addressed before items in the Product Backlog could be ready to be pulled into a Sprint. If the team is not able to pull items like that into a Sprint, they may never be able to address the items in the Product Backlog.

Think of it this way.  You may have a goal to travel from Paris to Rome via car.  Your goal is to get to Rome but that doesn't mean you can't stop along the way or even take a small detour to see some sights. As long as you arrive in Rome at the designated time, you can do some extra things along the way.