I’m all in for the idea of “tags” instead of “job titles” and was agreeing with the whole text until that phrase:

“the task that is the most relevant and valuable to the
team at that time, within the context of the project’s goals, rather
than just the tasks of most relevance to my job title”

Sometimes, the project goals may be harmful and blind the team to some other tasks that someone “knows” has to be done (like a new tool to analyze some data or the POC of some technology that no one in the team have expertise yet and they may need in the future). A “responsible specialist” may use some “free time” to tackle some of those tasks, while someone “following the goals” would pick up the next Sprint story…

Of course, If the PO is a nice person and the team has a good relationship with him/her, those tasks can be made visible and emerge in the next planning meeting and may even have a higher priority than a Story would 🙂 In that particular case, the “just follow the goal” approach would work well

If yes, than the user story probably describes actions and interactions of agents.
Otherwise you describe features of some software behaviour within a certain technological device.

I suspect that many people who make the mistake of feature-orientation haven’t read Mike’s book, certainly not properly. So, I thought I’d try to provide a shorter explanation that gets the point across in a different way.

I think that part of the problem is that many people look at the apparent simplicity of user stories and just do what they’ve always done except with a superficial application of the Connextra template (As a…I want…So that…). They may read literature on the web and find plenty of examples (written by people with the same assimilation bias) that support their assumptions and association with their past experiences of ‘requirements’.

This focus on features is natural. I’m pretty sure there was a time where I also thought of stories in this way. This is explained quite well by a quote from Udi Dahan:
‘Users ultimately dictate solutions to us, as a delta from the previous set of solutions we’ve delivered them. That’s just human psychology – writer’s block when looking at a blank page, as compared to the ease with which we provide “constructive criticism” on somebody else’s work.’ -http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/
Quote Highlighted: https://diigo.com/01uzg5

It’s not just users, it’s also those who may represent the users such as Product Owners and Business Analysts. So, I thought I’d try to help people see the impact of feature-oriented stories rather than goal-oriented stories on their agility (as in the dictionary definition of the term). I hope people see this article and see the opportunities for increased flexibility and speed-to-market as an incentive to better understand the subtleties of user stories.

Thanks for reading.