Utilities Team - Sprint Goals?

One Sprint Goal which mitigates a significant risk or uncertainty, and which gives the team a reason to Sprint and to demonstrate teamwork at all.

What criteria are the Developers currently using to choose the work they will do?

Is a team that is responsible for developing components in a wider application a Scrum Team? I'm not so sure. According to the Scrum Guide, a Scrum Team "is accountable for creating a valuable, useful Increment every Sprint". Although important, I don't think that the customers and users of your product generally see value in things like logging, message display, or file listing outside of a context. This is why the prevailing thinking is that Scrum Teams should, more often then not, be focused on an end-to-end flow of work in a particular domain.

This isn't so say that other types of teams don't have a place. The struggle is that the work of these teams specifically supports other teams. In my experience, complicated subsystem teams and enabling teams tend to have a problem defining Sprint Goals, especially that directly align with the Product Goal. They tend to offer services to the other stream-aligned teams and their work may change as other teams learn more about their context.

I'd recommend stepping back and looking at the purpose of a Sprint Goal. Over the course of the sprint, the unknown and unexpected will happen. If things go horribly wrong, what one valuable change should come as a result of the work of the team? The team can use this at their Daily Scrums to stay focused on making sure the most important things get done and become available for the other teams. Although if they struggle to remain focused for a whole Sprint or their goals frequently become invalidated, it may be better to focus on continuous flow of prioritized changes rather than goal-based development.

@Ian Mitchell, the PO will tell them what the most urgent needs are according to the business, and will have the PB prioritised. The team will then pull PBIs into the sprint based on their velocity "Well...we can pull those two in, and between them they'll complete the logging functionality. And we can pull those four in, and that will complete the message display aspect. Then we can pull those other three in and that will complete the file list functionality. And that brings us to our velocity, so that's it!"

@Thomas Owens - yeah, I appreciate what you say. Are we actually a Scrum Team? I'm not sure. There has been talk previously about us moving to Kanban, but whether that actually happens or not is another question.

Given what you say above, would you think that Kanban might be a better fit for the team?

A little background - I've recently come into this team, and while I'm a CSM, I'm not the SM for this team (I'm a BA). So I've found it as is - currently we don't even use sprint goals, but if we're going to do Scrum, we need to have them. We don't do a sprint review, either, on the grounds that often there isn't a demonstrable increment. Yes, I know, I know. That means we're not really doing Scrum at all. But I'd like to move the team closer toward it, including bringing both sprint goals and sprint reviews back. But it may be that due to the nature of the work the team does I'm trying to fit a square peg in a round hole.

I agree with @Thomas' assessment.  I have worked with a number of "service" teams and they weren't very successful with Scrum.  Kanban did work better for them.  However, the challenge becomes synchronizing the Kanban delivery with the needs of the Scrum teams. It is possible with a lot of communication but it can get a bit stressful at times. 

Has there been any consideration given to letting individual product teams work in the service's codebase and cut the reliance of a special team for those things?  That was an option we took at one of my former companies and it worked out.  The "services" team members were split up and added to product teams.  They learned about the product code and educated the others on the services code.  

The main question I would have is: "what is the product?". I notice some organisations starting to use scrum as a way of structuring the work that flows through a team, and trying to implement focus, transparancy, etc. All very good. But if you leave a team without a clear product definition, and you e.g. do not assign a PO, the rest becomes very difficult to do. 

Sprint Goals should normally have something to do with a journey towards a product vision, making a product better or more valuable. If you struggle to set a sprint goal, check back to your product vision to see what it is you're trying to achieve in the long run.

I agree with the points mentioned above.

Given what you say above, would you think that Kanban might be a better fit for the team?

This might work as you can work on tasks based on priority and need not be worried about the sprint goal. Again there would be a communication overhead with the teams that you support as they would more often than not ask for an ETA and you will have to manage expectations of multiple teams. But Kanban might work better for you and you can validate it by trying it out. 

Another option is to align resources based on products and be a part of the product scrum team. This might be challenge in organizations with resource constraints where priority is given for utilization rates. 

You will have to experiment and see what works best.