An experiment: Go to your backlog, and scan all User Stories by title. Ask yourself: “Is this a problem statement or already a proposed solution?”

When I did this with one of my customers, the stunning answer was:
Not a single problem statement from the user existed in the backlog (the backlog had around 150 items which is a problem on its own).

Even if the description would contain the problem statement from the customer, why are we hiding this? Just reading the solution in the title will influence the developers and stops them from thinking on their own.

This has several impacts, I believe no one wants to have:

• Slicing into tinier pieces is way harder as you are faced with a solution. How can you slice a solution?
• People are conditioned to just execute the proposed solution

Both issues will not lead to teams feeling responsible for the created solutions.

One real-life example (and there are many more):

The PO pushed hard that the team should do a specific story and ship it within 10 days. The story didn’t contain the customer’s problem at all, only a solution. The team started to complain because it was nearly impossible to finish it on time. And yes, there was a deadline.

So I started to ask:

ME: What is the customer’s need or what did the customer tell you is his problem?
PO: Oh, he just wants to see what the redesign of the UI looks like.
ME: Would a screenshot or mockup be sufficient?
PO: No, the customer wants to see how to interact with the UI.
ME: Does he want to click by himself or would a recording from a devs screen be sufficient?
PO: A recording would be ok.
THE TEAM: Ok, you can have the recording within the next 3 hours.

So instead of putting a whole team into tears by letting them do a nearly impossible thing on time, one dev made tiny UI changes, and recorded how he clicked through it – boom, done!
The trouble for the team was making it work behind the scenes, the UI part was actually very easy.
The customer and PO were happy: Instead of waiting 10 days, it was now 3 hours.