Crafting a good Sprint Goal
The Scrum Guide defines Sprint Goal as the single objective for the Sprint, is a commitment by the Developers, and is part of the Sprint Backlog.
While many agree the importance of it, equally struggle in creating a good Sprint Goal. So let me share with you how I helped a Scrum Team write a good Sprint Goal.
While the Scrum Team had a good Definition of Done in place, they didn’t have a Sprint Goal. Actually, they had it, but it was same as “Completing all Sprint Backlog items”. When I enquired, I got a question I somehow expected — “We have our Sprint Backlog and we have to deliver all the items, so isn’t that supposed to be our Sprint Goal?” I am sure few of you must have experienced this question sometime in your journey.
Saving your time from that conversation, and the explanation part on Sprint Goal, let me take you to the next Sprint Planning event. And I could see the same pattern getting repeated. Smith, the Product Owner presenting the Product Backlog, and Developers pulling Product Backlog Items into Sprint Backlog and crafting similar Sprint Goal — “Getting all PBIs done”.
I could relate the Sprint Goal as manifestation of Habit — 2 “Begin with End in Mind” in a much inspiring book “The 7 Habits Of Highly Effective People” by Stephen Covey.
Taking that inspiration, I asked the Scrum Team to frame in one sentence what does the end goal of this Sprint look like, the sentence which they would put in the Sprint Review invite to stakeholders and which will excite them to participate. The sentence that will give them a true purpose, and reason to collaborate. Something that will motivate them to come to office every day for the entire Sprint !
The Scrum Team looked at their Sprint Backlog and struggled — they could not find any pattern within the chosen PBIs as all seemed unrelated. Smith showed courage initiating the conversation:
Smith: “How do you create a Sprint Goal out of the unrelated set of items?”
Anand: “We will come to that question. But for now, let’s take a step back and re-look at our Product Goal.”
Smith: “So, our Product Goal is ‘Improve online Customer claim submission from 30% to 60% in 1 year’.”
Anand: “Good place to start with. With that as our end target, what else was in your mind when you ordered the Product Backlog?”
Smith: “I am worried about the increasingly bad customer satisfaction feedback on our Claim Submission form and I suppose that may have reflected in my ordering of the Product Backlog!”
Anand: “And how would this Sprint help in addressing your concern and help us progress toward the Product Goal?”
Smith: “If we could do something about the Claim Submission experience!”
Scrum Guide: The Product Owner proposes how the product could increase its value and utility in the current Sprint.
Now, the Scrum Team has a sense of alignment and they came up with an initial Sprint Goal.
Scrum Team: “How does ‘Reducing customer defect’ look like as a Sprint Goal?”
Anand: “Looks good! Now, how will we know if we have achieved the Sprint Goal? How can we make it SMART goal?”
Scrum Team: “How about putting some numbers to it? Like ‘Reducing customer defect in claim submission form by 20%”? Will this qualify as a good Sprint Goal?”
Anand: “That is something for you all to determine. Few pointers from my side though.”
· Will the Stakeholders be excited about it and looking forward to join the Sprint Review?
· Will it help the Developers remain focused for the Sprint duration?
· Will it provide flexibility in what work is needed be done to achieve it?
· Will it give a reason for the Developers to collaborate?
Scrum Team: “We feel we can tick most of those items for our Sprint Goal. So are we done?”
Anand: “Not yet! Given that we have agreed on the Sprint Goal, lets reflect back to our chosen Product Backlog items and see if we want to revisit it based on the newly created Sprint Goal.”
Scrum Team: “We could connect quite a lot of Product Backlog items to our Sprint Goal. So, now we see the cohesiveness you were talking about during our initial discussion.”
Anand: “Good to know. What else?”
Scrum Team: “We could see few Product Backlog items which cannot be linked to the Sprint Goal. What to do about those?”
Anand: “While you may have few Product Backlog items which may not be linked to the Sprint Goal, and that is OK. As an example, as part of your commitment to the Technical Debt removal, you may have an item toward that. But if you see a lot of Product Backlog items not having cohesiveness then it s a sign that either your Sprint length is too long, or that there the Product Backlog is not properly aligned with the Product Goal. Let’s hear from Smith and discuss with him on this.”
In discussion with Smith, the Developers were able to swap some unrelated Product Backlog items with the ones which would help achieve the Sprint Goal. And for the remaining capacity, Developers pulled in Product Backlog items which will help make product usable. And they considered revisiting their Sprint length.
Anand: “Now, I invite you to write your Sprint Goal in a big flip chart paper and put it in a common place where you generally conduct your Daily Scrum. And the very best of luck in your journey toward the Sprint Goal.”
I hope you had a good experience reading the above. In conclusion, a good Sprint Goal can help Developers remain focused on the purpose, encourage collaboration, and helps in flexibility on the plan to create a Done Increment by the end of a Sprint.
