Skip to main content

Sprint Goal a difficult balance

Last post 04:18 pm June 13, 2024 by Daniel Wilhite
4 replies
04:26 am June 13, 2024

I have a dilemma that is common in agile product management, particularly with Scrum. In theory, the Sprint Goal should guide the selection of backlog items for the sprint, and only the items directly related to this goal should be included. However, in practice, technical constraints, transversal needs, context-related tasks, and necessary improvements based on feedback may require adjustments even if they have nothing to do with the Sprint Goal.

How do you find the right balance? What approach do you recommend?

04:41 am June 13, 2024

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 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.

04:47 am June 13, 2024

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.

10:19 am June 13, 2024

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.

04:18 pm June 13, 2024

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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.