Sprint Goal definition
Hi all,
My team's backlog consists mostly of epics of "value deliveries" which are improvements or new functionalities to the product that we complete every 2 weeks. Our sprint goal is usually the value delivery, so if we are going a add a Buy now button to our products page, that would be our Sprint goal .. "Add Buy now button to products page to improve the customer experience .... "
We then struggle when it comes to a value delivery that takes more than 1 sprint, lets say 2 sprints (of 2 weeks each) ... How can we define properly the sprint goal that makes sense as on the first sprint are are partially done with the functionality? Do we use the same sprint goal of each sprint? Can you advise?
thank you
If your "epics" are your Product Backlog Items, why do any of them take more than one Sprint to complete? Consider this statement from the Scrum Guide:
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
There are some things that you're doing that are a bit unusual or uncommon, but not necessarily wrong or bad. For example, most teams that I've worked with had Product Backlog Items that represent things that can be completed in a couple of days, rather than a large item that takes the full Sprint. In cases like this, the Sprint Goal is helpful since it focuses the team on the subset of selected Product Backlog Items that are most important or valuable to the stakeholder. But in the case where you have items that represent value, I can see the struggle in crafting a Sprint Goal that is separate from the Product Backlog Item.
Thanks for your reply. Sorry if i explained myself wrong. The epics are the delivery value and inside there are the user stories to complete it. But for some epics we have stories that will take more than 1 sprint to complete so we struggle to get what the sprint goal should be
The epics are the delivery value and inside there are the user stories to complete it
That's an "epic" leap-of-faith before value will be delivered. The risk of value not being maximized will then be considerable for a complex product with many unknowns.
If valuable work cannot be completed in a Sprint it is not ready for Sprint Planning. The user stories you describe are not well formed, since their value is unclear, and no valuable Sprint Goal can then be agreed out of them.
Assuming the product is complex enough to justify the use of Scrum in the first place, what you've described isn't so much a Sprint Goal problem, but an issue refining the backlog for that product.
Scrum doesn't make distinctions between "epics" and "user stories" - there are only Product Backlog Items. On top of that, the concept of "epic" isn't well-defined - primarily, I've seen it used to refer to a container for other work and as an unrefined user story.
I would recommend a few things.
First, define what your Product Backlog Item is. Each Product Backlog Item should represent a change needed to improve the product.
Then, make sure that refinement is happening and that, through the act of refinement and before Sprint Planning, the Product Backlog Items that the team is working on are things that can be completed within one Sprint.
Once you have well-refined Product Backlog Items, you can craft Sprint Goals and select Product Backlog Items based on the team's ability to take on and complete work, or the team's capacity. Crafting a goal and choosing the Product Backlog Items to support that goal is an iterative process.
Thank you. I think i have a good idea on how to start improving.