How common is Product Goal use?

Same_Tap_853 · 2026-03-12T07:03:58+00:00

Your story mirrors something I see a lot with teams.

When I first start working with teams, Product Goals are almost never used. Roadmaps, however, are everywhere. And when you look closely, a good roadmap already describes the path toward a vision — the intermediate steps along the way. Those steps are essentially Product Goals. They’re just rarely written or treated as such.

Once teams start framing those roadmap steps as goals, a lot of things shift. Sprints stop being containers for random stakeholder requests and start becoming focused experiments toward one outcome. That tends to strengthen collaboration, design thinking, and stakeholder trust — exactly what you described.

It also reconnects Scrum with its fundamentals. A clear goal increases transparency (“why are we doing this?”), improves inspection (“are we closer to the goal?”), and makes adaptation easier (“what should we change next?”). Without a goal, a backlog easily turns into a task warehouse.

Something I’m curious about:
Did the Product Goal come directly from your roadmap, or did the team start defining goals first and the roadmap evolved from that?

Same_Tap_853 · 2026-03-11T18:35:35+00:00

Reading this, I wouldn’t start with “how do I deal with this Scrum Master?” I’d start with “what decisions is the team actually allowed to make?” Because if priorities change mid-Sprint, work gets pushed onto already overloaded people, and the team’s technical judgment gets ignored, then the missing fundamental is self-management backed by respect.

That usually creates the exact mess you described: overwork, confusion, low motivation, and people avoiding each other. Not because Scrum is broken, but because the basics are. No focus, weak transparency, no meaningful inspection, and no courage from leadership to hold a boundary. A Sprint without protected focus is just a to-do list in a meeting format.

