Sprint Goal

Do you usually come across the question “Why do we need a Spring Goal for?” or even worse “What is a Sprint Goal?”.

Well, I ‘d suggest to read the Scrum Guide (2017) in the first place. There is a whole paragraph dedicated to the importance of the Sprint Goal. Let me just copy and paste this for you:

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Let’s try and break this down. First of all, the Sprint Goal is one of the outputs of the Sprint Planning. It is the offspring of the collaboration between the Product Owner and the Dev Team. The Scrum Master should facilitate the creation of a Sprint Goal and should also keep in mind that a Sprint Planning without the creation of a Sprint Goal is flawed. So a tip to my fellow Scrum Masters: DON’T LET THEM GET AWAY WITHOUT A SPRINT GOAL. When Scrum Teams have face difficulties in crafting a Sprint Goal I ask them the following question: “How would you explain to your 5 year-old child what you will be doing for the next two weeks?”. Usually it works, as the Sprint Goal (imho) has to be something simple and not-so-much-technical.

Now, let’s just imagine that you are in a Sprint Planning without a Sprint Goal in place and the Dev Team pulls PBIs which are not related to each other. Then with a 110% certainty I can tell you that the Dev Team might finish all PBIs, but the value which will be delivered to the customer will be minimal, if non-existent. And this is just the best case scenario. In the worst case scenario will be occupied with very “interesting” and “exciting” fire-fighting tasks, without delivering anything. So, how does the Sprint Goal helps us? One word: Coherence. The Sprint Goal is like a mini vision on the Sprint level, a lighthouse that guides the Dev Team. By doing that three things can be achieved:

1) The collaboration between the Dev Team members increases as everyone is inspired to work towards a common goal,

2) It helps the Product Owner to deliver real coherent value, which in the future will increase the ROI of the product and

3) The Sprint Goal allows the team to be more flexible (i.e. it increases agility), by letting them readjust their Sprint Backlog in order to fulfil the Sprint Goal.

Here lies a very common misunderstanding in Scrum; the Dev Team does not commit to PBIs, but instead they use the Sprint Goal as a reference. Teams that commit to PBIs are free to do so (as you are free to jump off a bridge) but what they usually end up with is a very inflexible process. If for example you want to travel from London to Glasgow and you commit to travel by train and the latter is suddenly on a strike then what will you do? Wait until the strike is called off or look for other options? If you have committed to the PBI (i.e. travel by train) you will not arrive in Glasgow on time. On the other hand if you “let” the Sprint Goal to guide you, then you have the flexibility to adjust your initial Sprint plan and look for other options. Here, I would like to point out that the Sprint Goal does not change. If the Sprint Goal becomes obselete then the Sprint has to be terminated.

It is possible to achieve the Sprint Goal even without implementing all items of the Sprint Backlog, that’s the essence of being adaptive and focused. However if you see that the Sprint Goals becomes obsolete due to various reasons (organisational, technological, market etc.) then the Sprint has to be terminated and start a new one, taking the new variables into consideration. In short, there is no value in winning all your battles and then lose the war. Win the war even if you don’t dominate all battles.