11

This is a multi-faceted question, so I'll try to provide something helpful step-by-step. First, the Scrum Guide is just a guide, but it is the definitive guide on Scrum. Furthermore, it has been built and refined on decades of experience in companies effectively delivering products iteratively and incrementally. It is not the only proven approach by any ...


5

There is a lot to unwrap here, but it seems that you are in a company that is doing Scrum just by name: you don't have Sprint Goals (the 2017 version of the Scrum Guide mentions a sprint goal 27 times, the 2020 version 19 times); you don't have a product goal (the 2017 version doesn't use the words "product goal" but the 2020 version mentions it ...


4

The Scrum Guide says this: The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices. This makes it clear that if you do not have Sprint Goals and Product Goals, ...


4

There is a single sprint goal, to prioritize the sprint backlog. The team goes about what the do and when, but they need guidance. The goal is not from the user's perspective, the goal is about what the PO wants to achieve with this sprint. That might be something from the user perspective. It might not. Having sprint goals in advance is counterproductive. ...


4

What is taking the place of Product Goals and Sprint Goals? There's two ways to approach this. One is to say "without product goals or sprint goals, we're not doing SCRUM." And that works. But the "its just a guideline" argument comes up. So we really should dig deeper. The other way to approach it is to ask "why does SCRUM have ...


2

Asking a Scrum Team to deliver valuable shippable increment each Sprint leads to reinsurance - team members will put additional time/Story Points in their estimates. If you are calculating velocity there is no need to inflate estimates. The velocity will adapt over time and will reflect the team's genuine capacity to get work done. That is one of the key ...


2

TL;DR This is a good question because it exposes a common misunderstanding about Scrum theory and the value of a Sprint Goal. To illustrate your use case, though, you'd need to craft a Product Backlog from which the Scrum Team can extract backlog items that fit a central coherence. A Product Backlog that doesn't lend itself to unified Development Team ...


1

I'd suggest this: look at your project, at your company, in your situation, and think carefully: "What is it that I need to know, and for the team to know, in order for this project to be successful? And, to know when it's falling off course?" Whether you (or they) call it "scrum" or not is really not that important. The important ...


1

I think that nvoigt's answer is solid. I will add a few things. I see the Sprint Goal as a way for the Development Team to not need constant interaction with the Product Owner. Consider that the Sprint Goal is created during Sprint Planning as a collaboration between the Development Team and the Product Owner and helps to guide the selection of the Product ...


Only top voted, non community-wiki answers of a minimum length are eligible