Technically, what should a sprint goal actually consist of? What should it ideally include and cover, or mention?
Technically, what should a sprint goal actually consist of? What should it ideally include and cover, or mention?
Hello,
Your question isn't good because there is no notion of Technical in Sprint goal. This is just a goal to be achieved by a DT before the end of the Sprint. And Scrum is not only for "technical" projects.
In other terms, your question makes more sense with the definition of Done in the case of "technical" projects. For example, following concepts of Continuous Integration.
Regards,
Maxime Hochet
The sprint goal can be anything that causes the Dev Team to collaborate on the increment during the sprint instead of working separately on different PBIs.
Often it is a new feature which makes it necessary to get several PBIs done.
If you take one PBI and declare it as sprint goal, it can easily happen that only one developer works on it, so the focus is lost for all other developers. They will not be able to answer the three questions in the daily Scrum, and even worse, the risk increases that the Sprint goal is not met.
Hi Quick Scrum,
be also careful to distinguish between the Definition of Done and the Sprint Goal:
The Definition of Done should contain all that is needed to decide if a Product / Sprint Backlog Item is done, e.g. detailed quality or performance criteria. You can test against the Definition of Done. The Definition of Done is tangible and concrete.
The Sprint Goal's purpose is to provide "guidance to the Development Team on why it is building the Increment" (Scrum Guide). I think, the Scrum Guide doesn't specify it further because it's value is very abstract - and concrete mechanisms that are absolutely right for one individual to achieve an abstract goal can be completely wrong for another. Perhaps you can also see the Sprint Goal like a vision for the sprint.
I'd recommend trying to find a concrete Sprint Goal for your concrete situation yourself. The odds are in your favor that your Sprint Goal will suit your team better than a Sprint Goal anyone else defines (from far away). And if it turns out to be bad: just try to do it better in the next Sprint.
> I'd recommend trying to find a concrete Sprint Goal for your concrete situation yourself.
And "you" should already include the whole team, of course, as the shared Sprint Goal emerges from the shared Sprint Planning Meeting...
Posted By Anke Maerz on 25 Sep 2014 08:04 AM
Hi Quick Scrum,
be also careful to distinguish between the Definition of Done and the Sprint Goal:
The Definition of Done should contain all that is needed to decide if a Product / Sprint Backlog Item is done, e.g. detailed quality or performance criteria. You can test against the Definition of Done. The Definition of Done is tangible and concrete.
The Sprint Goal's purpose is to provide "guidance to the Development Team on why it is building the Increment" (Scrum Guide). I think, the Scrum Guide doesn't specify it further because it's value is very abstract - and concrete mechanisms that are absolutely right for one individual to achieve an abstract goal can be completely wrong for another. Perhaps you can also see the Sprint Goal like a vision for the sprint.
I'd recommend trying to find a concrete Sprint Goal for your concrete situation yourself. The odds are in your favor that your Sprint Goal will suit your team better than a Sprint Goal anyone else defines (from far away). And if it turns out to be bad: just try to do it better in the next Sprint.
I completely agree with this. You've got to find the goal that helps your team collaborate - not necessarily working toward getting a technically "correct" sprint goal. It doesn't exist.
> Technically, what should a sprint goal actually consist of?
At a purely "technical" level a Sprint Goal must consist of a value justification for the Sprint. If the Sprint Goal is compromised then the Product Owner can choose to abort the Sprint.
A Sprint Goal must therefore be achievable by a collaborative team, and coherent in terms of its agreed scope. Without those qualities value will not be delivered.
I agree with most of the responses here. If you had to provide a catch phrase or a slogan or a prominent benefit or a feature name that the team can easily snap to and remember throughout the sprint while they are working on the increment and which gives direction to the team and helps them focus, that would be a sprint goal. These are only some examples, but it can be anything that serves the underlying purpose. That is the reason the Scrum guide does not provide specific guidance on it.