How to define sprint goal for small unrelated stories

Hi Toni,

two thoughts:

1. Maybe you should think about order the backlog and discuss possible sprint goals in the backlog refinement with the PO and the DT.
2. Sometimes people have to learn from their mistakes / failure. Allow the sprint without sprint goal and discuss the results in the retro.

Cheers

Nils

Toni Oksanen, You don't build Sprint Goals around a set of related features, rather the Sprint Goal should answer, what is most important for us to accomplish this Sprint to deliver value through the resulting Increment.

I hope this will give you some direction.

I've worked in a similar situation. Two possible ideas stand out.

Group the work and don't let vastly unrelated work into the same Sprint. If your most important work is in Feature X, pull in work that is also in Feature X, or related to Feature X. Your Sprint Goal can be some measurable objective related to Feature X. This doesn't mean that all of your work must be in Feature X - you may have some very, very important work in Feature Y or Feature Z. However, there can be advantages in spending a focused amount of time in one feature of the application rather than scattered work.

Use the Sprint Goal as a focusing tool. Even though you have many unrelated work items, choose the one theme that is the most critical objective. At some point between Sprint Planning and Sprint Review, you need at least one potentially releasable increment. What is the one thing that differentiates that increment from the previous increment? That is your Sprint Goal. The team can use the goal to focus their energies as they self-organize around the work. Maybe you create that potentially releasable increment very early in the Sprint - the team can self-organize the rest of the timebox to continue to do other valuable work. That work may not necessarily be user-facing product work. Maybe it's time to rest and recharge. Perhaps it's self-improvement. Maybe there's technical debt to be paid down. Once the goal has been satisfied, let the team use the time as they see fit, perhaps with some negotiation with the stakeholders and Product Owner.

For SaaS the complexity lies often lies in delivering a predictable service, rather than in mitigating feature risk. In such cases having a flow based Sprint Goal can be more appropriate than a feature based one.

Backlog may have FRs （feature requirements） and NFRs （non-feature requirements） distribution areas

Thank you all for your answers!



I think the main problem emerges from the too extensive product backlog. There are a lot of very small stories like "enrich some view with some piece of data" etc... which make it very hard for PO to prioritise them. Those stories are requested in general by the one customer and their value haven't been tested among the all customers. 



I'm not sure what to do in terms of these small improvements. In general I think it is better to concentrate on the most valuable PBIs, but making the improvements can increase the customer satisfaction. 



One idea is also to split the whole SaaS service to multiple value streams and establish own product backlogs for each of them. It can be a good idea, because it is pretty easy to recognised almost totally independent parts in business perspective and it is easier to compare the value of the stories, which belongs better to same domain. 

In such cases having a flow based Sprint Goal can be more appropriate than a feature based one.

Hi Ian, could you please spent some words about flow based Sprint Goals? For me it sounds  like Kanban philosophy rather then a cohesive increment.

See "Sprint Planning with Kanban": https://www.scrum.org/resources/blog/sprint-planning-kanban