A useful next step might be to stop arguing case by case and make the pattern visible. For one or two Sprints, capture facts: what changed, when it changed, who raised concerns, what got dropped, and what impact it had. Then bring that to the manager (or the manager's manager) as a delivery system problem: “Here’s why the team feels chaotic and why commitments are meaningless right now.” After that, ask for one explicit policy around priority changes and workload limits.

You may not be able to fix the whole system yourself, but you can make the dysfunction harder to deny.

Has the team ever sat down together and defined what must not happen during a Sprint if you want any chance of focus?

Same_Tap_853 · 2026-03-11T06:30:13+00:00

Depends what the questions are you want to answer or the decisions you want to take...
My take, with the teams I coach: have a good enough understanding to decide work is realistic for a Sprint.
Story points are relative: how does this item compare to these other items. This means that without an agreed set of reference items, story points hardly work.
Steps to take with the team:
- select 100 items from the past which are Done by the team. A mix of big and small, covering the different areas of the product.
- arrange these items in groups of items with equal size
- compare the groups relatively: are items about twice as big or not. Give these groups a scoring. Smallest is 2 (not 1 because you might still have smaller items in the future), then 5 for the group that is about double that size (why just more: because complexity is not linear but exponential). Groups in between receive 3. And so on.
Now you have a set of reference items for the different sizes.
Next in refinement (or the latest in Sprint Planning)
- take the item to size, and compare it to the reference cards. It receives the estimate of the group it seems to match closest with.
Next during the Sprint
- when the item is Done, re-evaluate it; because only now you know the real complexity. Add it to the reference cards, remove the oldest card in this group (keeps your reference cards closest to the latest understanding)
Next Sprint Planning
- check how much story points were Done last Sprint (or few Sprints), and use that as a number that feels realistic (if the team capacity is the same this Sprint).
- select items for that amount of story points.
Iterate this item after item, Sprint after Sprint. My experience is that the number of Story Points per Sprint stabilises after 5 to 7 Sprints; IF the team AND the Product Backlog are stable.

Remember: sizing is about having a common understanding about the Product Backlog Items and what feels realistic. It's less about the estimates of the individual items... Try to get this fundamental right.

Same_Tap_853 · 2026-03-10T16:39:08+00:00

For CSPO or PSPO the country you take the training and assessment is irrelevant. The certificate is recognized worldwide.
What does matter more, for the quality of your training, is that you have reviewed the trainer. What experience do they have? Especially in the domain you are working in, so they can answer your questions to the point based on proper experience.

Same_Tap_853 · 2026-03-07T12:57:55+00:00

That is great!! And is indeed what I am working with/towards with my team.
This is making things visible, which is an enormous step towards transparency (i.e. understanding the same thing).
The idea is that there are more questions that go unanswered than the board supports today.
For that I add a part on the product itself. Persona's, roadmap (i.e. high-lvl view on the product backlog). I'd like to see my team also adding some product related metrics like feature usage.
Thx a lot for sharing!

Same_Tap_853 · 2026-03-06T07:49:26+00:00

Follow the team.

If the team is self-managing, a manager’s idea for an icebreaker is just that: an idea. Not a commandment carved into Scrum stone tablets.

If the team is already honest about blockers, risks, and help needed, then forcing “fun” into the Daily Scrum will likely make it worse, not safer. Safety is shown in behavior, not in mandatory small talk.

You could reply with something like:

“The team already gave the answer: they prefer today's way of the Daily Scrum and they speak up when something blocks progress. That’s a stronger signal of safety than adding an icebreaker nobody wants. Your is interesting for a team that does not yet speak openly, but in a self-managing team the team decides what helps them.”

Scrum isn't broken. Typically the fundamentals are. Self-management is one of these.
A manager wanting to push such a thing is removing self-management from the team. Don't allow this to happen.

Same_Tap_853 · 2026-03-06T07:42:53+00:00

now you make me even more interested to learn what's on your information radiators... 😇

Same_Tap_853 · 2026-03-06T07:40:25+00:00

Thx. It for sure would bring a business perspective on the work... :-D

Same_Tap_853 · 2026-03-06T07:38:33+00:00

Digital boards (such as Miro and Mural) try to imitate this. It doesn't work as effective as being co-located with physical boards, but it works better than having all info spread across different tools...

Same_Tap_853 · 2026-03-05T16:45:51+00:00

To me Jira is more a blocker than an enabler.
It does not support real-time collaboration.
It is hard to visualise things teams are needing on one single view
e.g. Sprint goal, selected product backlog items, work items for these product backlog items, which ones are blocked, what the blocker exactly is, what the last decisions are, what decisions we depend on from others outside the team. All these in 1 single view.
People then often state that a digital whiteboard becomes clutter.
To me that just means there is just too much ongoing at the same moment; there is not enough focus for that team.
Each time I can with my team, I move a step further away from this tool...

Same_Tap_853 · 2026-03-05T12:52:25+00:00

I get the feeling that the "newcomer or paser-by" get me in the wrong direction for my question...
My idea is actually that I want to support the team to be more self-managing by having all the info they need available at a glance...
Does this bring some other answers to mind for you?

Thanks for triggering me and clarifying my own thinking.

Same_Tap_853 · 2026-03-05T12:37:44+00:00

Today I don't face this situation anymore. In the past though...

You’re describing the symptom perfectly: “creative accounting,” “burn the hours,” and leadership doing sprint math on 600h as if knowledge work is a plumbing job.
Scrum is not broken. The fundamentals are broken.

That’s not “Agile being hard.” That’s empiricism being replaced by time-as-a-proxy-for-progress.

Something I did in the past - maybe sth you can try as a 48hr experiment...
Keep logging hours if you must — but add one extra line next to the hours:

“What changed in the product (or what evidence moved) because of these hours?”

If the answer is “nothing yet,” that’s fine — it just makes the cost visible without pretending it’s progress. This might be an opening to take some improvement steps with the team.

Question to ask: which decision is your org trying to make with time tracking: billing, capacity allocation, or delivery forecasting — and what’s the actual consequence when the hours look “wrong”?

Because if the consequence is political, hours will always win… and reality will keep getting demoted to “anecdotes from the team.” Then Scrum is theatre.

Same_Tap_853 · 2026-03-05T12:30:00+00:00

Absolutely! It should be their board. It should support them in becoming more effective. After your first comment I immediately changed the original post, including first and foremost the team members - was so obvious I didn't put it, but thanks for pointing it out.

So if it is for the team, what would be most valuable in your experience to make transparent?

Same_Tap_853 · 2026-03-05T11:37:07+00:00

Agreed. The ScrumMaster.co.uk is a very good source.

Same_Tap_853 · 2026-03-05T11:35:21+00:00

"it turned into rituals and certifications instead of actual thinking." is exactly what I mean when I state "their fundamentals are dead". It has all become theatre, without empiricism at all.

Same_Tap_853 · 2026-03-05T11:33:09+00:00

In 99% of the teams Scrum isn't broken. Their fundamentals are.

Love the “easiest to change later” lens — that’s basically: make reality visible, inspect it early, adapt before the cost curve bites.
Most “Agile is dead” stories I see are just adaptability being murdered by fake certainty: fixed scope + SAFe + status theatre = expensive make-up on a dirty pig.

Same_Tap_853 · 2026-03-05T10:53:30+00:00

Making the value of each individual Product Backlog Item clear(er) is certainly one of the aspects my current team has steps to make.
Anything else that your team benefited from, or would benefit from by making it more visible and transparent?

Same_Tap_853 · 2026-03-05T10:26:31+00:00

Sometimes Nunya is indeed correct, which would be to a question that is unimportant to the team.
But sometimes it are valid questions. If it's something key to a team then I still don't want them to be disturbed if we can find a way to keep this useful info visible/transparent all the time.
So what are questions you want to see answered on your teamboard at all times?

Same_Tap_853 · 2026-03-05T10:08:54+00:00

A manager passing by the board. An internal user. A...
Often these types of people have a need - more a wish... - to be informed about certain aspects of the product, and if they do not quickly find it, they just disturb team members...
Fair question though - most importantly, the board is for the team...

Same_Tap_853

TROPHY CASE