You’re welcome, Frank. I’m glad I could help.

Thanks Roman. I am not familiar with Kanban yet, but yes, some on the team have already suggested the same, so I’ll be looking into switching.

Thanks!

Thanks for sharing your challenge Frank. Given that your team works on a mature platform and has to commonly carry out unrelated activities, I suspect that using Kanban instead of Scrum might be better for you, see my article Is Scrum Right for Your Product? You may want to use one of your next retrospectives to discuss if you should change the process or stick with your current Scrum-based approach. Hope this helps!

While these are not “user stories”, they are sprint work that definitely requires testing and at times, some development. Mix this with constant compliance and audit requests (it’s a financial institution), you can see that each sprint has multiple, and often unrelated activities that fall upon the responsibilities of the scrum team. Unfortunately, it’s not feasible to break up the scrum into smaller more focused teams since all these activities do relate to the product.

Not surprisingly, we’ve never had one shared goal and don’t even think we can ever land on one. We even struggle to define multiple goals without them sounding like re-worded epics.

Trying to give you as much detail on our accountabilities. Any advice on how to define clear goals in our case?

Thank you for sharing your feedback and approach Frederik. Sounds interesting! I am wondering if you are combining the product goal and the sprint into one objective. Personally, I would prefer to keep them separate, and I am happy to work with sprint goals that are solution-focused–as the corresponding product goal described the desired outcome or benefit that the product should create. Please take a look at my articles “Leading Through Shared Goals” and “Product Goals in Scrum.” Hope this helps and good luck with choosing the right sprint goals!

The development team I am a part of are in the process of revising our way of work to put our sprint goal at the very forefront of what we are doing. This goal will capture an important business problem or outcome we want to achieve. It will be solution agnostic and have a wide solution space.

“Refinement” will be creating a shared understanding around the problems we are planning to solve and discussing high level solution candidates we might pursue. We will not formally size beforehand nor have a strict definition of ready. Slicing items to reduce scope and optimize value will be done inside the sprint itself.

The reasoning is to avoid feature factory thinking, where features/solutions are defined in detail upfront and engineers have often limited opportunity to influence them – we would like to focus on creatively and collaboratively solving well defined problems in a cross-functional effort. All inside the sprint.

Do you have any experience or learnings with this kind of approach? Would love to hear any input or feedback you may have. Thanks!

Thank you for your feedback and question Andreas. In order to effectively use sprint goals, you would have to experiment with working on product/solution per sprint and possibly running shorter sprints. In addition to strengthening teamwork, this approach should also increase the productivity of the team, assuming that team members currently switch between products/solution in a single sprint. Hope this helps!

Thank you for a very insightful post on the sprint goal. I find it difficult to get my team to value and actively use sprint goals. I think it has to do with the nature of their work. They develop automated solutions of manual processes for customer service systems mainly through the use of RPA software. Therefore we mostly have sprints where they work on different non-related solutions. This is because we prefer that our solutions aren’t too complex, and that our different customers often requests more solutions to our backlog. So we want to deliver each solution quickly. This makes it hard to formulate a common (simple) goal covering most of the sprints work. Therefore, our sprint goal mainly consists of meeting the acceptance criteria on the top user stories of the sprint.

Do you have any advice on how we can use the sprint goal?

Hi Julian, Thanks for sharing your question. To determine the right criteria, ask yourself how you can tell if the sprint goal has been achieved or not. You may want to try my sprint goal template, which encourages you to explicitly state the metrics for a sprint goal. Hope this helps!

thank you for this insightful post on sprint goals. Maybe you have some advice for my team and me.

In Scrum Master Training, I learned that the team should do a forecast of the work it can achieve in the sprint. A sprint goal is then worked out by the Scrum Team, following which some PBIs that were forecasted for the sprint may be exchanged for PBIs which better match the Sprint Goal.

So far, so good… In practice however, we’re having some difficulties. The most pressing of which is how to make the Sprint Goal measurable. As I understand it, in order to be an actual goal, there must be some criteria with which to evaluate whether or not the goal has been met at the end of the Sprint. For some time now, we’ve sort of picked the most important acceptance criteria of the PBIs that were forecasted and put them down. But in essence, that’s only marginally better than defining the sprint goal as “finishing all the selected PBIs”, which is exactly what we don’t want as a sprint goal.

So, my question is this: How does a Scrum Team arrive at criteria it can use to inspect whether or not the Sprint Goal has been met at the end of the sprint? Do any of you have some real-life examples of good and measurable sprint goals?

Regards,
Julian