The 11 Advantages of Using a Sprint Goal

Can't see the value, all the values you suggest are covered by the basic scrum principles. So, the PO prioritises the backlog, sprint planning uses known or believed velocity to fill the sprint to what can be committed to, and the sprint backlog should then be prioritized, and devs take each item in sprint priority order.

The principle purpose of the Scrum sprint was simply to timebox delivery, so you are not really delivering a specific feature, just what can be delivered in the timeboox agreed. A feature delivery would be more likely to be part of a release (so one or more sprints would go to make up a release). In theory every sprint should make available something that could be of business value, but in practice outside of the rarefied world of small software companies most organisations don't want the disruption of frequent releases but want more planned releases, typically 3-6 months.

So there is nothing to stop having a sprint goal, but for me it's covered by the basic scrum backlog management and sprint planning processes that already exist and for me just adds an additional layer of bureaucracy.

I struggle with the value of Sprint goals. Especially when most or all of the work being carried out is of a technical nature, and/or the team is working on multiple unrelated features, which aren't served by a single goal. It probably has a lot to do with the structure of the projects I am working on, whereby a simple functional desire is delivered over many sprints and involve multiple environments and development platforms. At present, we are writing a statement for each feature/project per sprint, so can have a few goals, (albeit in priority order). I kind of believe the goals work in very dev environments with uncomplicated requirements, that easily deliver functioning software each sprint. When just doing the back end technical stuff to enable that end goal across multiple sprints, a Sprint goal seems to have little value? But that could be because we seem to be working in a Water-Scrum-Fall way :)

All that said, I think your points for having a goal would be valid for us, were we able to deliver working solutions quicker, instead of across so many sprints. It feels like we should just maintain the same goal across the sprints until we deliver?

I enjoyed this quick read. I think of the sprint goal as the commitment, not the summary of the PBIs within a sprint backlog. I consider it a tool to assist the dev team in their negotiations with the PO about which work will be added to the sprint. Very rarely can work be selected with top-down order unless the PO is also an engineer involved in the architecture and implementation. Furthermore, as priorities change within the sprint, it may be possible to pull out work from the sprint backlog and replace it as long as it does not compromise the sprint goal (e.g., addressing technical debt, tertiary projects added as velocity filler).

Hi Julian

Thanks for you to share your thoughts! The situation of my team is same as yours: the team is working on multiple unrelated features. It is indeed hard to include them in a single goal. A single feature might cross several sprints. A Sprint goal for several sprints could be a good idea so that the team can put more focus on the going feature under the way.

Thanks Barry for sharing.

I have a question to all out here, is it a good practice to define more than one sprint goal? I need a good reason for NOT having more than one Sprint Goal. As part of basic understanding and scrum guide, team would loose focus. What else?

Thanks,
Raj

Is the sprint goal just a list of PBIs????? Can I complete the sprit goal and complete the sprint, if I have not completed the PBIs from the backlog? Can I complete the sprint if I complete all my sprint backlog PBIs, but not the spirit of the sprint goal? If I add a technical debt PBI to my sprint backlog, does it need to be incorporated in the sprint goal? ("Create a mind-reading UI for babies, and clean up the audit logs" It feels like there are 2 masters here that I don't know how to reconcile.

I do not see the value of this. To me it is just more layers of overhead that is not a value add, which is not something I need.

No, the sprint goals generally is the business value delivered at the end of the sprint. That could be accomplished via the PBIs moved into the sprint backlog, or a different list of items. The team commits to delivering the value, any way that they can deliver that value is okay. The sprint backlog is a plan that exists at the start of the sprint to achieve the sprint goals, but if another approach were to be found mid-sprint, that was both better than the original plan and doable in the sprint, then the team is free to change the plan (and the associated list of PBIs in the sprint backlog) to implement this new plan, as long as it still delivers the sprint goals.

To me this makes a lot of sense. The sprint goal is what the team commits to; the sprint backlog (composed of PBIs) is just a plan to achieve the goal. If, on day 2 of the sprint, it was discovered that the sprint goals could be achieved with a different set of PBIs, the team could choose to select the second set of PBIs. There is no penalty for not completing the original set of PBIs agreed to at the end of sprint planning as long as the team still delivers on the sprint goal.

This is possible because the team has deep insights into the POs or business' vision, mission, and problems they are trying to solve. You don't want a scrum team that simply does the work as agreed to at the start of the sprint. They should be open to better solutions that maybe no one has thought of.

Thanks for sharing https://www.romanpichler.co... . There is always a valuable stuff hidden somewhere down there but one has to recognize and share the reward of appreciation. Many Thanks once again!

Creating a single goal helps the team to share responsability to achieve it. By defining more than one goal, the team members may focus each one in one goal separatedly, decreasing the collaboration and the product backlog cohesion.

But who decides if the new approach is really achieving the sprint goal? The initial PBIs have been prioritized by the PO and assessed by the devs and there have been a chance to discuss it in detail. On the otehr handl the Sprint goal is just a more vague statement that can potentially be interpreted in different ways.

The PO decides if the sprint goal is meet. The PO is a member of the team and interacts and reviews what the team is doing daily. If that is not the case then the team doesn’t really have a PO, right? One of the agile principles of that the developers and the business work together daily.

Thanks, but I do not see the differens between Sprint Goal and Sprint Objective.

As it seems in this case, a summary of what is going to be delivered could make sense as spring goal? A dozen of small unrelated PBIs (perhaps what remains from implemented features from previous sprints) could still have a goal , ie. a formal short description that describes them well. Consequently, if PBIs remain as not implemented after completing the current sprint, they could feed another sprint in the future with the same goal more or less.