Split user stories ruthlessly and get value earlier

- the person assigned to you as voice of customer does not use the product - the person doesn't have time to engage with the dev team - the person doesn't care

Over the years I have seen exactly one product owner who could give useful feedback. All the others in the end had no idea what they were after.

This user story is utterly absurd.

In this case, the "user" is actually the company, not the developer. The developer usually wants to provide business value by adding new features, or fixing bugs. And this is a feature, but it's not a feature for the developer. It's a feature for the company.

The fact that it got broken down into manual data entry features like:

"Users (read developers) select a project and enter hours spent for each day"

Makes me question whether the users were involved in making the stories at all.

This article feels like an illustration of what is wrong with Big-A Agile, not an exemplar of how to do it right.

"We want to add the software version number to the dialog. We think they will then cite this when they raise tickets"

?

At least in this form, you can expand on the context and justify it in depth.

Also, user stories often phrase the context as a given when it's really not. In your example, it's an implicit premise that a version number may help. In mine, the writer admits scepticism and therefore invites the programmer to think up some better solution.

Admin :: Roles :: Multiple Roles)

And the "story" part goes in the body:

"As an adminstrator I assign multiple roles to users so they have access to all the parts (and only those parts) of the application they need to do their job."

..with additional context, exceptions, rules, examples, etc, in the body.

If I may share an alternative possibility..

It often comes down more to communication styles and the individuals involved. It's still possible to do exploration and answer the questions about what's done / doing / blocking. You could say "I learned X won't work, now I'm exploring Y, and currently debugging Z". The only time this would be problematic is in scenarios where the leader is not supportive of honest communication about activities, in which case it may worth asking why you're spending your life / time underneath such an individual.

In general I'm a strong advocate of tight feedback loops and frequent communication in a team. There are many benefits, including helping ensure everyone has access to the support they need to be successful. The result of these tight loops sometimes also translates to deciding to set someone loose for a[defined] period of time to focus their energy on researching creative solutions or just jamming on something without distractions.

P.S. - Regarding "going dark": As a manager I can understand why as a general rule of thumb that managers pose issue with this.

The common, crappy scenario goes like this. An individual goes dark, then comes back with nothing of consequence to show for it or any evidence that they tried to do anything. Now valuable time has been squandered, while the rest of the team was hard at work. This leads to an array of harmful effects for all involved (the manager, the team, and individual worker).

Even if you are super responsible, fear and trauma from past offenders could still be a trigger for some managers.