Skip to main content

Clarification about Sprint Backlog and Sprint Goal

Last post 12:32 pm March 11, 2022 by Thomas Owens
2 replies
10:34 am March 11, 2022

Let me first mention the Scrum Guide 2020 parts I am going to refer to in this post:

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).


the Sprint Backlog is updated throughout the Sprint as more is learned


(Sprint Goal) it provides flexibility in terms of the exact work needed to achieve it


(Sprint Goal) If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.


As far as I understand:

- the Sprint Goal is part of the Sprint Backlog

- the Sprint Backlog can be updated during the Sprint

- the Sprint Goal can not be changed/updated during the Sprint, as it should be flexible enough (to welcome the other Sprint Backlog changes, I guess).


Here are my questions:

1. Is my above understanding correct?

2. How a goal can be at the same time "specific" to clearly state/know when it is achieved, whereas being flexible at the same time?

3. What would be some good basic examples of Sprint Goals? In an E-Commerce context, might "Allow the customer to pay with credit card in order to create his order" be one of these? (it does not sound really flexible to me, and it looks like "implement feature X")


11:06 am March 11, 2022

It isn't the Sprint Goal which ought to be flexible. Flexibility ought to lie in the forecast of work required to achieve it.

A good Sprint Goal makes the selection of work on the Sprint Backlog coherent and gives the team a reason to work together that Sprint.

Paying by credit card might be a good Sprint Goal in so far as it allows a clear commitment to be made by the team, and provides flexibility regarding the providers, intermediaries and technologies used in the solution.

12:32 pm March 11, 2022

I think your understanding is generally correct.

One of the mistakes that I see when thinking about the Sprint Backlog is around the set of Product Backlog Items that are selected for the Sprint, but I'm not sure if you are making this mistake or not. Some people believe that there is a close relationship between the set of selected Product Backlog Items and the Sprint Goal. I don't believe this to be true. The Sprint Goal does help guide the selection of Product Backlog Items. At the end of Sprint Planning, however, there may only be one or two of the Product Backlog Items that are believed to be necessary to accomplish the Sprint Goal. There are clear separations between the Sprint Goal, the set of Product Backlog Items selected for the Sprint, and the team's capacity. At Sprint Planning, you craft the goal as one that is achievable within the Sprint timebox. Then you select the Product Backlog Items that the team believes are necessary to accomplish the goal. You should check to see that the selected items still make sense for completion within the Sprint. If you still have remaining capacity, the team can decide to select some other Product Backlog Items so they have a clear picture of what to work on after the goal or they can defer this decision until during the Sprint, as the items in the Sprint Backlog all become Done.

Going to the specific example of a Sprint Goal of "allow the customer to pay with a credit card in order to create his order", that feels like a Sprint Goal that can be accomplished by implementing a very small number of Product Backlog Items. Depending on how you slice it, you may have a PBI around the happy path and then additional PBIs to handle various error conditions (or perhaps handle them more gracefully). If it is critical to stakeholders that credit card payments are delivered and the team determines that this Sprint Goal can be accomplished at some point within the Sprint timebox, though, it could be a reasonable Sprint Goal. If it is a straightforward goal, it may be accomplished well before the Sprint concludes. The team may choose other work to fill the remainder of the timebox. Some examples of things the team could do include pulling in additional Product Backlog Items that are ready, refining the Product Backlog, paying down technical debt, building skills and improving cross-functionality, or even just taking time off to rest and ensure a long-term sustainable pace.

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.