When the Sprint Goal becomes less engaging...
As a Scrum Master, I try to teach the Team with effective practices inspired by Scrum.
One point I am struggling with: I find it often difficult to influence Teams to use a "Sprint Goal".
Most of the Teams I work with do not have a real sense of urgency.
So they usually spend their sprints working on: translations, small adjustments, minor bugs fixes, small additional features, etc.
In this context, how is it possible to use a sprint goal based on your experience?
If your Product Owner is ordering that kind of work at the top of the Product Backlog then the team is working on the right things. I have had teams in similar situations while our Product Owner is waiting on some results from experiments that we have released. In those cases I will craft a Sprint Goal and suggest it to the team. I try to have it cover the most important things being done but it does not have to cover the entire body of work that is forecast. Find a set of the items that will provide a combined set of value and craft the goal around that.
If they frequently do not want to craft goals it appears to me that they have not realized the benefit and importance of it. They need to understand how the Sprint Goal should be influencing all of the decisions that they make during the sprint. You may need to "influence" that a bit. At Sprint Planning craft and suggest a Sprint Goal based on the items that the Development Team has pulled into the Sprint. Write it on a piece of paper and put it on the wall somewhere in their area so that they can see it. (If they use a physical board put it above or beside the board). Attend their Daily Scrum. After they have finished, see if they will allow you to ask a question. That question is "How does everything you discussed today influence the Sprint Goal?". Help them start to take that into consideration on a daily basis. At Sprint Review start by reviewing the Sprint Goal and at the end ask them if they feel that they achieved it.
You have to help people appreciate the Scrum ideals/artifacts/events/etc or they will just view them as "stuff we have to do". The Scrum Guide states that the Scrum Team crafts the Sprint Goal so as Scrum Master you are part of that team. Talk to your Product Owner to see if they understand the importance. If so, they can help you in illustrating to the team how important it is. If not, then you will also need to help the Product Owner learn to appreciate it.
Are the team working on a complex product which would make the use of Scrum, including Sprint Goals, worthwhile?
Thank you for your kind answers.
As a Scrum Master, I try to teach the team focus on a particular goal each sprint, and for that, I coach its members to maximize added value and have them work on the highest value items first. I basically do as you suggest to try to influence the team with adopting this vertuous habit. Teaching them as a mentor and inspire them using practices as those you suggest too, which are familiar to me.
But it often happens when a product is already on the market since a while, making a good amount of money, that innovation and new ideas start to decrease. At this stage, teams start to work on fine tuning the product, and not every sprint can be delegated to bringing new features.
On a theoretical point of vue, I get the point that every sprint should bring added functional value, but in reality, not all of them allow the team to work on new ideas. So I do just like you do : trying to "package" a few prioritary features behind a common theme, whenever it is possible to.
Having worked for smaller companies with a stronger sense of urgency, I found it easier to apply the spint goal concept as it was a condition to survive in a highly agressive economic environment. In bigger companies, it's not often so easy to setup a product and entrepreneurial culture, and teams are often dedicated to maintain an existing product, and adpating it to the evolving environment.
Have you considered switching to Kanban instead of Scrum?
If the team is working on small, somewhat incoherent tasks then you are probably better off focussing on flow.